scrub problem

scrub problem

[Johan Kröckel]

The scrub is neither cancelable not stoppable. What is the problem?

[root@host ]# btrfs scrub status ./
scrub status for XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX
scrub started at Thu Feb 19 12:41:22 2015, running for 16964 seconds
total bytes scrubbed: 1.56TiB with 0 errors
[root@host ]# btrfs scrub cancel ./
ERROR: scrub cancel failed on ./: not running
[root@host ]# btrfs scrub start ./
ERROR: scrub is already running.
To cancel use 'btrfs scrub cancel ./'.
To see the status use 'btrfs scrub status [-d] ./'.

Re: scrub problem

[Bob Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 20/02/15 19:59, Johan Kröckel wrote:
> The scrub is neither cancelable not stoppable. What is the 
> problem?
> 
> [root@host ]# btrfs scrub status ./ scrub status for 
> XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX scrub started at Thu Feb 19 
> 12:41:22 2015, running for 16964 seconds total bytes scrubbed: 
> 1.56TiB with 0 errors [root@host ]# btrfs scrub cancel ./ ERROR: 
> scrub cancel failed on ./: not running [root@host ]# btrfs scrub 
> start ./ ERROR: scrub is already running. To cancel use 'btrfs 
> scrub cancel ./'. To see the status use 'btrfs scrub status [-d] 
> ./'. --

If the local state file used to track scrub history has become
desynchronized, fix it by editing the file

/var/lib/btrfs/scrub.status.0b07b829-9a0e-44ab-89ee-14b36a45199e

(the last bit of the filename is the filesystem uuid)

Look for a line that ends with "finished:0" and change it to say
"finished:1"

Bob
- -- 
Bob Williams
System:  Linux 3.16.7-7-desktop
Distro:  openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3
Uptime:  06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlTnoSUACgkQ0Sr7eZJrmU75sQCcDTJvEufEFVaO8hgHp5SC81Lr
DUwAn2rKiCiyu7k0/6svdfhmlbFpn12B
=/2xH
-----END PGP SIGNATURE-----

Re: scrub problem

[Robert White]

On 02/20/2015 01:03 PM, Bob Williams wrote:
> /var/lib/btrfs/scrub.status.0b07b829-9a0e-44ab-89ee-14b36a45199e
>
> (the last bit of the filename is the filesystem uuid)
>
> Look for a line that ends with "finished:0" and change it to say
> "finished:1"

Why does this data item even exist? The filesystem/kernel should know 
whether a scrub is ongoing. Isn't is universally cheaper to do the 
single IOCTL to ask the kernel whether a scrub is ongoing compared to 
the open-and-parse of this file?

Re: scrub problem

[Anand Jain]

On 02/23/2015 02:26 AM, Robert White wrote:
> On 02/20/2015 01:03 PM, Bob Williams wrote:
>> /var/lib/btrfs/scrub.status.0b07b829-9a0e-44ab-89ee-14b36a45199e
>>
>> (the last bit of the filename is the filesystem uuid)
>>
>> Look for a line that ends with "finished:0" and change it to say
>> "finished:1"
>
> Why does this data item even exist? The filesystem/kernel should know
> whether a scrub is ongoing. Isn't is universally cheaper to do the
> single IOCTL to ask the kernel whether a scrub is ongoing compared to
> the open-and-parse of this file?

good point. I wished btrfs activities/status are host independent. It 
helps in SAN configs.

-Anand

> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: scrub problem

[Calvin Walton]

On Fri, 2015-02-20 at 20:59 +0100, Johan Kröckel wrote:
> The scrub is neither cancelable not stoppable. What is the problem?
>
> [ root@host]# btrfs scrub status ./
> scrub status for XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX
> scrub started at Thu Feb 19 12:41:22 2015, running for 16964 seconds
> total bytes scrubbed: 1.56TiB with 0 errors
> [ root@host]# btrfs scrub cancel ./
> ERROR: scrub cancel failed on ./: not running
> [ root@host]# btrfs scrub start ./
> ERROR: scrub is already running.
> To cancel use 'btrfs scrub cancel ./'.
> To see the status use 'btrfs scrub status [-d] ./'.

You don't say here which version of btrfs-progs you are using...

As Bob said, this issue is caused by a desynchronization between the
state file on the drive and the kernel state. However, code was added
to btrfs-progs 3.17 to detect and correct this condition.

I'd suggest updating your btrfs-progs.

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