linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).