[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <46BCECED.7050002@gmail.com>
Date: Sat, 11 Aug 2007 00:55:41 +0200
From: Rene Herman <rene.herman@...il.com>
To: Matti Aarnio <matti.aarnio@...iler.org>
CC: Vlad <vladc6@...oo.com>, linux-kernel@...r.kernel.org
Subject: Re: Noatime vs relatime
On 08/10/2007 05:10 PM, Matti Aarnio wrote:
> On Fri, Aug 10, 2007 at 07:26:46AM -0700, Vlad wrote:
> ...
>> "Warning: Atime will be disabled by default in future kernel versions,
>> but you will still be able to turn it on when configuring the kernel."
>>
>> This should give a heads-up to the 0.001% of people who still use
>> atime so that they know to customize this option or start using modern
>> file-monitoring techniques like inotify.
>
> NO for two reasons:
> - atime semantics are just fine in server environments
> - inotify IS NOT scalable to millions of files, nor
> to situations where we want to check alteration weeks
> or months after the fact
>
> In reality I would perhaps prefer mount-behaviour being altered
> from 'by default do atime' to 'by default do noatime.
I must say I've been wondering about relatime a bit as well. Are there
actually users who do really want atime, but not badly enough to want real
atime?
I've been running with noatime for years now and do not plan on changing
that so have been shrugging this entire discussion off with "no care of
mine", but whose care _is_ it?
> There MUST be an easy way to tell system that "yes, I want to track
> last accesstime."
mount -o atime. Or as far as I'm concerned, keep the default as posixly
compliant as one wants and teach people and distributions to mount "noatime"
as I hear some have already been doing. I may be wrong, but to me, relatime
sounds like compromising for the sake of compromising...
Rene.
-
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