Richard Gooch wrote:
>
> Hi, Al. I'd like to explore an idea Linus suggested a while back. He
> suggested using VFS inodes as the data store for devfs, rather than
> keeping stuff in devfs entries. So the idea would be that the VFS
> maintains the tree structure rather than devfs entries.
>
> This is a lot closer to being feasible with all the VFS changes you've
> been making, but there is one problem that really concerns me. VFS
> inodes are very heavyweight. The devfs entries are very lightweight,
> storing only that which is necessary. So you could save some code
> space in devfs, but at the expense of increased data size. Either way,
> it costs RAM.
>
> Have you given any consideration to coming up with a more lightweight
> inode structure? Either through modification of the VFS inode, or
> creation of some kind of "generic" lightweight inode structure that
> stores the bare essentials. Perhaps it could go like this:
> dentry->lightweight inode->heavyweight inode.
>
> 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.
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.
>
> 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.
>
> I have two basic questions:
>
> - do you see merit in some kind of cheaper inode structure
>
> - how would you like to see it done?
>
> Regards,
>
> Richard....
> Permanent: [EMAIL PROTECTED]
> Current: [EMAIL PROTECTED]
This looks like the start of an interesting discussion.:)
