On Wed, Apr 07, 2021 at 02:24:55PM +0100, Christoph Hellwig wrote: > On Wed, Apr 07, 2021 at 07:36:37AM -0400, Brian Foster wrote: > > 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. > > I'm currently testing a series that just ignores disabling of accounting > and logs a message and that seems to do ok so far. I'll check if > clearing the on-disk flags as well could work out even better. While I was rejiggering the inode walk parts of quotaoff I did wonder why it even mattered to dqpurge the affected dquots **now**. With patch 1 applied, we could just turn off the _ACTIVE flag and let reclaim erase them slowly. --D
