Re: [PATCH v2 2/3] xfs: transaction subsystem quiesce mechanism

From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH v2 2/3] xfs: transaction subsystem quiesce mechanism
Date: Wed, 7 Apr 2021 07:36:37 -0400	[thread overview]
Message-ID: <YG2ZRXp/vPXlvpcB@bfoster> (raw)
In-Reply-To: <20210407080041.GB3363884@infradead.org>

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