linux-ext4 - Re: lazytime implementation questions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20160107022140.GM21461@dastard>
Date:	Thu, 7 Jan 2016 13:21:40 +1100
From:	Dave Chinner <david@...morbit.com>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Jan Kara <jack@...e.cz>, xfs@....sgi.com,
	linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-api@...r.kernel.org
Subject: Re: lazytime implementation questions

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@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html