Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question
    
Found this: lwn.net/2002/0214/a/dirsync.php3 Seems to have a lot of information you may find useful. –  Joel Davis Apr 2 '13 at 17:04

1 Answer 1

up vote 3 down vote accepted

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.

share|improve this answer
    
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. –  Joel Davis Apr 2 '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. –  Patrick Apr 2 '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. –  Joel Davis Apr 2 '13 at 17:23
    
Which RFC are you referring to BTW? –  Joel Davis Apr 2 '13 at 17:25
    
@JoelDavis RFC 2821. 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 ) –  Patrick Apr 2 '13 at 17:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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