From: "Ragnar Kjørstad" <reiserfs@ragnark.vestdata.no>
To: Hans Reiser <reiser@namesys.com>
Cc: Daniel Phillips <phillips@bonn-fries.net>,
linux-kernel@vger.kernel.org, reiserfs-dev@namesys.com,
Nikita Danilov <god@namesys.com>,
green@thebsh.namesys.com
Subject: Re: [reiserfs-dev] Re: Ext2 directory index: ALS paper and benchmarks
Date: Sat, 8 Dec 2001 20:16:39 +0100 [thread overview]
Message-ID: <20011208201639.B12687@vestdata.no> (raw)
In-Reply-To: <E16BjYc-0000hS-00@starship.berlin> <3C0EE8DD.3080108@namesys.com> <20011206122753.A9253@vestdata.no> <E16CNHk-0000u4-00@starship.berlin> <20011207174726.B6640@vestdata.no> <3C112E20.2080105@namesys.com> <20011207235641.B18104@vestdata.no> <3C115BB6.5050402@namesys.com>
In-Reply-To: <3C115BB6.5050402@namesys.com>; from reiser@namesys.com on Sat, Dec 08, 2001 at 03:15:50AM +0300
On Sat, Dec 08, 2001 at 03:15:50AM +0300, Hans Reiser wrote:
> >>no, actually this is a problem for v3. stat data are time of creation
> >>ordered (very roughly speaking)
> >>and directory entries are hash ordered, meaning that ls -l suffers a
> >>major performance penalty.
> >
> >Yes, just remember that file-body ordering also has the same problem.
> >(ref the "find . -type f | xargs cat > /dev/null" test wich I think
> >represent maildir performance pretty closely)
>
> So is this a deeply inherent drawback of offering readdir name orders
> that differ hugely from time of creation order?
It should not be, if:
* If the cache was smart enough to detect that the user is reading all
the files in a directory and started reading in files into memory
ahead of time. It sounds ugly, so I don't know if I like it.
or
* file-bodies were ordered by hash as well.
> I suppose we could use objectids based on the hash of the first
> assigned filename plus a 60 bit global to the FS counter....
>
> but it is too many bits I think. I think that using substantially less
> than the full hash of the name that is used for directory entry keys
> doesn't work.... Comments welcome.
The abould stort the file-bodies in optimal order in the three, but
block-allocation is a seperate issue, right? Even if block-allocation
would take objectids into account it would be nearly impossible to get
the optimal order of the file-bodies, because you don't know the number
of files and their sizes before allocating the blocks for the first
files. (unless you would move files around after they are allocated)
So, I think the _only_ way to get the optimal performance for a growing
directory is to do allocation and ordering by creating-time.
That said, maybe trying to find algorithms that are order sub-sets of
the directories entries in optimal order rather than the whole directory
is perhaps more constructive? Or look at repackers or other utilities to
reorder data in batch instead?
So how is this done in ext2/3 with directory indexes, Daniel? Are there
any papers available, or would I have to decifer the source?
--
Ragnar Kjørstad
Big Storage
next prev parent reply other threads:[~2001-12-08 19:17 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 [this message]
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 ` [reiserfs-dev] " Ragnar Kjørstad
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=20011208201639.B12687@vestdata.no \
--to=reiserfs@ragnark.vestdata.no \
--cc=god@namesys.com \
--cc=green@thebsh.namesys.com \
--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