Stan Hoeppner wrote:
Did you read the other excellent XFS resources available?
Users guide: http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide//tmp/en-US/html/index.htm...
File system structure: http://xfs.org/docs/xfsdocs-xml-dev/XFS_Filesystem_Structure//tmp/en-US/html...
Training labs: http://xfs.org/docs/xfsdocs-xml-dev/XFS_Labs/tmp/en-US/html/index.html
I don't know why I missed these, thank you for pointing them out. Following Ted Tso's blog post mentioned by Timo, I'll read up on inodes and allocation so that I understand what is, and is not, committed, and when. What I do worry about is a crash or power loss during the period between the time an application requests some data to be written, and the time that the filesystem actually completes writing it with all the file allocation data correct (and therefore tolerant of a crash from then on).
I thought I read in the XFS mount options something that suggested there was up to a 30 second window for this commit, which is a relatively long lump of time out of our UPS availability. Here it is, not a mount option but a 'sysctl' (I expect these are discussed in the docs you pointed me to, above).
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).
regards, Ron