On 2/5/18 9:10 AM, Emmanuel Florac wrote:
> Le Fri, 2 Feb 2018 15:36:33 -0600
> Eric Sandeen <sandeen@xxxxxxxxxxx> écrivait:
>
>> I'd really value feedback on scrub as it stand at this point -
>> Is the documentation clear? Is the output correct? Do the
>> tool's arguments make sense? Does it segfault? Does it
>> find real errors? Does it crash your kernel? Does it
>> eat your data?
>
> Wouldn't it be better to remove the parts about repairing the
> filesystem in the documentation? The man page states that it *can't*
> repair the filesystem, but nonetheless explains under which
> circumstances it *won't* be able to repair (in some theoretical future
> version with repair capabilities, I suppose). Ditto with the -n and -y
> option, I suppose they're both basically noop at the moment? That's
> quite unclear what it actually does.
I'll take another look at the manpage. The userspace tool today /can/
do some degree of optimization or repair if the kernel supports it,
so I was reluctant to suggest removing all such language.
So, "-n" is not a no-op, it's a check-only ("scrub") pass vs. the default
no-argument action of "optimizing," or the extra -y action which would repair.
If that's not all clear, I'd appreciate suggestions to clean it up.
> Regarding FITRIM for flash storage, I think most people refers to it as
> "TRIM", not the ioctl name FITRIM. Using "TRIM" would probably be more
> understandable IMO.
Fair point, thanks.
> Because I'm such a funny boy, I just wanted to see what happens when
> running xfs_scrub on an unsupported kernel. On both a 4.14.x and a
> 3.18.x it seems about right:
>
> 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.
> I don't have any system running 4.15 to test its effects, but I'll do
> as soon as possible.
Cool, thanks.
-Eric
Attachment:
signature.asc
Description: OpenPGP digital signature
