linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc MERLIN <marc@merlins.org>
To: "Holger Hoffstätte" <holger.hoffstaette@googlemail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Better handling of stale scrub status
Date: Sat, 31 May 2014 14:54:24 -0700	[thread overview]
Message-ID: <20140531215424.GG12384@merlins.org> (raw)
In-Reply-To: <pan.2014.05.20.15.30.48@googlemail.com>

On Tue, May 20, 2014 at 03:30:48PM +0000, Holger Hoffstätte wrote:
> As Marc Merlin recently wrote in his blog [1] scrub can sometimes leave a 
> stale state file behind, making cancel/resume complain. I took a peek at 
> the code and found most of the scrub state file handling fairly 
> straightforward, so before I go off and start hacking, what would a 
> better behaviour look like?
> 
> - delete the stale file?
> - fix the file by setting the "finished" flag?
> - something else entirely?

So while writing the workaround I was also indeed thinking we should
just fix the tool, I just haven't had time to look at it myself yet.

Basically once you have a way to confirm that indeed there is no scrub
running, I'd say the best is to set the finished flag, as if someone has
cancelled the scrub before shutting down the machine.

> I currently lean towards fixing (and not printing an error?), but maybe 
> someone else has different ideas about how this should be handled.
> Any suggestions welcome..

Yeah, it's a spurious error, auto fixing is the right solution.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/                         | PGP 1024R/763BE901

      reply	other threads:[~2014-05-31 21:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-20 15:30 Better handling of stale scrub status Holger Hoffstätte
2014-05-31 21:54 ` Marc MERLIN [this message]

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=20140531215424.GG12384@merlins.org \
    --to=marc@merlins.org \
    --cc=holger.hoffstaette@googlemail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).