linux-ext4 - Re: [PATCH,RFC] ext4: add lazytime mount option

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 13 Nov 2014 16:34:50 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Dave Chinner <david@...morbit.com>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH,RFC] ext4: add lazytime mount option

On Fri, Nov 14, 2014 at 07:48:32AM +1100, Dave Chinner wrote:
> However, we'd be fools to ignore the development of relatime, which
> in it's original form never updated the atime until m/ctime updated.
> 3 years after it was introduced, relatime was changed to limit the
> update delay to 24 hours (before it was made the default) so that
> applications that required regular updates to timestamps didn't
> silently stop working.
> 
> So perhaps what we should simply define "lazytime" policy to be
> "only update timestamps once a day or whenever the inode is
> otherwise modified, whichever comes first".

Yes, that's reasonable thing to do.  Right after I hit send on my last
email I thought about adding a tunable that would do this sort of time
delay, but making it be a hard-coded 24 hours is simpler.

> lazytime isn't POSIX compliant as it is implemented in the patch.
> sync() won't write back inodes with lazy timestamp updates as they
> are not tracked in dirty lists or the ext4 journal, therefore a
> crash after a sync() can still lose timestamp updates from before
> the sync() ran.

Good point, I had fixed it for fsync(), but not for sync();
fortunately it's easy enough to make sure this gets fixed if we
implement it at the VFS Layer.

> w.r.t. default behaviour, like relatime, I think this it will be a
> couple of years before we can consider it to be a default.  We'll
> need to shake out it's impact on the Real World first....

Fair enough, although that will only work if distributions actually
enable it by default so we get that real world experience.  Otherwise,
we'll not gain any experience wrt to Real World impact.

What I'm thinking about doing is adding a way to enable lazytime via a
flag in the ext4 superblock, which in turn can be set by tune2fs or
mke2fs (if so enabled by /etc/mke2fs.conf), so that we _can_ get this
real world experience.

Cheers,

						- Ted
--
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