Messages in this thread | | | Subject | Re: Filesystem optimization.. | From | "Michael O'Reilly" <> | Date | 01 Jan 1998 09:34:23 +0800 |
| |
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.
| |