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 19:43:04 +0000
From:	Matthew Garrett <mjg@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Frans Pop <elendil@...net.nl>,
	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, Mar 26, 2009 at 12:20:03PM -0700, Andrew Morton wrote:
> On Thu, 26 Mar 2009 18:49:00 +0000 Matthew Garrett <mjg@...hat.com> wrote:
> > On Thu, Mar 26, 2009 at 10:48:43AM -0700, Andrew Morton wrote:
> > There has to be a default. 24 hours is a sensible one.
> 
> "default" implies that it can be altered by some means.

You need a default even in the tunable case.

> > When did we adopt a mindset that led to code having to satisfy every 
> > single user requirement before being accepted, rather than being happy 
> > with code that provides an incremental improvement over what exists 
> > already?
> 
> Shortcomings have been identified.  Weaselly verbiage is not a suitable
> way of addressing shortcomings!

What shortcomings? So far we have a hypothetical complaint that some 
users will want to choose a different value. Right now they have the 
choice of continuing to not use relatime. Things are no worse for them 
than they were previously.

> > If there are actually users who want to be able to tune this 
> > per filesystem then I'm sure someone (possibly even me) will write code 
> > to support them, but right now it just sounds like features for the sake 
> > of some sense of aesthetic correctness.
> 
> A hard-wired global 24-hours constant is in no way superior to a
> per-mount tunable.  If we're going to do this we should do it in the
> best way we know, and we certainly should not lock ourselves into the
> inferior implementation for all time by exposing it to userspace.

I don't claim that it's superior, merely that it deals with all the use 
cases I've had to worry about and so is good enough. If it turns out 
that there are people in the real world who need the better version then 
I can write that code, but I'm not going to while it's a hypothetical.
-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/