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