From: Dmitry Monakhov <dmonakhov@openvz.org>
To: linux-ext4@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org, tytso@mit.edu, adilger@sun.com,
hch@infradead.org, jack@suse.cz, david@fromorbit.com,
viro@ZenIV.linux.org.uk, xemul@openvz.org
Subject: Ping.
Date: Tue, 06 Apr 2010 13:00:58 +0400 [thread overview]
Message-ID: <87ljd1vtth.fsf@openvz.org> (raw)
In-Reply-To: <1268920970-9061-1-git-send-email-dmonakhov@openvz.org> (Dmitry Monakhov's message of "Thu, 18 Mar 2010 17:02:45 +0300")
Dmitry Monakhov <dmonakhov@openvz.org> writes:
> This is 6'th version of extened inode owner patch-set.
> Please review it tell me what do you think about all this.
> Are you agree with this approach?
> Are you worry about some implementation details?
> Is it ready for merge to some devel's tree?
Ping. I haven't got response about the patchset, just small note about
xattr-name from Andreas.
Please clarify what do you think about whole idea and
current patch-set state. What do i have to do to make a progress?
>
> *Feature description*
> 1) Inode may has a project identifier which has same meaning as uid/gid.
> 2) Id is stored in inode's xattr named "system.project_id"
> 3) Id is inherent from parent inode on creation.
> 4) This id is cached in memory inode structure vfs_inode->i_prjid
> This field it restricted by CONFIG_PROJECT_ID. So no wasting
> of memory happens.
>
> 5) Since id is cached in memory it may be used for different purposes
> such as:
> 5A) Implement additional quota id space orthogonal 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
> project_id will be accessible via nfsd)
>
> 6) It is possible to create isolated project's subtree.
> Note: Please do not blame isolation feature before you read the
> isolation patch description, and than please wellcome.
>
> *User interface *
> Project id is managed via generic xattr interface "system.project_id"
> This good because
> 1) We may use already existing interface.
> 2) xattr already supported by generic urils tar/rsync and etc
>
> PATCH SET TOC:
> 1) generic projectid support
> 2) generic project quota support
> 3) ext4 project support implementation
> 3A) ext4: generic project support
> 3B) ext4: project quota support
> 3C) ext4: project isolation support. This patch is not principal
> but makes ext4 implementation rename behaviour equotals
> to XFS
>
> Patch against linux-next-20100318
> Changes against v5
> - convert dquota_transfer to struct iattr interface. Not it is possible
> to change i_prjid via notify_changes()
> - some bugfixes.
next prev parent reply other threads:[~2010-04-06 9:07 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-18 14:02 [PATCH 0/5] RFC: introduce extended inode owner identifier v6 Dmitry Monakhov
2010-03-18 14:02 ` [PATCH 1/5] vfs: Add additional owner identifier Dmitry Monakhov
2010-03-18 14:02 ` [PATCH 2/5] quota: Implement project id support for generic quota Dmitry Monakhov
2010-03-18 14:02 ` [PATCH 3/5] ext4: Implement project ID support for ext4 filesystem Dmitry Monakhov
2010-03-18 14:02 ` [PATCH 4/5] ext4: add project quota support Dmitry Monakhov
2010-03-18 14:02 ` [PATCH 5/5] ext4: add isolated project support Dmitry Monakhov
2010-03-18 21:25 ` [PATCH 3/5] ext4: Implement project ID support for ext4 filesystem Andreas Dilger
2010-03-19 8:16 ` Dmitry Monakhov
2010-04-06 9:00 ` Dmitry Monakhov [this message]
2010-04-13 18:14 ` Ping Christoph Hellwig
2010-04-15 11:30 ` Ping Dmitry Monakhov
2010-05-15 9:34 ` Ping Al Viro
2010-04-30 12:14 ` Ping to Al Pavel Emelyanov
-- strict thread matches above, loose matches on Subject: below --
2011-04-09 11:20 ping Gáspár Lajos
2011-09-17 13:32 [PATCH 1/3] ext4: migrate cleanup Dmitry Monakhov
2011-10-28 20:34 ` Ping Dmitry Monakhov
2023-08-13 6:18 Ping Manas Ghandat
2023-08-13 6:18 ` Ping Manas Ghandat
2023-08-13 6:25 ` Ping Greg KH
2023-08-13 6:25 ` Ping Greg KH
2023-08-13 7:50 ` Ping Willy Tarreau
2023-08-13 7:50 ` Ping Willy Tarreau
2024-09-04 6:20 ping Su Hui
2024-09-04 7:53 ` ping Christian Heusel
2024-10-30 10:32 ping metux
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=87ljd1vtth.fsf@openvz.org \
--to=dmonakhov@openvz.org \
--cc=adilger@sun.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=viro@ZenIV.linux.org.uk \
--cc=xemul@openvz.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.