On Fri, Oct 14, 2022 at 09:49:11AM +1100, Dave Chinner wrote: > On Sun, Oct 02, 2022 at 11:19:55AM -0700, Darrick J. Wong wrote: > > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > > > If we tried to repair something but the repair failed with -EDEADLOCK or > > -EAGAIN, that means that the repair function couldn't grab some resource > > Nothing should fail with EAGAIN by this point? Right. > > it needed and wants us to try again. If we try again (with TRY_HARDER) > > but still can't do it, exit back to userspace, since xfs_scrub_metadata > > requires xrep_attempt to return -EAGAIN. > > -EDEADLOCK, not -EAGAIN? That part of the message confused me too. How about this revision? "If we tried to repair something but the repair failed with -EDEADLOCK, that means that the repair function couldn't grab some resource it needed and wants us to try again. If we try again (with TRY_HARDER) but still can't get all the resources we need, the repair fails and errors remain on the filesystem. "Right now, repair returns the -EDEADLOCK to the caller, which passes it up to userspace without copying the xfs_scrub_metadata structure back to userspace. This is very confusing for userspace since xfs_scrub merely reports "Resource deadlock would occur" and gives no indication that there are uncorrected errors on the filesystem. Hence we want to return 0 here so that the ioctl code copies the CORRUPTION flag back to userspace." Clearer, I hope? --D > > Confused. > > -Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx