public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Ragnar Kjørstad" <reiserfs@ragnark.vestdata.no>
To: Cameron Simpson <cs@zip.com.au>
Cc: Hans Reiser <reiser@namesys.com>,
	Daniel Phillips <phillips@bonn-fries.net>,
	linux-kernel@vger.kernel.org, reiserfs-dev@namesys.com
Subject: Re: [reiserfs-dev] Re: Ext2 directory index: ALS paper and benchmarks
Date: Fri, 7 Dec 2001 14:06:09 +0100	[thread overview]
Message-ID: <20011207140608.A1684@vestdata.no> (raw)
In-Reply-To: <E16BjYc-0000hS-00@starship.berlin> <3C0EE8DD.3080108@namesys.com> <20011207141913.A26225@zapff.research.canon.com.au>
In-Reply-To: <20011207141913.A26225@zapff.research.canon.com.au>; from cs@zip.com.au on Fri, Dec 07, 2001 at 02:19:13PM +1100

On Fri, Dec 07, 2001 at 02:19:13PM +1100, Cameron Simpson wrote:
> On Thu, Dec 06, 2001 at 06:41:17AM +0300, Hans Reiser <reiser@namesys.com> wrote:
> | Have you ever seen an application that creates millions of files create 
> | them in random order?
> 
> I can readily imagine one. An app which stashes things sent by random
> other things (usenet/email attachment trollers? security cameras taking
> thouands of still photos a day?). Mail services like hotmail. with a
> zillion mail spools, being made and deleted and accessed at random...

I wouldn't think either of those had "random" names.
E.g. a lot of mailsystems use maildir for storage, and the filenames
depend on the server recieving the data and a timestamp. It's a very
good example of what can be optimized with some guesses about ordering.

> But they shouldn't have to! Specificly, to "play nice" you need to know
> about the filesystem attributes. You can obviously do simple things like
> a directory hierachy as for squid proxy caches etc, but it's an ad hoc
> thing. Tuning it does require specific knowledge, and the act itself
> presumes exactly the sort of inefficiency in the fs implementation that
> this htree stuff is aimed at rooting out.

An ordering hash doesn't imply that you _need_ some knowledge about the
filesystem attributes. The hash should not change the worst-case
scenario significantly. The only effect of an ordering hash should be
that you get best-case whenever you access the files in order, and I
believe that tests on reiserfs have shown both that:
* this particular ordering is used in real life applications
and
* the best case is significantly better than the worst case.
  (probably because of read-ahead and better cache results)

That said, there are other ways for filesystem to guess the optimal
order of the files, e.g.:
1 the order of wich files are created
2 a seperate interface where userspace programs could specify optimal
  order

The 2. is probably out of the question because applications would need
to be changed to take advantage, but ordering the files on disk in the
order they were created in is probably a very good approxemation.



-- 
Ragnar Kjørstad
Big Storage

      parent reply	other threads:[~2001-12-07 13:06 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-05 21:26 Ext2 directory index: ALS paper and benchmarks Daniel Phillips
2001-12-06  3:41 ` Hans Reiser
2001-12-06  3:54   ` Daniel Phillips
2001-12-06  3:56     ` Hans Reiser
2001-12-06  4:08       ` Daniel Phillips
2001-12-06 13:44         ` Hans Reiser
2001-12-06 17:22           ` Daniel Phillips
2001-12-07  0:13             ` [reiserfs-dev] " Hans Reiser
2001-12-07  4:39               ` Daniel Phillips
2001-12-07 12:36                 ` Hans Reiser
2001-12-07 14:35                   ` Daniel Phillips
2001-12-07 20:16                     ` Hans Reiser
2001-12-06 11:27   ` Ragnar Kjørstad
2001-12-07 15:51     ` Daniel Phillips
2001-12-07 16:47       ` Ragnar Kjørstad
2001-12-07 17:41         ` Daniel Phillips
2001-12-07 18:03           ` Ragnar Kjørstad
2001-12-07 18:18             ` Daniel Phillips
2001-12-07 21:10               ` Hans Reiser
2001-12-07 21:12               ` Hans Reiser
2001-12-07 18:32           ` Andrew Morton
2001-12-07 19:46             ` Daniel Phillips
2001-12-07 20:00               ` Andrew Morton
2001-12-08  7:19             ` Linus Torvalds
2001-12-08 17:32               ` Daniel Phillips
2001-12-08 17:54                 ` Jeff Garzik
2001-12-09  3:27                   ` Daniel Phillips
2001-12-09  4:19                     ` Linus Torvalds
2001-12-09 16:29                       ` Alan Cox
2001-12-09 20:13                       ` Daniel Phillips
2001-12-10  6:27                         ` Linus Torvalds
2001-12-10  6:49                           ` Alexander Viro
2001-12-10  8:32                           ` Alan Cox
2001-12-10 16:14                           ` Daniel Phillips
2001-12-08 20:28                 ` Hans Reiser
2001-12-08 21:10                   ` Ragnar Kjørstad
2001-12-07 21:01         ` Hans Reiser
2001-12-07 22:56           ` Ragnar Kjørstad
2001-12-08  0:15             ` Hans Reiser
2001-12-08 19:16               ` Ragnar Kjørstad
2001-12-08 19:55                 ` Hans Reiser
2001-12-09  2:47                   ` Daniel Phillips
2001-12-09  2:39                 ` Daniel Phillips
2001-12-08 18:02       ` Jeremy Fitzhardinge
2001-12-09  2:24         ` Daniel Phillips
2001-12-07  3:19   ` Cameron Simpson
2001-12-07 10:54     ` Hans Reiser
2001-12-07 14:53       ` Daniel Phillips
2001-12-07 20:33         ` Hans Reiser
2001-12-07 13:06     ` Ragnar Kjørstad [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20011207140608.A1684@vestdata.no \
    --to=reiserfs@ragnark.vestdata.no \
    --cc=cs@zip.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phillips@bonn-fries.net \
    --cc=reiser@namesys.com \
    --cc=reiserfs-dev@namesys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox