Linux-BTRFS Archive on lore.kernel.org
 help / color / Atom feed
From: David Sterba <dsterba@suse.cz>
To: "Holger Hoffstätte" <holger@applied-asynchrony.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Scrub resume regression
Date: Thu, 16 Jan 2020 15:02:27 +0100
Message-ID: <20200116140227.GV3929@twin.jikos.cz> (raw)
In-Reply-To: <5aa23833-d1e2-fe6f-7c6e-f366d3eccbe3@applied-asynchrony.com>

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.

  parent reply index

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-15  9:03 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 [this message]
2020-01-17 15:59       ` Zygo Blaxell
2020-01-17 18:39         ` Chris Murphy
2020-01-17 19:39           ` Graham Cobb

Reply instructions:

You may reply publically 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=20200116140227.GV3929@twin.jikos.cz \
    --to=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

Linux-BTRFS Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-btrfs/0 linux-btrfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-btrfs linux-btrfs/ https://lore.kernel.org/linux-btrfs \
		linux-btrfs@vger.kernel.org
	public-inbox-index linux-btrfs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-btrfs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git