[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070805102021.GA4246@unthought.net>
Date: Sun, 5 Aug 2007 12:20:21 +0200
From: Jakob Oestergaard <jakob@...hought.net>
To: Jeff Garzik <jeff@...zik.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
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
On Sat, Aug 04, 2007 at 02:08:40PM -0400, Jeff Garzik wrote:
> Linus Torvalds wrote:
> >The "relatime" thing that David mentioned might well be very useful, but
> >it's probably even less used than "noatime" is. And sadly, I don't really
> >see that changing (unless we were to actually change the defaults inside
> >the kernel).
>
>
> I actually vote for that. IMO, distros should turn -on- atime updates
> when they know its needed.
Oh dear.
Why not just make ext3 fsync() a no-op while you're at it?
Distros can turn it back on if it's needed...
Of course I'm not serious, but like atime, fsync() is something one
expects to work if it's there. Disabling atime updates or making
fsync() a no-op will both result in silent failure which I am sure we
can agree is disasterous.
Why on earth would you cripple the kernel defaults for ext3 (which is a
fine FS for boot/root filesystems), when the *fundamental* problem you
really want to solve lie much deeper in the implementation of the
filesystem? Noatime doesn't solve the problem, it just makes it "less
horrible".
If you really need different filesystem performance characteristics, you
can switch to another filesystem. There's plenty to choose from.
--
/ jakob
-
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