On Fri, 16 Jun 2000, Hans Reiser wrote:
> Dropping dentries could easily be much harder to code in the general case, and
> your resisting that suggestion is very reasonable, but we are pie-in-the-skying
> right now, so I said what I did. I will further pie-in-the-sky and suggest that
> perhaps special individual directories could be without dentries, and perhaps
> that would be easier to code since those special directories could fail to
> support such things as mount points, etc.
Unfortunately, that list would have to include (e.g.) rename() in them and
all their children. Having isolated dentries (or subtrees detached from
root) _may_ be OK if we guarantee that nothing will happen in that subtree.
As soon as you want to work with it you'll have to take care of merging it
with the root one. IOW, the subtree containing root is the only one that
may be involved in any sort of lookups/link creation/removal. That way we
can guarantee that other subtrees may grow towards root until they meet
the main tree - otherwise you are in for very interesting hellbroth of
races. It would be even slightly worse than pure vnode design...
> Now is probably a good time to pie-in-the-sky for 2.5, as doing anything
> imaginative for 2.4 should be strictly verbotten, and we all need something
> besides debugging to get us through the day. Agree?
Well, if that's your idea of fun... <shudder>
> > No surprise here, but if they have dedicated boxen they may want to trim
> > the unneeded lines from inode->u - it's a union and it has some pretty
> > large fields. If you don't use foofs - don't include its private inode
> > into the thing. Not that radical, but may actually reduce the
> > sizeof(struct inode) about two times (depends on the filesystem mix they
> > are using, indeed).
>
> I know ifdefs are not beloved by the penguin, but is there any other reason not
> to use them on said union to exclude unconfigured filesystems? They seem
> precisely appropriate here.
One word: modules. Oh, and Linus is not alone in distaste to ifdefs.
This union is an old design mistake and it actually used to be worse -
named pipes also were there. By chance it worked on ext2 and minixfs since
there fs-specific part of inode had pointers to data blocks in the first
fields (they are not used for named pipes, indeed, and large enough to
avoid intersection of pipe-related stuff with fields that sit after them).
Ewww...
Real fix, indeed, is to take the fs-specific parts out of the struct
inode. That can be done on fs-by-fs basis and since it doesn't affect
other filesystems it can happen even in 2.4 - this stuff is pretty much
automatic.
