From: Dmitry Monakhov <dmonakhov@openvz.org>
To: Andreas Dilger <adilger@sun.com>
Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
tytso@mit.edu, hch@infradead.org, jack@suse.cz,
david@fromorbit.com, viro@ZenIV.linux.org.uk, xemul@openvz.org
Subject: Re: [PATCH 3/5] ext4: Implement project ID support for ext4 filesystem
Date: Fri, 19 Mar 2010 11:16:14 +0300 [thread overview]
Message-ID: <87fx3wg20h.fsf@openvz.org> (raw)
In-Reply-To: <41219796-D9F2-4292-9284-E8D266EB3532@sun.com> (Andreas Dilger's message of "Thu, 18 Mar 2010 15:25:00 -0600")
Andreas Dilger <adilger@sun.com> writes:
> On 2010-03-18, at 08:02, Dmitry Monakhov wrote:
>> * Disk layout
>> Project id is stored on disk inside xattr usually inside ibody.
>> Xattr is used only as a data storage, It has not user visible xattr
>> interface.
>>
>> * User interface
>> Project id is accessible via generic xattr interface
>> "system.project_id"
>>
>> +#define EXT4_XATTR_INDEX_PROJECT_ID 7
>
> If you are making this attribute available to userspace via
> system.project_id, doesn't it make sense to store it on disk as
> system.project_id also (i.e. in the "system" namespace)?
>
> Alternately, the "trusted" namespace is already intended for use as
> "accessible only by root/kernel" semantics if this is what you are
> trying to achieve.
Yess, may be it will be better storage class for projectid.
> I'm also with the statement "It has not user visible xattr interface"
> yet you also write "Project id is accessible via generic xattr
> interface". Why bother having this complexity when you are free to
> make the two identical?
Ohh. obviously sentence that 'xattr is not visible' is obsolete.
I'v forgot to change it after prjid becomes visible xattr, sorry
for ambiguity.
>
> Cheers, Andreas
> --
> Andreas Dilger
> Sr. Staff Engineer, Lustre Group
> Sun Microsystems of Canada, Inc.
next prev parent reply other threads:[~2010-03-19 8:16 UTC|newest]
Thread overview: 26+ 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 [this message]
2010-04-06 9:00 ` Ping Dmitry Monakhov
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 --
2012-06-21 9:08 [PATCH 0/5] RFC: introduce extended inode owner identifier v9 Dmitry Monakhov
2012-06-21 9:08 ` [PATCH 3/5] ext4: Implement project ID support for ext4 filesystem Dmitry Monakhov
2012-06-21 23:51 ` Jan Kara
2012-07-03 18:46 ` Dmitry Monakhov
2012-06-22 3:07 ` Dave Chinner
2012-06-28 10:16 ` Jan Kara
2012-07-03 19:11 ` Dmitry Monakhov
2010-03-04 18:34 [PATCH 0/5] RFC: introduce extended inode owner identifier v5 Dmitry Monakhov
2010-03-04 18:34 ` [PATCH 1/5] vfs: Add additional owner identifier Dmitry Monakhov
2010-03-04 18:34 ` [PATCH 2/5] quota: Implement project id support for generic quota Dmitry Monakhov
2010-03-04 18:34 ` [PATCH 3/5] ext4: Implement project ID support for ext4 filesystem Dmitry Monakhov
2010-03-11 12:06 ` Christoph Hellwig
2010-03-11 13:30 ` Dmitry Monakhov
2010-03-11 19:54 ` Andreas Dilger
2010-03-11 22:01 ` tytso
2010-03-12 9:32 ` Dmitry Monakhov
2010-03-12 20:07 ` J. Bruce Fields
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=87fx3wg20h.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 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).