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? 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
