From: Ryusuke Konishi <ryusuke-sG5X7nlA6pw@public.gmane.org>
To: reinoud-S783fYmB3Ccdnm+yROfE0A@public.gmane.org
Cc: tangyorangesour-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
Subject: Re: How does NILFS2 handle directory management
Date: Fri, 11 Sep 2009 15:44:52 +0900 (JST) [thread overview]
Message-ID: <20090911.154452.43227079.ryusuke@osrg.net> (raw)
In-Reply-To: <20090911052213.GA24899-5cYspOl2ggRz6xQTk39kMVfVdRo2wo/d@public.gmane.org>
Hi,
On Fri, 11 Sep 2009 07:22:13 +0200, Reinoud Zandijk wrote:
> Hi folks,
>
> On Fri, Sep 11, 2009 at 10:21:18AM +0900, Ryusuke Konishi wrote:
> > > I dont know if b+tree directory management would be preferable though. With
> > > some smart caching all directory operations can be made O(1) anyway.
> >
> > Yes, directory is a file and it's already managed with b-tree like
> > other files. However, the current directory design is not O(log n),
> > and is actually slow especially for file creation.
>
> Thats what i was refering to. UDF has the same issue and the same design on
> directory structure, only even more complicated since directory entries are
> not of a fixed length and may actually span logical sectors/blocks.
>
> I now have code in UDF that i also use in my NiLFS implementation that manages
> the first file creation/reference in O(n) but all other files
> creation/lookup/delete in O(1)! speeding up large directory copies
> modifications/copies enormously, upto thousands of times.
You mean hashing (on-memory) by file names?
Well, I agree. Such optimization would improve directory operations of
the current code without disk format change.
I think it should be considered along with ext3 approach.
> > So, it leaves room for considering the true "b-tree directory
> > management".
> >
> > OTOH, the replacement has the following points to notice:
> >
> > 1) It may complicate the log writer.
> >
> > The current log writer is designed on the basis that every data
> > and meta data is a file. In NILFS, inodes, segment usage state,
> > and checkpoints, are managed with correponding meta-data files.
> >
> > The true "b-tree directory management" may break this uniformity.
>
> This indeed complicates it a lot. It could still be implemented using `perfect
> hashing' techniques in one file but i have no experience with this and updates
> may still be expensive.
>
> With regards,
> Reinoud
>
> P.S. Ryusuke, did you recieve my mail on the length of partial segments?
Oh, I just noticed.
Regards,
Ryusuke Konishi
next prev parent reply other threads:[~2009-09-11 6:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-10 19:16 How does NILFS2 handle directory management Prasenjit Giri
[not found] ` <2324ff2b0909101216q31dad1a8y43ea0f229923a0c3-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-09-10 19:26 ` Reinoud Zandijk
[not found] ` <20090910192619.GA1263-bVHBekiX4bNgoMqBc1r0ESegHCQxtGRMHZ5vskTnxNA@public.gmane.org>
2009-09-11 1:21 ` Ryusuke Konishi
[not found] ` <20090911.102118.69189169.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-09-11 3:48 ` Jiro SEKIBA
[not found] ` <873a6u16qy.wl%jir-27yqGEOhnJbQT0dZR+AlfA@public.gmane.org>
2009-09-11 4:13 ` Ryusuke Konishi
2009-09-11 3:58 ` Prasenjit Giri
[not found] ` <2324ff2b0909102058g1ee407fco3f2482b4732dacca-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-09-11 6:23 ` Ryusuke Konishi
2009-09-11 5:22 ` Reinoud Zandijk
[not found] ` <20090911052213.GA24899-5cYspOl2ggRz6xQTk39kMVfVdRo2wo/d@public.gmane.org>
2009-09-11 6:44 ` Ryusuke Konishi [this message]
[not found] ` <20090911.154452.43227079.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-09-14 10:27 ` Reinoud Zandijk
[not found] ` <20090914102731.GA154-5cYspOl2ggRz6xQTk39kMVfVdRo2wo/d@public.gmane.org>
2009-09-24 8:49 ` Jiro SEKIBA
[not found] ` <87hbusbud6.wl%jir-27yqGEOhnJbQT0dZR+AlfA@public.gmane.org>
2009-09-25 12:21 ` Reinoud Zandijk
[not found] ` <20090925122109.GD6624-5cYspOl2ggRz6xQTk39kMVfVdRo2wo/d@public.gmane.org>
2009-09-25 15:47 ` Ryusuke Konishi
[not found] ` <20090926.004730.113223425.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-09-25 16:23 ` Reinoud Zandijk
[not found] ` <20090925162334.GA14945-5cYspOl2ggRz6xQTk39kMVfVdRo2wo/d@public.gmane.org>
2009-09-26 1:16 ` Ryusuke Konishi
[not found] ` <20090926.101634.31873031.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-09-27 22:10 ` Reinoud Zandijk
[not found] ` <20090927221049.GA14618-5cYspOl2ggRz6xQTk39kMVfVdRo2wo/d@public.gmane.org>
2009-09-27 23:03 ` Jiro SEKIBA
2009-09-27 11:34 ` Jiro SEKIBA
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=20090911.154452.43227079.ryusuke@osrg.net \
--to=ryusuke-sg5x7nla6pw@public.gmane.org \
--cc=reinoud-S783fYmB3Ccdnm+yROfE0A@public.gmane.org \
--cc=tangyorangesour-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org \
/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