On Thu, Jul 07, 2011 at 09:48:22PM -0700, Paul Nienaber wrote: > I would definitely agree that this is perhaps perhaps quite > nonsensical in the case of user/group quotas. However, a project > quota is conceptually a quota for "files in a directory and its > subdirectories on a particular filesystem", No, project quota works exactly like user and group quotas - every file in a project group has the same project ID stored in the inode, just like uid and gid are stored in the inode. They do not rely on directory structure at all, and you can add any file to a project anywhere in the filesystem simply by changing it's project ID. Project quotas can be used to -implement- directory tree quotas because there is another flag in the inode that tells directories that children should inherit the projid of the parent directory at creation time. That's the actual feature that allows project quotas to be used for directory tree quotas - it's entirely independent of the basic functionality of accounting and enforcing project quotas based on the projid in each inode. That's why it is not at all clear how bind mounts should be treated. On one hand they should be treated identically to user and group quotas, and on the other hand bind mounts can completely screw up directory tree quotas. > and I would argue that, > regardless of bindmounts, / is never a subdirectory of /foo, and > this is where I think the change in behaviour should be. You're attempting to cross recursive bind mounts with directory tree quota and worse, pointing the bind mount inside the directory tree to a parent directory outside the directory tree the quota applies to. IOWs, your directory structure disappears up it's own fundamental orifice in a manner that is very difficult to detect (did Oroborus know that it was eating it's own tail?). As such I don't think there is a sane set of semantics that we can apply consistently in the XFS code in both userspace and kernel code when it comes to directory tree quotas and bind mounts. The simple answer is: Just Don't Do It. > There's > also the somewhat-grey area of how 'project -C' should behave, and I > suppose the simplest and most sensible answer there is "however > 'project -s' and 'project -c' behave", as that's both at least > somewhat sensible and the least likely to confuse people. I'd be > happy to go digging at find at some point soon. Like I said above, there's also consistency with every other application that does traversal for accounting purposes (e.g. du). If you want to avoid traversals moving across bind mounts (especially recursive bind mounts), I think we need a syscall flag similar to AT_SYMLINK_NOFOLLOW for the kernel to detect and prevent such traversal in a consistent manner. As such, that's not a project quota problem - that's a generic, VFS behaviour issue. That's where I'd recommend trying to solve the bind mount traversal problem, not hack something into xfs_quota.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
