All of lore.kernel.org
 help / color / mirror / Atom feed
From: Graham Cobb <g.btrfs@cobb.uk.net>
To: "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:19:24 +0000	[thread overview]
Message-ID: <654bf850-65bf-65f5-2ed2-90a0d4058e74@cobb.uk.net> (raw)
In-Reply-To: <CADkZQakAhrRHFeHPJfne5oLT81qFGbzNAiUoqb3r0cxVSuHTNg@mail.gmail.com>

On 09/01/2020 10:03, 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?

Coincidentally, I noticed exactly the same thing yesterday!

I have just run a quick test. It works with kernel 4.19 but doesn't with
kernel 5.3. This is using exactly the same version of btrfs-progs:
v5.3.1 (I just rebooted the same system with an old kernel to check).

As Sebastian says, the symptom is that the file in /var/lib/btrfs shows
all fields as zero after the cancel (although "cancelled" and "finished"
are both 1). In particular, last_physical is zero so the scrub always
resumes from the beginning.

With the old kernel, the file in /var/lib/btrfs correctly has all the
values filled in after the cancel so the scrub can be resumed.

Graham

  reply	other threads:[~2020-01-09 10:19 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 [this message]
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
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=654bf850-65bf-65f5-2ed2-90a0d4058e74@cobb.uk.net \
    --to=g.btrfs@cobb.uk.net \
    --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.