[Dovecot] Best filesystem?

[Stan Hoeppner]

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=Documentation/filesystems/xfs.txt;hb=HEAD
> 
> 
> 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