From: Jan Kara <jack@suse.cz>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Subject: [RFC PATCH 0/2] A new way of attaching information to inodes
Date: Thu, 30 Apr 2009 19:31:16 +0200 [thread overview]
Message-ID: <1241112678-6615-1-git-send-email-jack@suse.cz> (raw)
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
next reply other threads:[~2009-04-30 17:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-30 17:31 Jan Kara [this message]
2009-04-30 17:31 ` [PATCH 1/2] Implement trivial struct feature macros Jan Kara
2009-05-01 9:14 ` Christoph Hellwig
2009-04-30 17:31 ` [PATCH 2/2] Use feature code to eliminate quota pointers from inodes for filesystems that don't need it Jan Kara
2009-05-02 3:23 ` Ryusuke Konishi
2009-04-30 19:43 ` [RFC PATCH 0/2] A new way of attaching information to inodes Theodore Tso
2009-05-01 9:08 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1241112678-6615-1-git-send-email-jack@suse.cz \
--to=jack@suse.cz \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®