lkml.org 
[lkml]   [1997]   [Dec]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Filesystem optimization..
From
Date
tytso@mit.edu writes:
>
> From: "Michael O'Reilly" <michael@metal.iinet.net.au>
> Date: 29 Dec 1997 12:45:42 +0800
>
> So: Why not embed the inode directly into the directory itself?
>
> Check out the Usenix Proceedings from the January, 1997 conference;
> there's an article about doing something very much like your idea.

Any idea when unenix will allow you to buy their proceedings on-line? :)

> While I was there, I toyed with trying to add a similar (although not
> quite as ambitious as was described in their paper) to ext2fs. That is,
> instead of eliminating the inode table altogether, put a copy of the
> inode in the directory, but leave a forwarding pointer in the inode
> table for programs like e2fsck and dump which need to scan the inode
> table.

That did cross my mind. Without the redudancy of the inode used
bitmap, and the inodes in known positions, it's a little harder to
detect inconsistencies...

> It's doable, but it runs into complicating factors; how to handle adding
> and removing hard links is one of the bigger ones, which you've already
> identified.

Adding / removing hard links is easy enough except with the underlying
directory is deleted as well.

I did think of a relatively clean solution.

The inode number --> inode mapping is simply:
inode offset on disk == (inode number) * sizeof(inode);
thus adding hardlinks runs exactly as normal (you find the existing
inode, and add a link to it).

Deleting a directory now requires an extra check. You need to ensure
that none of the inodes in the directory has a non-zero count. If it
does, you need to add that block to a 'used block' list to prevent it
being re-allocated until the inode ref count falls to zero.

As far as I can think, that fixes everything.

Fsck now turns into a real problem. There's no longer to nearly
independant data structures to check against each other. If you lose a
directory, it's damned hard to find it again.

> In either the simpler or the more ambitious case, it would require
> non-trivial modifications to the ext2 filesystem, and in the latter
> case, the filesystem format would be completely incompatible, so you
> might as well call it a completely new filesystem (which is what the
> people who wrote the Usenix paper did when they modified the UFS
> filesystem).

Yup. :(


Michael.

\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.152 / U:0.624 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site