Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Jan Kara <jack <at> suse.cz>
Subject: [RFC PATCH 0/2] A new way of attaching information to inodes
Newsgroups: gmane.linux.kernel
Date: Thursday 30th April 2009 17:31:16 UTC (over 7 years ago)
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
 
CD: 4ms