On 10/21/19 3:29 PM, Darrick J. Wong wrote: > On Mon, Oct 21, 2019 at 02:45:17PM -0500, Eric Sandeen wrote: >> On 9/25/19 4:37 PM, Darrick J. Wong wrote: >>> From: Darrick J. Wong <darrick.wong@xxxxxxxxxx> >>> >>> There's nothing that xfs_scrub (or XFS) can do about media errors for >>> data file blocks -- the data are gone. Create a new category for these >>> unfixable errors so that we don't advise the user to take further action >>> that won't fix the problem. >>> >>> Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> >> >> <bikeshed> >> What if unfixable_errors was a subcounter for total errors_found? >> Would that simplify all the places that need to check both? > > Unfixable errors need to be tracked separately because we advise the > user on what xfs tool to run next if @errors_found (aka corruption > errors) or @runtime_errors are greater than zero. There is no xfs > utility that you can run to fix things like file data loss. > > (I mean, you can fix the unfixable by restoring from backups, maybe we > should say that?) I understand why it needs to be tracked separately. What I was suggesting was that every error (fixable or not), bumps errors_found. Unfixable errors also bump unfixable_errors as a subset of that. That way every time you want to find out "was there a scrub error?" you don't have to test both ctx->unfixable_errors and ctx->errors_found, and if you add some other subclass of errors later, you don't have to then check even more. When all is done, you can just see if errors_found > unfixable_errors and if so there's something to be done. It's a bikeshed conversation. If you disagree that's fine, just thought I'd propose it. -Eric
