Re: lazytime implementation questions

[Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org>]

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-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org