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