[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070805144645.GA28263@thunk.org>
Date: Sun, 5 Aug 2007 10:46:45 -0400
From: Theodore Tso <tytso@....edu>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Claudio Martins <ctpm@....utl.pt>, Jeff Garzik <jeff@...zik.org>,
Ingo Molnar <mingo@...e.hu>,
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
On Sun, Aug 05, 2007 at 01:49:26AM +0100, Alan Cox wrote:
> HSM is the usual one, and to a large extent probably why Unix originally
> had atime. Basically migrating less used files away so as to keep the
> system disks tidy.
>
> Its not something usally found on desktop boxes so it doesn't in anyway
> argue against the distribution using noatime or relative atime, but on
> big server boxes it matters
In addition, big server boxes are usually not reading a huge *number*
of files per second. The place where you see this as a problem is (a)
compilation, thanks to huge /usr/include hierarchies (and here things
have gotten worse over time as include files have gotten much more
complex than in the early Unix days), and (b) silly desktop apps that
want to scan huge numbers of XML files or who want to read every
single image file on the desktop or in an open file browser window to
show c00l icons. Oh, and I guess I should include Maildir setups.
If you are always reading from the same small set of files (i.e., a
database workload), then those inodes only get updated every 5 seconds
(the traditional/default metadata update sync time, as well as the
default ext3 journal update time), it's no big deal. Or if you are
running a mail server, most of the time the mail queue files are
getting updated anyway as you process them, and usually the mail is
delivered before 5 seconds is up anyway.
So earlier, when Ingo characterized it as, "whenever you read from a
file, even one in memory cache.... do a write!", it's probably a bit
unfair. Traditional Unix systems simply had very different workload
characteristics than many modern dekstop systems today.
- Ted
-
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