It seems in a hard crash, in particular failure of a UPS to keep a system running, that some of the contents of logs get lost due to file system caching. As an experiment, I tried mounting the /var partition with the sync option. There was substantially more disk noise on a boot up, but the show stopper was trying to run apt. The disk pounded away while apt sat there unresponsive.

Is it a mistake to mount /var sync, or is one of the options such as relatime, strictatime or noatime required for success? If so, is it safe to use one of these options on /var?


Enabling sync on the filesystem level is usually not a good solution (usually, not always). When sync is enabled, it not only forces a buffer flush on every single write, it also negates the filesystem's ability to re-order writes to optimize IO (by writing larger chunks). This also results in higher fragmentation.

The better solution is to get whatever application youre using to use fsync (or fdatasync) instead. When an application writes out data, it can make a call to fsync which will force that data out to disk. This way it's only certain data that is being synced all the time, and not the whole filesystem. It also is a little more intelligent as the fsync can be called once the application has written all its data, and not on every little bit.

If youre using syslog-ng, it has the ability to enable fsync on per file destination (documentation). rsyslog might also have this feature, but I do not know.

  • Thanks for the tip on ``syslog-ng''. – casualunixer Mar 12 '12 at 1:22
  • From what I'd seen in rsyslog the synced writes are the default. You have to prepend the filename with a hyphen (eg, -/var/log/messages) to disable sync. – Jodie C Mar 12 '12 at 2:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.