Hi folks, On Thu, Sep 24, 2009 at 05:49:09PM +0900, Jiro SEKIBA wrote: > Reinoud Zandijk wrote: > > > I think it should be considered along with ext3 approach. > > > > What is is the ext3 approach? What is different compared to ext2? And is it > > really such a big improvement? Will it complicate directory reading/writing > > more? > > ext3 approach is a hashed index for file names, stored on disk. > So it always costs constant time to lookup the block filename stored.
So its basicly the same aproach as mine only with the disadvantage that the hash is stored on-disc and hacked into the directory entries. That explains the deletion penelty to be paid since the has to be updated. One could cheat by not updating the hash on disc on deletion since its result will backfire on lookup but thats silly. Hmm... with these things in mind, i'd still opt for the application of my hash scheme in NiLFS2. It does have the penalty that the directory has to be sequentially read once but no further penalties and no disc layout change. Note that it *only* needs the directory contents to be read, the inodes don't have to be visited/created and is thus a cheap alternative. The only time it will be slower than ext3 is when you randomly delete files from large directories visiting each directory once... an event thats not remotely realistic. Looking into the papers you sent me, they refer to my scheme as a `cached index' if i read it correctly. The disadvantages they bring forward are not that realistic in common use. Especially not if you keep the cache entries small like the 24/28 bytes it takes for mine and if it also keeps track of the free entries. Thoughts? With regards, Reinoud Zandijk _______________________________________________ users mailing list [email protected] https://www.nilfs.org/mailman/listinfo/users
