Ron Leach put forth on 1/31/2011 4:06 AM:
git.kernel.org - linux/kernel/git/torvalds/linux-2.6.git/blob - Documentation/filesystems/xfs.txt 175 "fs.xfs.xfssyncd_centisecs (Min: 100 Default: 3000 Max: 720000) 176 The interval at which the xfssyncd thread flushes metadata 177 out to disk. This thread will flush log activity out, and 178 do some processing on unlinked inodes. 179 "
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Do...
Why does this period in the UPS availability-time matter? Because the UPS available-time has, of course, to first be allocated to the application machines to close their applications, before the file servers can be asked to 'commit' any delayed allocations and close down themselves (I don't want the file servers to close down while Dovecot (and any other applications) still have relevant data yet unwritten to the file-servers).
You need to read all about the xfssyncd thread before you jump to conclusions about what the above patch actually does, and does not, do, and how that may or may not relate to your specific concerns here.
Note that when you do a shutdown, the kernel will flush all buffers, and XFS will automatically push all writes to disk. The patch you're looking at above, IIRC, is a house cleaning parameter, not a normal operations parameter. For instance, if you create 10k directories that's not going to fit in the XFS log. Once it fills up, the inodes at the head of the log will start getting flushed to disk, and new inodes will start coming in the tail of the log. If fs.xfs.xfssyncd_centisecs was a "set in stone" parameter you'd never get any performance out of XFS. IIRC the maximum log size is 128MB. Again, once it fills, it starts writing out immediately.
Also, if Ted's article told you anything, it is that any application writing critical data needs to do fsync or O_DIRECT, because no filesystem itself makes any guarantees about when data hits the disk. Ok, EXT3 did, for various ill conceived reasons. In a way, I guess, that patch above does something similar to what EXT3 did, but only for metadata in this case.
-- Stan