Re: File system stuck in scrub

[Calvin Walton <calvin.walton@kepstin.ca>]

Hi,

On Mon, 2014-08-11 at 08:12 -0700, Nikolaus Rath wrote:
> Hello,
> 
> I started a scrub of one of my btrfs filesystem and then had to 
> restart
> the system. `systemctl restart` seemed to terminate all processes, 
> but
> then got stuck at the end. The disk activity led was still flashing
> rapidly at that point, so I assume that the active scrub was 
> preventing
> the reboot (is that a bug or a feature?).
This sounds like a bug - I know that e.g. the rebalance operation is 
designed so that you can shutdown/reboot during the operation, and it 
will complete following a reboot. But I'm not familiar with the code 
in question.

> In any case, I could not wait for that so I power cycled. But now my
> file system seems to be stuck in a scrub that can neither be 
> completed
> nor cancelled:
> 
> $ sudo btrfs scrub status /home/nikratio/
> scrub status for 8742472d-a9b0-4ab6-b67a-5d21f14f7a38
>         scrub started at Sun Aug 10 18:36:43 2014, running for 1562 
> seconds
>         total bytes scrubbed: 209.97GiB with 0 errors
> 
> $ date
> Sun Aug 10 22:00:44 PDT 2014
> 
> $ sudo btrfs scrub cancel /home/nikratio/
> ERROR: scrub cancel failed on /home/nikratio/: not running
> 
> $ sudo btrfs scrub start /home/nikratio/
> ERROR: scrub is already running.
> To cancel use 'btrfs scrub cancel /home/nikratio/'.
> To see the status use 'btrfs scrub status [-d] /home/nikratio/'.
My guess is that this is a mismatch between some state stored by the 
userspace tools and the state in the kernel. One of the things you can 
try is to delete the files /var/lib/btrfs/scrub.status.* - that will 
force the btrfs tools to get the current status from the kernel (you 
will lose some statistics and scrub history.)

Running 'btrfs scrub status /home/nikratio/' after this should simply 
say 'no stats available', and you can start a new scrub later if you 
like.

> I then figured that maybe I need to run btrfsck. This gave the 
> following
> output:
As long as you didn't use --repair, this shouldn't break anything... 
Note that btrfs has to be run on an *unmounted* filesystem to give 
useful results.

>  * Is it more risky to leave the above errors uncorrected, or to run
>    btrfsck with --repair?
There probably aren't any issues on the filesystem that the runtime 
btrfs code can't handle. Don't run with --repair, at least not yet.

> 
> 
> I'm using kernel 3.14.
> 
> Thanks!
> -Nikolaus
> 
> 

-- 
Calvin Walton <calvin.walton@kepstin.ca>