On Tue, 13 Jun 2000, Richard Gooch wrote:
> 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.
<nods> That's a problem. Unfortunately, not the only one - there is an
revalidation stuff that can also make life painful.
> 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.
Start from taking ext2, UFS and NFS out of ->u. in struct inode. Yup,
separate allocation and inlined function (ext2_ino(inode)) that would
return the pointer to private part of inode. I can send you my old (circa
2.2.early) patch that does it for ext2 tonight - hope that will help.
Notice that some filesystems are already keeping private stuff out of
struct inode, so similar taking the worst offenders out will not be too
complex. You'll need ->clear_inode() releasing the data + foo_new_inode()
and foo_read_inode() allocating it. That's more or less it - minimal patch
mostly consists of replacements like inode->u.ext2_i.foo to
ext2_ino(inode)->foo.
