Re: [PATCH 11/11] xfs_scrub: create a new category for unfixable errors

[Eric Sandeen <sandeen@sandeen.net>]

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@oracle.com>
>>>
>>> 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@oracle.com>
>>
>> <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