On Wed, Jan 06, 2016 at 08:05:06PM -0500, Theodore Ts'o wrote: > On Wed, Jan 06, 2016 at 09:59:07AM +1100, Dave Chinner wrote: > > > So the intended semantics is: > > > 1) fsync / sync / freeze / unmount will write the timestamp updates even > > > with lazytime. So unless crash happens, timestamps are guaranteed to be > > > consistent. Also sync / fsync guarantees all changes to get to disk. > > > 2) We periodically write back timestamps (once per 24 hours) to avoid too > > > big timestamp inconsistencies in case of crash. > > > > Ok, so it's supposed to be a delayed timestamp update mechanism > > without any specific ordering guarantees, not an opportunistic > > timestamp update mechanism. > > There is an optimization which ext4 has which will update related > timestamps when we write an inode table block, which is > "opportunistic", but there is no guarantee that this will happen. XFS used to do that, too, before we removed all that hackery when we moved to logging timestamp updates unconditionally a few years ago. I'm going to have to re-instate some of that code for lazytime, I think. > This is purely optional; other file systems don't have to do this, but > it can be a win in that if related inodes are in the same 4k block, > and we need to update, say, the index file one because we are changing > i_size, but we were also doing non-allocating writes to the data file, > then we might as well write out the timestamps for the data file at > the same time, since this is "free". *nod*. Explicit, optimised clustered inode writeback (rather than purely opportunistic clustering via delayed buffer writeback) was added to XFS way back in early 1999. :) Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
