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.