On Wed, Apr 07, 2021 at 09:00:41AM +0100, Christoph Hellwig wrote: > On Tue, Apr 06, 2021 at 10:42:37AM -0400, Brian Foster wrote: > > The updated quotaoff logging algorithm depends on a runtime quiesce > > of the transaction subsystem to guarantee all transactions after a > > certain point detect quota subsystem changes. Implement this > > mechanism using an internal lock, similar to the external filesystem > > freeze mechanism. This is also somewhat analogous to the old percpu > > transaction counter mechanism, but we don't actually need a counter. > > Stupid question that already came up when seeing the replies to my > s_inodes patch: Why do we even care about quotaoff? Is there any > real life use case for quotaoff, at least the kind that disables > accounting (vs enforcement)? IMHO we spend a lot of effort on this > corner case that has no practical value, and just removing support > for quotaoff might serve us much better in the long run. > Hm, fair point. I think the historical fragility and complexity makes it reasonable to question whether it's worth continued support. Looking back through my notes, ISTM that the original report of the log reservation deadlock came from fstests, so not necessarily an end user report. I'm not aware of any real user reports around quotaoff, but then again it's fairly boring functionality that probably just works most of the time. It's kind of hard to surmise external dependencies from that alone. Personally, I'd probably have to think about it some more, but initially I don't have any strong objection to removing quotaoff support. More practically, I suspect we'd have to deprecate it for some period of time given that it's a generic interface, has userspace tools, regression tests, etc., and may or may not have real users who might want the opportunity to object (or adjust). Though perhaps potentially avoiding that mess is what you mean by "... disables accounting vs. enforcement." I.e., retain the interface and general ability to turn off enforcement, but require a mount cycle in the future to disable accounting..? Hmm... that seems like a potentially nicer/easier path forward and a less disruptive change. I wonder even if we could just (eventually) ignore the accounting disablement flags from userspace and if any users would have reason to care about that change in behavior. Brian
