On Tue, Feb 7, 2017 at 10:05 PM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 2017-02-07 at 11:49 -0800, Christoph Hellwig wrote: >> On Tue, Feb 07, 2017 at 11:02:03AM -0800, James Bottomley wrote: >> > > Another option would be to require something like a project as >> > > used >> > > for project quotas as the root. This would also be conveniant as >> > > it >> > > could storge the used remapping tables. >> > >> > So this would be like the current project quota except set on a >> > subtree? I could see it being done that way but I don't see what >> > advantage it has over using flags in the subtree itself (the >> > mapping is >> > known based on the mount namespace, so there's really only a single >> > bit >> > of information to store). >> >> projects (which are the underling concept for project quotas) are >> per-subtree in practice - the flag is set on an inode and then >> all directories and files underneath inherit the project ID, >> hardlinking outside a project is prohinited. > > OK, this is what I don't understand: how is something that's inode > based limited to be per-subtree? The way I've seen the VFS operate it > seems that any given inode (and indeed dentry) can appear in many > subtrees so how do I limit them to just one? > Project id's are not exactly "subtree" semantic, but inheritance semantics, which is not the same when non empty directories get their project id changed. Here is a recap: https://lwn.net/Articles/623835/ So if you created an empty directory and "marked" it for shiftuid and all descendants inherited this property you would be able to check that property on a per inode basis. Not sure that is what you are looking for? I guess we should define the semantics for the required sub-tree marking, before we can talk about solutions.
