[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070806065712.GA2818@elte.hu>
Date: Mon, 6 Aug 2007 08:57:12 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Willy Tarreau <w@....eu>
Cc: Alan Cox <alan@...rguk.ukuu.org.uk>,
Claudio Martins <ctpm@....utl.pt>,
Jeff Garzik <jeff@...zik.org>,
Jörn Engel <joern@...fs.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>, linux-mm@...ck.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
miklos@...redi.hu, akpm@...ux-foundation.org, neilb@...e.de,
dgc@....com, tomoki.sekiyama.qu@...achi.com, nikita@...sterfs.com,
trond.myklebust@....uio.no, yingchao.zhou@...il.com,
richard@....demon.co.uk, david@...g.hm
Subject: Re: [PATCH 00/23] per device dirty throttling -v8
* Willy Tarreau <w@....eu> wrote:
> In your example above, maybe it's the opposite, users know they can
> keep a file in /tmp one more week by simply cat'ing it.
sure - and i'm not arguing that noatime should the kernel-wide default.
In every single patch i sent it was a .config option (and a boot option
_and_ a sysctl option that i think you missed) that a user/distro
enables or disabled. But i think the /tmp argument is not very strong:
/tmp is fundamentally volatile, and you can grow dependencies on pretty
much _any_ aspect of the kernel. So the question isnt "is there impact"
(there is, at least for noatime), the question is "is it still worth
doing it".
> Changing the kernel in a non-easily reversible way is not kind to the
> users.
none of my patches did any of that...
anyway, my latest patch doesnt do noatime, it does the "more intelligent
relatime" approach.
Ingo
-
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/
Powered by blists - more mailing lists