Re: [PATCH 0/6] RFC: introduce extended inode owner identifier v4

[Dmitry Monakhov <dmonakhov@openvz.org>]

Dave Chinner <david@fromorbit.com> writes:

> On Thu, Feb 18, 2010 at 07:45:24PM +0300, Dmitry Monakhov wrote:
>> 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.
>
> Admins, users and developers of mangement tools are all going to
> hate us if we introduce subtly different "project/directory quota
> like" accounting to different filesystems with different
> administration mechanisms.
Seems what you right here.
>
> The fact that project quotas are already implemented in XFS is not a
> valid reason for creating a new, slightly less functional,
> incompatible implementation of the same feature in other
> filesystems.
>
>> And my implementation is
>> slightly different from it especially from user-space point of view.
>
> This is exactly my point - if a user has an ext4 filesystem and an
> xfs filesystem then your proposal will result in them needing two
> different mechanisms to manage the project/directory quotas on their
> filesystems.  This result is not desirable from a system design
> perspective.  Management of such a feature needs to be consistent
> across all filesystem types - just like it is for user and group
> quotas - and we already have a widely used and well tested
> management interface that can be used to implement exactly what you
> need.
Not exactly. XFS  allow only subtree-like structure (link, rename are
restricted). Personally I think what right restriction, but someone may
want to have not subtree-like hierarchy. So this patch doesn't introduce
any link/rename rules. If user want to restrict his tree it will use
bindmount. IMHO it is more intuitive than XFS does.
But again you definitely right about feature_names/interfaces ambiguity 
If we can create common interface it would be great. See later in 
the mail.
>
>> In order to avoid ambiguity i've stopped at the "metagroup" term.
>> I hope it is final name for the feature.
>
> I think "metagroup" is too abstract and will likely be confused with
> group quotas by those that don't understand what it is. i.e it does
> not convey any information about the bounds of the quota container
> (unlike user, group, directory or project).
Ok. Since we want common interface we should use well known "project_id"
term.

I think we can try to unify it in following way:
*User interface*
As soon as i understand XFS manage projid via xfs_ioctl_setattr, 
struct fsxattr. IMHO it is not good idea to make this interface common
for all filesystems. Let's use standard i_op->setxattr/getxattr for
this purpose. Let's name this xattr as "system.project_id".
And xfs may easily catch corresponding setxattr/getxatrr and translate
it to it's ioctl interface, so both interfaces will be equal.
At least xattr interface already supported by various utils (tar,
rsync, etc).

*Link/Rename behavior*
 Let's introduce two modes:
 1) SHARED project hierarchy: without restrictions for link/renames
 2) ISOLATED project hierarchy: Well known XFS (subtrees like)
    link/rename rules
 And support this two mode like this:
 generic_fs)
       SHARED: by default 
       ISOLATED: via bindmount
 XFS)
       ISOLATED: by default, because this is expected semantics (no
                 changes required)
       SHARED: xfs may add "shared_project" mount feature to disable
               isolation semantics. At least this gives user more
               flexibility than before.
 We have to document such difference. In order to avoid misbehavior.

*VFS interface to project_id*
 In order to make profit of project_id we have to make it visible to
 vfs layer, and let quota and nfsd (any other users?) exploit this.
 Let's use proposed per-sb aux_attributes table for this purpose.
 Off course i was wrong then proposed to export pointer to project_id
 (former metagroup) var. Since this value is read-only we have to
 export it like this: unsigned get_project_id(struct inode *inode)
 And document what project_id changes are guarded by inode->i_mutex
 So caller have to grab i_mutex in order to avoid races.

What do you think?