Re: quotaoff, transaction quiesce, and dquot logging

[Brian Foster <bfoster@redhat.com>]

On Thu, Sep 10, 2020 at 08:59:37AM +1000, Dave Chinner wrote:
> On Wed, Sep 09, 2020 at 11:00:35AM -0400, Brian Foster wrote:
> > On Wed, Sep 09, 2020 at 07:07:20AM +1000, Dave Chinner wrote:
> > > On Tue, Sep 08, 2020 at 11:56:02AM -0400, Brian Foster wrote:
> > > > - xfs_trans_mod_dquot_byino() (via xfs_bmapi_write() -> ... -> xfs_bmap_btalloc() ->
> > > >   xfs_bmap_btalloc_accounting()) skips accounting the allocated blocks
> > > >   to the group dquot because it is not enabled
> > > 
> > > Right, the reservation functions need to do the same thing as
> > > xfs_trans_mod_dquot_byino(). I simply missed that for the
> > > reservation functions. i.e. Adding the same style of check like:
> > > 
> > > 	if (XFS_IS_UQUOTA_ON(mp) && udq)
> > > 
> > > before doing anything with user quota will avoid this problem as
> > > we are already in transaction context and the UQUOTA on or off state
> > > will not change until the transaction ends.
> > > 
> > > > concept itself. It seems like we should be able to head this issue off
> > > > somewhere in this sequence (i.e., checking the appropriate flag before
> > > > the dquot is attached), but it also seems like the quotaoff start/end
> > > > plus various quota flags all fit together a certain way and I feel like
> > > > some pieces of the puzzle are still missing from a design standpoint...
> > > 
> > > I can't think of anything that is missing - the quota off barrier
> > > gives us an atomic quota state change w.r.t. running transactions,
> > > so we just need to make sure we check the quota state before joining
> > > anything quota related to a transaction rather than assume that the
> > > presence of a dquot attached to an inode means that quotas are on.
> > > 
> > 
> > This gets back to my earlier questions around the various quota flags.
> > If I trace through the code of some operations, it seems like this
> > approach should work (once this logging issue is addressed, and more
> > testing required of course). However if I refer back to the runtime
> > macro comment:
> > 
> > /*
> >  * Checking XFS_IS_*QUOTA_ON() while holding any inode lock guarantees
> >  * quota will be not be switched off as long as that inode lock is held.
> >  */
> > 
> > This will technically no longer be the case because the updated quotaoff
> > will clear all of the flags before cycling any ilocks and detaching
> > dquots. I'm aware it will drain the transaction subsystem, but does
> > anything else depend on not seeing such a state change with an inode
> > lock held? I haven't seen anything so far that would conflict, but the
> > comment here is rather vague on details.
> 
> Not that I know of. I would probably rewrite the above comment as:
> 
> /*
>  * Checking XFS_IS_*QUOTA_ON() while inside an active quota modifying
>  * transaction context guarantees quota will be not be switched until after the
>  * entire rolling transaction chain is completed.
>  */
> 
> To clarify the situation. Having the inode locked will now only
> guarantee that the dquot will not go away while the inode is locked,
> it doesn't guarantee that quota will not switch off any more.
> 

Ok, that makes more sense.

> > Conversely, if not, I'm wondering whether there's a need for an ACTIVE
> > flag at all if we'd clear it at the same time as the ACCT|ENFD flags
> > during quotaoff anyways. It sounds like the answer to both those
> > questions is no based on your previous responses, perhaps reason being
> > that the transaction drain on the quotaoff side effectively replaces the
> > need for this rule on the general transaction side. Hm? Note that I
> > wouldn't remove the ACTIVE flag immediately anyways, but I want to make
> > sure the concern is clear..
> 
> Yes, I think you are right - the ACTIVE flag could probably away as
> it doesn't really play a part in the quota-off dance anymore. We'd
> still need the IS_QUOTA_ON() checks, but they'd look at ACCT|ENFD
> instead...
> 

Ack. Thanks for the sanity check.

Brian

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
>