From: Graham Cobb <g.btrfs@cobb.uk.net>
To: "Holger Hoffstätte" <holger@applied-asynchrony.com>,
"Sebastian Döring" <moralapostel@gmail.com>,
linux-btrfs@vger.kernel.org
Subject: Re: btrfs scrub: cancel + resume not resuming?
Date: Thu, 9 Jan 2020 10:52:49 +0000 [thread overview]
Message-ID: <71add409-04ad-c6be-4f4f-5eec4ffb167c@cobb.uk.net> (raw)
In-Reply-To: <b031f351-2a9c-83b3-7e4b-ac15791d96e6@applied-asynchrony.com>
On 09/01/2020 10:34, Holger Hoffstätte wrote:
> On 1/9/20 11:03 AM, Sebastian Döring wrote:
>> Maybe I'm doing it entirely wrong, but I can't seem to get 'btrfs
>> scrub resume' to work properly. During a running scrub the resume
>> information (like data_bytes_scrubbed:1081454592) gets written to a
>> file in /var/lib/btrfs, but as soon as the scrub is cancelled all
>> relevant fields are zeroed. 'btrfs scrub resume' then seems to
>> re-start from the very beginning.
>>
>> This is on linux-5.5-rc5 and btrfs-progs 5.4, but I've been seeing
>> this for a while now.
>>
>> Is this intended/expected behavior? Am I using the btrfs-progs wrong?
>> How can I interrupt and resume a scrub?
>
> Using 5.4.9+ (all of btrfs-5.5) and btrfs-progs 5.4 I just tried and
> it still works for me (and always has):
>
> $btrfs scrub start /mnt/backup
> scrub started on /mnt/backup, fsid d163af2f-6e03-4972-bfd6-30c68b6ed312
> (pid=25633)
>
> $btrfs scrub cancel /mnt/backup
> scrub cancelled
>
> $btrfs scrub resume /mnt/backup
> scrub resumed on /mnt/backup, fsid d163af2f-6e03-4972-bfd6-30c68b6ed312
> (pid=25704)
>
> ..and it keeps munching away as expected.
Can you check that the resume has really started from where the scrub
was cancelled? What I (and, I think, Sebastian) are seeing is that the
resume "works" but actually restarts from the beginning.
For example, something like:
btrfs scrub start /mnt/backup
sleep 300
btrfs scrub status -R /mnt/backup
btrfs scrub cancel /mnt/backup
btrfs scrub resume /mnt/backup
sleep 100
btrfs scrub status -R /mnt/backup
and check the last_physical in the second status is higher than the one
in the first status.
next prev parent reply other threads:[~2020-01-09 10:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-09 10:03 btrfs scrub: cancel + resume not resuming? Sebastian Döring
2020-01-09 10:19 ` Graham Cobb
2020-01-09 17:06 ` Graham Cobb
2020-01-09 20:35 ` Graham Cobb
2020-01-13 13:57 ` btrfs scrub: cancel + resume not resuming - kernel regression Graham Cobb
2020-01-09 10:34 ` btrfs scrub: cancel + resume not resuming? Holger Hoffstätte
2020-01-09 10:52 ` Graham Cobb [this message]
2020-01-09 11:05 ` Holger Hoffstätte
2020-01-09 11:13 ` Graham Cobb
2020-01-09 11:16 ` Holger Hoffstätte
2020-01-22 15:52 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=71add409-04ad-c6be-4f4f-5eec4ffb167c@cobb.uk.net \
--to=g.btrfs@cobb.uk.net \
--cc=holger@applied-asynchrony.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=moralapostel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.