Alexander Viro writes:
> 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.
I'd like to see something more drastic. Indeed, that union crap is by
far the worst offender and needs fixing. But there's a whole pile of
other junk that's just not needed all the time.
Even with a patch to remove the union bloat, I'm still not keen on
using the VFS for devfs storage, as it would be quite a bit more
wasteful than the current devfs implementation.
Besides, there's also the problem of getting efficiency improvements
into the mainline kernel. I don't expect Linus would let us fix these
things so close to 2.4.
> 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.
Yeah, but 2.4 is too close. Such a change is going to require a fair
bit of surgery for all filesystems.
I still prefer my idea of splitting the dcache and icache so that you
can maintain a populated dentry tree without keeping the inodes
hanging around as well. This seems far less invasive and also brings
even more space savings.
Do you dislike this approach? If so, why?
Regards,
Richard....
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
