On Wed, May 10, 2017 at 10:46 PM, Peter Maloney <peter.maloney@xxxxxxxxxxxxxxxxxxxx> wrote: > On 05/10/17 09:03, John Spray wrote: >> On Tue, May 9, 2017 at 5:47 PM, Gregory Farnum <gfarnum@xxxxxxxxxx> wrote: >>> On Fri, May 5, 2017 at 7:57 AM, Sage Weil <sage@xxxxxxxxxxxx> wrote: >>>> On Fri, 5 May 2017, Dan van der Ster wrote: >>>>> On Fri, May 5, 2017 at 4:36 PM, Dan van der Ster <dan@xxxxxxxxxxxxxx> >>>>> wrote: >>>>>> Hi all, >>>>>> >>>>>> It would be really nice if for Luminous client quotas were always >>>>>> enabled -- it should be impossible to disable quota enforcement on the >>>>>> client side. >>>>>> >>>>>> From the looks of things, the patch to remove client_quota and >>>>>> client_quota_df would be trivial. >>>>>> Is there some reason we need to leave that optional? >>>>> PR: 14978 >>>> This seems reasonable to me. Client can of course run modified code so >>>> it's not really "secure" in that sense but it's certainly inconvenient to >>>> circumvent. >>> I'm sure John will comment on this once he gets back from vacation, but >>> there were some reasons not to enable it by default when this was discussed >>> by the team last fall. I think it was combined concern about the lack of >>> server-side enforcement and (more importantly) not wanting to provide >>> default experiences which differ across the userspace and kernel clients. >> client_quota has been true by default in master for about a year -- I >> think at this stage the question is just whether it's important to >> enable people to disable them, where disabling is really only sensible >> in cases where someone e.g. hits a quota bug and wants to skip the >> code. >> >> My view is that the simplicity of support (not worrying about users >> disabling quota and then complaining about it not working) is a good >> enough motivator to remove the setting. Making it less convenient for >> naughty clients to circumvent quota is a bonus. >> >> Commenting on PR.... >> >> John >> > I don't think it was mentioned yet...but isn't a pool quota mandatory? > If so, you could use that for those naughty clients. > > I'm using cephfs with a pool quota and found the client just hangs > waiting for space if the pool quota is hit, and ceph -s gets a warning. > That's less than desirable, but if combined with the client quota, it > ought to be friendly. > We don't have a unique pool per user (where user in our case == Manila share). OTOH, quota per RADOS namespace would be usable, if such a thing were implementable. Cheers, Dan -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
