From: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
To: dsterba@suse.cz,
"Holger Hoffstätte" <holger@applied-asynchrony.com>,
linux-btrfs@vger.kernel.org
Subject: Re: Scrub resume regression
Date: Fri, 17 Jan 2020 10:59:48 -0500 [thread overview]
Message-ID: <20200117155948.GM13306@hungrycats.org> (raw)
In-Reply-To: <20200116140227.GV3929@twin.jikos.cz>
[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]
On Thu, Jan 16, 2020 at 03:02:27PM +0100, David Sterba wrote:
> On Wed, Jan 15, 2020 at 02:10:42PM +0100, Holger Hoffstätte wrote:
> > On 1/15/20 1:51 PM, David Sterba wrote:
> > >> It is important that scrub always returns the stats, even when it
> > >> returns an error. This is critical for cancel, as that is how
> > >> cancel/resume works, but it should also apply in case of other errors so
> > >> that the user can see how much of the scrub was done before the fatal error.
> > >
> > > That's something we need to document in code and perhaps in the manual
> > > pages too.
> >
> > Isn't the real problem that cancel does not actually mean cancel,
> > but rather also implies "..and maybe continue"? IMHO cancel should cancel
> > (and say how much work was performed), while the intention to resume should
> > be called e.g. "pause". This makes the behaviour clear and prevents
> > accidental semantic overlap.
>
> We can add 'pause', but for backward compatibility, cancel has to stay
> as is. I personally think that saving the last position after cancel is
> not a big deal. With 'pause' it will be less confusing for users and
> will have also parity with balance commands.
>
> start - pause - resume
> start - cancel
>
> One difference is that cancelling balance will also delete the state
> (stored inside the filesystem metadata). If scrub start follows cancel,
> the state is reset at the beginning. I'm not sure if adding an extra
> option eg. 'scrub cancel --reset' is worth.
Currently 'scrub cancel' doesn't reset the state, so existing scripts will
be broken if 'cancel' is not exactly the same as 'pause'. I have such
scripts, they call 'cancel' and 'resume' blindly according to load or
maintenance window boundaries, and they leave it to btrfs userspace to
sort out whether any new work should be done.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2020-01-17 15:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-15 9:03 Scrub resume regression Graham Cobb
2020-01-15 9:33 ` Filipe Manana
2020-01-15 11:55 ` Graham Cobb
2020-01-15 12:51 ` David Sterba
2020-01-15 13:10 ` Holger Hoffstätte
2020-01-15 21:02 ` Sebastian Döring
2020-01-16 14:02 ` David Sterba
2020-01-17 15:59 ` Zygo Blaxell [this message]
2020-01-17 18:39 ` Chris Murphy
2020-01-17 19:39 ` Graham Cobb
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=20200117155948.GM13306@hungrycats.org \
--to=ce3g8jdj@umail.furryterror.org \
--cc=dsterba@suse.cz \
--cc=holger@applied-asynchrony.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 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.