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