From: Dave Chinner <david@fromorbit.com>
To: Paul Nienaber <phox@uvic.ca>
Cc: xfs@oss.sgi.com
Subject: Re: xfs_quota: bug: traverses bind mountpoints
Date: Fri, 8 Jul 2011 18:01:35 +1000 [thread overview]
Message-ID: <20110708080135.GH1026@dastard> (raw)
In-Reply-To: <4E168C16.6000408@uvic.ca>
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@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2011-07-08 8:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-07 20:46 xfs_quota: bug: traverses bind mountpoints Paul Nienaber
2011-07-08 3:23 ` Dave Chinner
2011-07-08 4:48 ` Paul Nienaber
2011-07-08 8:01 ` Dave Chinner [this message]
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=20110708080135.GH1026@dastard \
--to=david@fromorbit.com \
--cc=phox@uvic.ca \
--cc=xfs@oss.sgi.com \
/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