7

Today I stumbled upon this mount's option:

dirsync All directory updates within the filesystem should be done synchronously. This affects the following system calls: creat, link, unlink, symlink, mkdir, rmdir, mknod and rename.

What are some real-life use cases for this option? When would I want to use dirsync instead of sync?

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
Petr
  • 1,624
  • 2
  • 19
  • 35
  • Found this: http://lwn.net/2002/0214/a/dirsync.php3 Seems to have a lot of information you may find useful. – Bratchley Apr 02 '13 at 17:04

1 Answers1

7

sync does everything dirsync does, plus more. Unfortunately this 'more' is a significant performance penalty. With sync enabled, all disk I/O is immediately written to disk. With dirsync, only directory operations are immediately written.

The only case I've seen where one might want to use dirsync instead of sync is in the case of network filesystems. When multiple boxes are working in a shared directory, they might try to create the file at around the same time. One box will create the file, but without dirsync on, the file isn't visible to other boxes yet. With dirsync on, the file will show up immediately, so the other servers at least know it exists and can now perform file locking on it.

phemmer
  • 70,657
  • 19
  • 188
  • 223
  • As an addendum, the article I linked to states that the original motivation for dirsync was to "make the MTA folks happy" which makes sense given how much file locking goes on and how often they use temporary files when processing the queues. – Bratchley Apr 02 '13 at 17:17
  • @JoelDavis Saw that comment, but it doesn't make much sense. The RFC for mail transfer says the entire file must be committed to disk, not just the directory entry. – phemmer Apr 02 '13 at 17:19
  • Well it's written by Andrew Morton so it's bonafide no matter what our understanding of the logic is. But the file-based operations have to do with queue operations and locking mailbox files. This is transparent to the transmitting client and just how the internals of the MTA are structured. I know most mail admins don't turn on sync operations for the filesystems (for performance reason), so there must be some wiggle room. – Bratchley Apr 02 '13 at 17:23
  • Which RFC are you referring to BTW? – Bratchley Apr 02 '13 at 17:25
  • @JoelDavis [RFC 2821](http://tools.ietf.org/html/rfc2821). `It MUST NOT lose the message for frivolous reasons, such as because the host later crashes`. (I do enjoy how they call a crash "frivolous" :-P ) – phemmer Apr 02 '13 at 17:32
  • If that's the criteria then that explains why they use flat files from the get-go rather than just storing everything in memory until it's been processed and queued. It still doesn't require file I/O be sync'd. To fulfill the requirement the MTA would just have to blindly dump what it gets to a file and do an fsync, after which directory operations are the only sticking point. – Bratchley Apr 02 '13 at 17:42
  • For clarity, the assumption I'm making is that it would wait for the fsync before returning the 250 to the SMTP client. – Bratchley Apr 02 '13 at 17:47
  • @JoelDavis Correct, it does not require full sync I/O as in a write to disk for every `write()` call. It only requires that when the `250 OK` is given that it be written to disk. Postfix does this as well. It explicitly calls `fsync` on the files when fully written. You can also call `fsync` on a directory to ensure that the directory is updated as well. You do not need to enable `dirsync` on the mount. – phemmer Apr 02 '13 at 17:48
  • I don't think I can continue the conversation much farther since I'm at the limit of stuff I either know or can make an educated guess on, but fwiw there has to be some bonafide logic to it. I doubt mm (judging from other comments I've seen from him on other things, and the approach taken by kernel maintainers in general) would be servicing an idle request from MTA vendors especially if the vendors had the ability to control what they had a problem with. – Bratchley Apr 02 '13 at 17:57