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.
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.
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]
