Re: xfs_scrub: call for testing

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Mon, Feb 05, 2018 at 10:55:22AM -0600, Eric Sandeen wrote:
> 
> 
> On 2/5/18 10:44 AM, Darrick J. Wong wrote:
> >>> root@bareos16:~# ./xfs_scrub /mnt/raid/
> >>> EXPERIMENTAL xfs_scrub program in use! Use at your own risk!
> >>> Error: /mnt/raid: Kernel metadata scrubbing facility is not available.
> >>> Info: /mnt/raid: Scrub aborted after phase 1.
> >>> /mnt/raid: 2 errors found.
> >> Yup.  TBH I'm not a fan of listing "your kernel can't scrub" as
> >> "errors found."  I think we should find a way around that.
> > What do you mean by that?
> > 
> > --D
> > 
> 
> When people run a tool like scrub and they see "errors found"
> at the end of the run, I think it's very easy to have that register
> as "filesystem errors found" which is not the case here.
> 
> If a kernel can't do scrub at all, "2 errors found" is a confusing
> message - I'd rather find a way to not conflate filesystem
> errors with operational errors (or simply missing capabilities).
> 
> As a first cut I might suggest that if required capabilities for
> the requested action were not found, we should not even print
> the "errors found" line, just the informational text.  i.e.
> just reset the error counters in that specific case before exit.

Yeah.  As you and I have been batting around on IRC all day, I've
changed most of the non-fs-corruption str_warn/str_error calls into
str_info since they pretty much all abort the scrub anyway (which is
itself recorded as a runtime error).

--D

> -Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html