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.html
File system structure:
http://xfs.org/docs/xfsdocs-xml-dev/XFS_Filesystem_Structure//tmp/en-US/html/index.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=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).
regards, Ron
