Dave Chinner <david@xxxxxxxxxxxxx> 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
