Re: btrfs-progs reports nonsense scrub status

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, May 9, 2020 at 4:15 AM Andrew Pam <andrew@xxxxxxxxxxxxxx> wrote:
>
> $ uname -a
> Linux RainbowDash 5.7.0-050700rc4-generic #202005051752 SMP Tue May 5
> 21:56:32 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
>
> After a couple of cancel/resumes here we are again:


OK I didn't previously pick up on the fact that you're cancelling a
scrub. Suspending. Then resuming.

Things to verify:

1. That a scrub started, and allowed to finish without any
interruption, does finish. This is the only experience I have, but I'm
wondering whether you've tried this just to eliminate the possibility
of some weird multiple device scrub bug; or possibly something unique
about your file system state.

2. That a scrub started, then cancelled, then resumed, also does
finish (or not).

3. That a scrub started, then cancelled, then suspend-to-RAM, then
resumed, also does finish (or not).

The distinction between (2) and (3) is system sleep. Is this strictly
a resume scrub bug. Or is there something about suspend that causing
state to be lost?

And a low priority (3b) variation might be suspend-to-disk; but this
is not very well supported anyway, in particular UEFI Secure Boot
enabled systems due to hibernation lockdown policy being common these
days.

-- 
Chris Murphy



[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux