From: Oleg Drokin <green@namesys.com>
To: Nikita Danilov <Nikita@Namesys.COM>
Cc: reiserfs-dev@namesys.com, reiserfs-list@namesys.com
Subject: Re: Using filename-hash as part of key
Date: Mon, 23 Dec 2002 14:58:19 +0300 [thread overview]
Message-ID: <20021223145819.A7670@namesys.com> (raw)
In-Reply-To: <15878.63735.448875.70027@laputa.namesys.com>
Hello!
On Mon, Dec 23, 2002 at 02:52:23PM +0300, Nikita Danilov wrote:
> > We refer to this order as "read optimised" ;)
> > Of course writing files in read-optimised order is not always possible,
> > so the idea is to use hash of file name as part of the key.
> Can you clarify this? Hash of a file name is already used as a part of
> directory entry key (and has always been from the earliest versions of
> reiserfs, as far as I know).
No, I mean to use it as part of key used fir everything including
statdata/filebody
> v3. I generally think this is easy enough to try without a lot of
> discussion, thanks to decision to concentrate all key assignment
> decisions in one place (kassign.c). One point: probably we want to embed
> into key part of file name rather than hash.
That would require us to calculate the hash lots of times instead of doing
this only once, no?
We still do not suport changing of hash on the fly anyway.
> > That would allow us to allocate blocks for files in right order (only
> > true for reiesr4 where we have delayed allocation).
> >
> > Obvious disadvantages are: larger keys mean more fs overhead,
> If we restrict ourselves to only optimizing layout of stat-data (rather
> than file bodies), current key size would suffice, because now offset
> field of stat-data's key is unused.
No, I think optimising only statdata is not that useful as optimising
both statdata and file data.
> > this optimisation won't work if file gets renamed later, if this directory
> > is never read in sequentional order.
> >
> > But as Hans argues, usually these sequentional-read operations are ones most
> > noticed because they are usually performed by humans:
> > ls, tar, copy of a directory and this kind of stuff.
> Humans are so slow compared to the slowest hard drive that ls is the
> least important thing to optimize.
This is not true for large directories populated in random order.
Bye,
Oleg
next prev parent reply other threads:[~2002-12-23 11:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-23 11:16 Using filename-hash as part of key Oleg Drokin
2002-12-23 11:27 ` Anders Widman
2002-12-23 11:52 ` Nikita Danilov
2002-12-23 11:58 ` Oleg Drokin [this message]
2002-12-23 15:49 ` Valdis.Kletnieks
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=20021223145819.A7670@namesys.com \
--to=green@namesys.com \
--cc=Nikita@Namesys.COM \
--cc=reiserfs-dev@namesys.com \
--cc=reiserfs-list@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.