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 2:33 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
>
> 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).


I just tried all three of these on my laptop, which has NVMe and
5.7.0-0.rc4.1.fc33.x86_64+debug. And they all complete, with no odd
reporting in user space for ETA, and progress seems normal.

I do see this in dmesg, which I think coincides with the cancel/abort
[98580.937332] BTRFS info (device nvme0n1p7): scrub: not finished on
devid 1 with status: -125

I don't know how the kernel and user space communicate scrub progress.
I don't see anything in sysfs.

When you see this problem manifesting (no progress being made) the
/home file system is otherwise working normally? You can read and
write files OK?


-- 
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