Hans Reiser writes:
> Richard Gooch wrote:
> > Another idea (probably too radical, and also CPU inefficient), is a
> > super lightweight inode that has just two pointers: one to FS-specific
> > data, another to FS-specific methods. The methods are used to
> > read/write inode members, so each FS can decide just how much is worth
> > storing.
>
> There are desired applications of reiserfs where the VFS inode is
> just too heavyweight. I'd just like to say that this seems like a
> good concern you have here, and the ReiserFS team is completely
> willing to recode in 2.5.* to accomodate your radical proposal, or
> some as yet unproposed even better radical proposal if it comes
> along, because this is a real issue. Perhaps the ultimate
> lightweight inode would simply mean treating the dcache as optional,
> and the FS determining whether to look there for it or sidestep it.
In my case, I'd like to keep the dcache, because I'd like the VFS to
maintain my tree, rather than having to do it myself. I just want the
inodes to shrink.
The radical idea of using methods to access each inode field is
probably too radical. It would impact the performance of every FS,
because direct access would be replace with indirect function calls.
I don't seriously advocate this approach.
> For persons surprised that this is a real issue, let me just mention
> that there are persons desiring to put 30 million entry plus
> hypertext indexes with poor locality of reference into reiserfs as
> directories, and one issue is that the VFS inode costs too much RAM.
> For these indexes to be effective one needs to use stem compression
> and other such techniques on them just to be able to prevent being
> killed by random I/Os to disk when the index is too big for RAM.
Agreed, the VFS inode is bulky. But dentries are cheap. Do you see a
problem with the amount of RAM they take up?
> > Yet another idea is to split the dcache and icache so that you can
> > keep dentries around (thus maintaining your tree), with pointers to
> > FS-specific data (to save "inode" state), but still free VFS inodes
> > when there is memory pressure. This would require a new "refill"
> > method, which is similar but not quite the same as the lookup()
> > method.
>
> Also interesting.
And probably a lot more reasonable than my radical suggestion.
Regards,
Richard....
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
