On Mon, Dec 04, 2023 at 12:52:14PM -0800, Darrick J. Wong wrote: > > > > > - xchk_ilock(sc, XFS_ILOCK_EXCL); > > > > > if (error == -ECANCELED) > > > > > error = 0; > > > > > if (!xchk_fblock_process_error(sc, XFS_DATA_FORK, > > > > > > > > What is the replacement for this lock? The call in xrep_quota_item? > > > > > > The replacement is the conditional re-lock at the start of xrep_quota. > > > > Hmm. but not all scrub calls do even end up in the repair callbacks, > > do they? Ok, I guess the xchk_iunlock call in xchk_teardown would have > > just released it a bit later and we skip the cycle. Would have been > > a lot easier to understand if this was in a well-explained > > self-contained patch.. > > How about I not remove the xchk_ilock call, then? Repair is already > smart enough to take the lock if it doesn't have it, so it's not > strictly necessary for correct operation. No, please keep this hunk. As I said I would have preferred to have it in a separate hunk to understand it, but it understand it now, and it does seems useful.
