linux-kernel - Re: relatime: update once per day patches (was: ext3 IO latency measurements)

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 26 Mar 2009 10:48:43 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Frans Pop <elendil@...net.nl>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>, mingo@...e.hu,
	tytso@....edu, jack@...e.cz, alan@...rguk.ukuu.org.uk,
	arjan@...radead.org, a.p.zijlstra@...llo.nl, npiggin@...e.de,
	jens.axboe@...cle.com, drees76@...il.com, jesper@...gh.cc,
	linux-kernel@...r.kernel.org, oleg@...hat.com, roland@...hat.com
Subject: Re: relatime: update once per day patches (was: ext3 IO latency
 measurements)

On Thu, 26 Mar 2009 18:12:04 +0100 Frans Pop <elendil@...net.nl> wrote:

> On Thursday 26 March 2009, Andrew Morton wrote:
> > On Thu, 26 Mar 2009 09:14:28 -0700 (PDT) Linus Torvalds 
> <torvalds@...ux-foundation.org> wrote:
> > > I generally agree witht he "leave policy to user space" people, but
> > > this is an area where (a) user space has shown itself to not get it
> > > right (ie people don't do even the existing relatime because distros
> > > don't) and (b) what's the alternative?
> > >
> > > > I (and others) pointed out that it would be better to implement
> > > > this as a mount option.  That suggestion was met with varying
> > > > sillinesses and that is where things stand.
> > >
> > > I'd suggest first just doing the 24 hour thing, and then, IF user
> > > space actually ever gets its act together, and people care, and they
> > > _ask_ for a mount option, that's when it's worth doing.
> >
> > We wouldn't normally just enable the new feature by default because it
> > changes kernel behaviour.  Userspace needs to be changed in some manner
> > to opt-in.  One way it's `mount -o remount', the other way it's a poke
> > in /proc.
> 
> What change are you talking about here exactly? The "change relatime to 
> have a 24 hour safeguard" of Matthes's first patch or the "enable 
> relatime by default" options in the second patch?
> 
> For the first I don't think it's that big a deal as it is a change that 
> makes the behavior of relatime safer and not riskier. Also, it's 
> something people have argued should have been part of the initial 
> functionality of relatime (it was part of the discussion back then), and 
> finally for a lot of users it's already current functionality as major 
> distros already do include the patch.
> 
> For the second, I can see your point and can understand reservations to 
> make enabling relatime a kernel config option.
> 
> Speaking exclusively for myself, I would be happy enough if only the first 
> of Matthew's patches would get accepted.
> 

Oh, the feature itself is desirable.  But the interface isn't.

- It's a magic number.  Maybe someone runs tmpwatch twice per day, or
  weekly, or...

- That's fixable by making "24" tunable, but it's still a global
  thing.  Better to make it per-fs.

- mount(8) is the standard way of tuning fs behaviour.  There's no
  need to deviate from that here.

Note that none of this involves the default setting.  With a per-mount
tunable we can still make the default for each fs be "on, 24 hours"
if we so decide.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/