From: Dmitry Monakhov <dmonakhov@openvz.org>
To: linux-fsdevel@vger.kernel.org
Cc: Dmitry Monakhov <dmonakhov@openvz.org>
Subject: [PATCH 0/6] RFC: introduce extended inode owner identifier v4
Date: Thu, 18 Feb 2010 19:45:24 +0300 [thread overview]
Message-ID: <1266511530-10533-1-git-send-email-dmonakhov@openvz.org> (raw)
This is new generation of attempt to add extended inode identifier.
In previous posts it was called tree_id, subtree_id, project_id.
But after none of this was not good enough. I've refused project_id
because it is well know XFS feature. And my implementation is
slightly different from it especially from user-space point of view.
In order to avoid ambiguity i've stopped at the "metagroup" term.
I hope it is final name for the feature.
*Feature description*
1) Inode may has a metagroup identifier which has same meaning as uid/gid.
2) Id is stored in inode's xattr named "system.metagroup"
3) Id is inherent from parent inode on creation.
4) This id is cached in memory inode structure(inside fsprivate_inode)
and is accessible from vfs layer.
5) Since id is cached in memory it may be used for different purposes
such as:
5A) Implement additional quota id space ortohonal to uid/gid. This is
useful in managing quota for some filesystem hierarchy(chroot or
container over bindmount)
5B) Export dedicated fs hierarchy to nfsd (only inode which has some
metagroup will be accessible via nfsd)
*Implementation details*
It is unlikely that everybody will be happy to have new field in
vfs_inode(which is not widely used). What's why this field is
stored inside private_inode.
But we have to have an access to this private_field.
First time similar issue was resolved while implementing
generic quota reserved_space management interface.
Jan suggested to implement some sort auxiliary inode attributes map.
And access non standard inode attributes via this aux_attr_map.
I've implemented this idea in form of per-sb aux_attribute table.
(Macros is not good here because different attributes may have
different types which result in massive typecasting).
If someone have better ideas please say you word.
In order to give an overview of this interface i've converted
quota's reserved space interface to that new aux_attr_table.
After we have generic interface for auxiliary attributes
each filesystem may implement metagroup support in it's own meaner.
This should be done in following steps:
1) Add field to private_inode, and export it via aux_attribute
2) Implement id inheritance on inode creation
3) Implement handler for "system.metagroup" xattr.
This patch contains an example implementation of this for ext4.
The patch-set is compile tested only.
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 12b1aa1..c9aef25 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 33
-EXTRAVERSION = -rc8
+EXTRAVERSION = -rc8-metagroup
NAME = Man-Eating Seals of Antiquity
# *DOCUMENTATION*
--
1.6.6
next reply other threads:[~2010-02-18 16:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-18 16:45 Dmitry Monakhov [this message]
2010-02-18 16:45 ` [PATCH 1/6] vfs: add per-sb auxiliary inode attribute table Dmitry Monakhov
2010-02-18 16:45 ` [PATCH 2/6] quota: switch reservation space management to aux_attribute Dmitry Monakhov
2010-02-18 16:45 ` [PATCH 3/6] vfs: Add additional owner identifier Dmitry Monakhov
2010-02-18 16:45 ` [PATCH 4/6] quota: Implement metagroup support for quota Dmitry Monakhov
2010-02-18 16:45 ` [PATCH 5/6] ext4: enlarge mount option field Dmitry Monakhov
2010-02-18 16:45 ` [PATCH 6/6] ext4: Implement metagroup support for ext4 filesystem Dmitry Monakhov
2010-02-18 19:00 ` [PATCH 1/6] vfs: add per-sb auxiliary inode attribute table Brad Boyer
2010-02-18 19:34 ` Dmitry Monakhov
2010-02-18 23:31 ` [PATCH 0/6] RFC: introduce extended inode owner identifier v4 Dave Chinner
2010-02-19 10:16 ` Dmitry Monakhov
2010-02-19 23:31 ` Dave Chinner
2010-02-20 10:58 ` Dmitry Monakhov
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=1266511530-10533-1-git-send-email-dmonakhov@openvz.org \
--to=dmonakhov@openvz.org \
--cc=linux-fsdevel@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;
as well as URLs for NNTP newsgroup(s).