Gregory Farnum <gfarnum@xxxxxxxxxx> writes: > On Mon, Aug 13, 2018 at 6:27 PM, Patrick Donnelly <pdonnell@xxxxxxxxxx> wrote: >> On Fri, Aug 10, 2018 at 9:15 AM, Gregory Farnum <gfarnum@xxxxxxxxxx> wrote: >>> This needs to be consistent across kernel- and user-space, and I >>> believe we settled on continuing to allow cross-quota links (despite >>> the accounting issues) >> >> The current behavior of the user-space client is to disallow links >> across quota boundaries (at least for rename). See also: >> http://tracker.ceph.com/issues/24305 >> >>>because otherwise the introduction of new >>> quotas makes it incredibly messy. Unless I missed a change, Zheng? >> >> How does it make new quotas messy? > > If we add a new "quota realm" that interrupts existing hard links, > what would we do? Just grandfather them in, and deal with the mess, > but treat them like a special case we mostly ignore? Fully examine the > tree for hard links and reject the new quota realm if it splits one? > Fully support hard links across boundaries, but still block new > cross-quota-realm hard links so users can't get themselves *more* > confused? > > I'd forgotten that CephFS disallows renames across quota boundaries > now. That does seem like another thing we should be generally > consistent about. Does anybody remember why we did that? The kernel client has the same behavior, and my assumption at that time was that the fuse client was simply being consistent with what other filesystems do. For example, xfs and ext4 don't allow renames when using project quotas (if using project inheritance). Cheers, -- Luis > Was it just in preparation for the "subvolume" behavior that we > eventually decided against? The EXDEV was introduced in the initial > quota work from the Kylin et al group (hash > bbfeaaea53f1cee3d798debc790c37ff5a5276bc). > > I think my preference would be to just allow the hard links *and* > rename if the user has permission over both trees. But if that's not > acceptable, we should enforce that condition on the MDS, not (at least > not only) in the clients. > -Greg >
