[RFC PATCH 0/2] A new way of attaching information to inodes

From: Jan Kara
Date: Thu Apr 30 2009 - 13:54:08 EST


Hi,

currently our VFS inode structure is quite big. It contains quite some
members that are useful only in some cases (e.g. device pointers and list head
used only when the inode represents a block/character device, quota pointers
used only when the filesystem actually supports quota, etc.). And it would
be helpful to add some more so that we can handle ACL's in generic code, or
we can do some kind of block reservation for mmaped writes, and there are
other cases.
So I though it may be worth a try to come up with a way to attach info to
inode structure so that generic code can look it up (or find it's not there),
it's space effective and on the other hand the access does not cost us too
much.
What I've come up with is that each inode could have a pointer to a (usually
static) table of offsets of structures associated with the inode. Filesystem
would then carry the structures it is interested in in it's private inode.
As an example, I've converted quota pointers from inode to use this feature
and ext2 filesystem so that we have some rough idea how the resulting code
looks like. IMO from the filesystem's POV it's quite fine, the generic code
gets a bit less obvious but it's bearable as well. Regarding the speed, we
impose additinal lookup in the table and an addition of the offset from the
table so it should be IMHO acceptable cost for things that are not really fast
path.
What do you think? Your opinions and suggestions are welcome...

Honza
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/