Implemented zpool scrub pause/resume #6167

alek-p · 2017-05-25T13:18:28Z

Currently, there is no way to pause a scrub. Pausing may
be useful when the pool is busy with other I/O to preserve
bandwidth.

Description

This patch adds the ability to pause and resume scrubbing.
This is achieved by maintaining a persistent on-disk scrub state.
While the state is 'paused' we do not scrub any more blocks.
We do however perform regular scan housekeeping such as
freeing async destroyed and deadlist blocks while paused.

Motivation and Context

Scrub pausing can be an I/O intensive operation and people have been asking for the ability to pause a scrub for a while. This allows one to preserve scrub progress while freeing up bandwidth for other I/O.

How Has This Been Tested?

Unit testing and zfs-tests.

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Performance enhancement (non-breaking change which improves efficiency)
Code cleanup (non-breaking change which makes code smaller or more readable)
Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

My code follows the ZFS on Linux code style requirements.
I have updated the documentation accordingly.
I have read the CONTRIBUTING document.
I have added tests to cover my changes.
All new and existing tests passed.
All commit messages are properly formatted and contain Signed-off-by.
Change has been approved by a ZFS on Linux member.

mention-bot · 2017-05-25T13:18:32Z

@alek-p, thanks for your PR! By analyzing the history of the files in this pull request, we identified @behlendorf, @FransUrbo and @tonyhutter to be potential reviewers.

alek-p · 2017-05-25T14:20:18Z

looks like I missed the makefile update after I renamed zpool_import_scrub_pause_001_pos.ksh. I'll fix that tonight

loli10K · 2017-05-25T15:48:02Z

This patch also adds a -p option to zpool import which allows one to pause scrub instead of resuming it on import.

This seems a suitable fix for #3658

alek-p · 2017-05-25T21:22:36Z

Looks like the problem was something else:

tar: zfs-0.7.0/tests/zfs-tests/tests/functional/cli_root/zpool_import/zpool_import_scrub_pause_001_pos.ksh: file name is too long (max 99); not dumped
tar: Exiting with failure status due to previous errors

I've changed the filename, let's try again...

loli10K · 2017-05-28T10:23:50Z

module/zfs/zfs_ioctl.c

@@ -1683,7 +1684,12 @@ zfs_ioc_pool_scan(zfs_cmd_t *zc)
 	if ((error = spa_open(zc->zc_name, &spa, FTAG)) != 0)
 		return (error);

-	if (zc->zc_cookie == POOL_SCAN_NONE)
+	ASSERT(zc->zc_flags >= POOL_SCRUB_NORMAL &&


Can we be a little more tolerant here and return (SET_ERROR(EINVAL)) instead of ASSERTing zc_flags value?

root@debian-8-zfs:~# stap -g -v -d `which zfs` --ldd \ > -e 'probe process("/lib*/libzfs.so*").function("zpool_scan").call { $cmd = 0xff; }' \ > -c "zpool scrub -p $POOLNAME" Pass 1: parsed user script and 113 library scripts using 94688virt/39056res/5008shr/34604data kb, in 390usr/100sys/1727real ms. Pass 2: analyzed script: 1 probe, 1 function, 0 embeds, 0 globals using 95856virt/41876res/6536shr/35772data kb, in 20usr/0sys/118real ms. Pass 3: using cached /root/.systemtap/cache/dd/stap_dd9957a3d2f294127e57b1abbc2c4bac_2280.c Pass 4: using cached /root/.systemtap/cache/dd/stap_dd9957a3d2f294127e57b1abbc2c4bac_2280.ko Pass 5: starting run. [ 72.776788] Kprobes globally unoptimized [ 72.929149] VERIFY(zc->zc_flags >= POOL_SCRUB_NORMAL && zc->zc_flags < POOL_SCRUB_FLAGS_END) failed [ 72.930278] PANIC at zfs_ioctl.c:1688:zfs_ioc_pool_scan() [ 72.932426] Showing stack for process 2024 [ 72.935176] CPU: 7 PID: 2024 Comm: zpool Tainted: P OE 4.6.4 #3 [ 72.935758] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 72.936396] 0000000000000286 0000000047860cbc ffff8800758a7c20 ffffffff81491063 [ 72.938873] ffffffffc0450268Message from sy 0000000000000698 ffff8800758a7c30 ffffffffc005bd04 [ 72.942586] ffff8800758a7db8 ffffffffc005bdcf 0000000000000007 ffff880000000028 [ 72.943316] Call Trace: [ 72.943551] [<ffffffff81491063>] dump_stack+0x63/0x90 [ 72.943998] [<ffffffffc005bd04>] spl_dumpstack+0x44/0x50 [spl] [ 72.944501] [<ffffffffc005bdcf>] spl_panic+0xbf/0xf0 [spl] [ 72.946604] [<ffffffff81200200>] ? create_object+0x170/0x2f0 [ 72.948138] [<ffffffff81812452>] ? mutex_lock+0x12/0x30 [ 72.950116] [<ffffffffc02e6433>] ? refcount_add_many+0x73/0xf0 [zfs] [ 72.950847] [<ffffffffc02e64c6>] ? zfs_refcount_add+0x16/0x20 [zfs] [ 72.951437] [<ffffffffc030063b>] ? spa_open_ref+0x3b/0x90 [zfs] [ 72.952031] [<ffffffffc02f7b48>] ? spa_open_common+0x2b8/0x4b0 [zfs] [ 72.954031] [<ffffffffc033f916>] zfs_ioc_pool_scan+0xc6/0xe0 [zfs] [ 72.956447] [<ffffffffc0346525>] zfsdev_ioctl+0x635/0x750 [zfs] [ 72.958340] [<ffffffff8117a934>] ? __create_xol_area+0x1a4/0x210 [ 72.960631] [<ffffffff810636fe>] ? arch_uprobe_post_xol+0x6e/0x100 [ 72.962671] [<ffffffff8121ac4d>] do_vfs_ioctl+0x9d/0x5b0 [ 72.964428] [<ffffffffc01e6617>] ? utrace_report_syscall_entry+0x117/0x130 [stap_dd9957a3d2f294127e57b1abbc2c4bac_2021] [ 72.968223] [<ffffffff8121b1d9>] SyS_ioctl+0x79/0x90 [ 72.969048] [<ffffffff81003cf9>] do_syscall_64+0x89/0x180 [ 72.970008] [<ffffffff81814425>] entry_SYSCALL64_slow_path+0x25/0x25

sure, I made the change

behlendorf

A few quick comments.

behlendorf · 2017-06-01T20:45:31Z

cmd/zpool/zpool_main.c

+			size_t len = strlen(ctime(&pause));
+			char cbuf[len];
+			struct tm *p = localtime(&pause);
+			(void) strftime(cbuf, len, "%a %b %e %T %Y", p);


Using strlen(ctime()) as a way to calculate the maximum buffer size for strftime() is a little dangerous since the required buffer size depends on the pattern format specifier. It would be simpler to safer to declare this buffer as say 32 bytes.

behlendorf · 2017-06-01T20:51:36Z

include/sys/dsl_scan.h

-	boolean_t scn_pausing;
+	uint8_t scn_scrub_state;
+	uint64_t scn_scrub_pause_time;
+	boolean_t scn_suspending;


It would be better to move boolean_t scn_suspending before uint64_t scn_scrub_pause_time to make sure this structure is nicely packed.

behlendorf · 2017-06-05T23:48:10Z

cmd/zpool/zpool_main.c

@@ -5737,6 +5743,7 @@ typedef struct scrub_cbdata {
 	int	cb_type;
 	int	cb_argc;
 	char	**cb_argv;
+	uint8_t	cb_scrub_cmd;


I'd suggest using the pool_scrub_cmd_t enum which was introduced so this code can benefit from the type checking.

behlendorf · 2017-06-05T23:54:18Z

cmd/zpool/zpool_main.c

+			struct tm *p = localtime(&pause);
+			(void) strftime(buf, sizeof (buf), "%a %b %e %T %Y", p);
+			(void) printf(gettext("scrub paused since %s; started "
+			    "on %s"), buf, ctime(&start));


This output exceeds the 80 character limit. We're going to need to make this a little more concise or split it over two lines.

behlendorf · 2017-06-06T00:00:32Z

lib/libzfs/libzfs_util.c

@@ -246,6 +247,9 @@ libzfs_error_description(libzfs_handle_t *hdl)
 	case EZFS_POSTSPLIT_ONLINE:
 		return (dgettext(TEXT_DOMAIN, "disk was split from this pool "
 		    "into a new one"));
+	case EZFS_SCRUB_PAUSED:
+		return (dgettext(TEXT_DOMAIN, "scrub currently paused; "
+		    "use 'zpool scrub' to resume scrubbing"));


Exceeds 80 character limit.

ahrens

I took a quick look at this and it seems fine except for the lack of persistence.

ahrens · 2017-06-06T19:34:41Z

include/sys/dsl_scan.h

@@ -107,7 +110,9 @@ typedef enum dsl_scan_flags {
 typedef struct dsl_scan {
 	struct dsl_pool *scn_dp;

-	boolean_t scn_pausing;
+	boolean_t scn_suspending;
+	uint8_t scn_scrub_state;


should this be an enum? this struct is in memory and there aren't many instances of it, so using a larger type is fine.

ahrens · 2017-06-06T19:36:39Z

man/man8/zpool.8

+Pause scrubbing. Scrub progress is periodically synced to disk so if the system
+is restarted or pool is exported during a paused scrub, the scrub will resume
+from the place where it was last checkpointed to disk. To resume a paused scrub
+issue \fBzpool scrub\fR again.


I don't see where the paused-ness is persisted to disk. So when the pool is opened/imported, it will not be paused, even if it was paused before export/reboot (unless you do zpool import -p)? We should at least document that confusing behavior. But I would much prefer to fix it before integrating this.

I think you could either:

add a feature flag and introduce a new dsl_scan_state_t; or

add a new dsl_scan_flags_t, which would be ignored on older software (so if the pool is imported/opened with older software, the scrub would not be paused)

It would be nice to avoid the feature flag and reserve a dsl_scan_flags_t bit for this to avoid potential GRUB compatibility issues.

behlendorf · 2017-06-06T20:02:11Z

@alek-p FYI a rebase on master will resolve the memory leak detected by the kmemleak builder.

alek-p · 2017-06-07T00:33:01Z

thanks for the reviews, I should be able to address these comments in the next couple of days

alek-p · 2017-06-08T23:36:24Z

In the updated patch I've rebased on master and shortened the error messages as much as I could without making them grammatically too ugly. Keep in mind some of the existing ones are also over 80 chars.
I've also modified the patch to take into account the time spent paused so that the rate isn't affected by paused time.
Finally, the scrub paused state is now persistent on disk using option 2 (new dsl_scan_flags_t) suggested by Matt so there is no new feature flag.

loli10K · 2017-06-09T05:40:01Z

module/zfs/dsl_scan.c

@@ -141,9 +142,9 @@ dsl_scan_init(dsl_pool_t *dp, uint64_t txg)
 		 */
 		if (err == EOVERFLOW) {


I wonder if adding a new value to dsl_scan_phys_t (and bumping SCAN_PHYS_NUMINTS to 25) will prevent us from detecting errata 2094 in the first place, since zap_lookup will not EOVERFLOW if the pool is affected.

I think I can avoid modifying the on-disk format (dsl_scan_phys_t) here, as scn_scrub_pause_time doesn't need to be persistent and that will actually make the code simpler.

However, you do bring up an interesting point - errata 2094 locks us into the current on-disk format for dsl_scan_phys_t...

it locks you into the current size of the dsl_scan_phys_t, but adding the new flag should be OK.

ahrens · 2017-06-09T19:23:50Z

include/sys/dsl_scan.h

@@ -55,6 +56,7 @@ typedef struct dsl_scan_phys {
 	uint64_t scn_cur_max_txg;
 	uint64_t scn_start_time;
 	uint64_t scn_end_time;
+	uint64_t scn_scrub_pause_time; /* when scrub was paused */


regardless of the other errata, you definitely can't change the offset of the following fields without adding a feature flag and managing the transition to the new on-disk format.

yea I realized that after @loli10K's comment about errata. What I'm going to have to do avoid changing on disk format is have the pause time reset every time the pool is imported in a paused state which I think is ok.

ahrens · 2017-06-09T19:25:19Z

module/zfs/dsl_scan.c

@@ -141,9 +142,9 @@ dsl_scan_init(dsl_pool_t *dp, uint64_t txg)
 		 */
 		if (err == EOVERFLOW) {


it locks you into the current size of the dsl_scan_phys_t, but adding the new flag should be OK.

alek-p · 2017-06-12T18:24:46Z

With the latest patch scrub-pause persistence is now achieved without any on-disk format changes.
There are caveats that follow from that:

If exported pool had scrub paused the scrub pause time as seen in zpool status output is initialised on import.
Scrub completion time includes time spent paused. It also includes time spent exported just like before this patch.

ahrens · 2017-06-12T18:26:31Z

@alek-p Thanks! Those caveats sound reasonable to me.

behlendorf · 2017-06-12T19:20:21Z

@alek-p thanks, that sounds reasonable.

behlendorf

Looks good. Just a few minor suggested things to cleanup.

behlendorf · 2017-06-13T19:57:08Z

lib/libzfs/libzfs_pool.c

-	    (errno == ENOENT && func != POOL_SCAN_NONE))
+	    (errno == ERESTART && func == POOL_SCAN_SCRUB) ||
+	    (errno == ENOENT && func != POOL_SCAN_NONE &&
+	    cmd == POOL_SCRUB_NORMAL))


It would be nice to restructure these checks in to standard if statements so they're easier to read.

As part of that cleanup you should also store the errno in a local variable after the call to zfs_ioctl(). The existing code is a bit dodgy in this regard since it possible errno will change if the snprintf were to fail. It can be set to any of the following on failure: EILSEQ, EINVAL, EBADF, ENOMEM, EOVERFLOW. Fortunately, that's unlikely but let's fix this while we're here.

behlendorf · 2017-06-13T20:08:42Z

module/zfs/zfs_ioctl.c

@@ -1683,7 +1684,13 @@ zfs_ioc_pool_scan(zfs_cmd_t *zc)
 	if ((error = spa_open(zc->zc_name, &spa, FTAG)) != 0)
 		return (error);

-	if (zc->zc_cookie == POOL_SCAN_NONE)
+	if (zc->zc_flags < POOL_SCRUB_NORMAL ||


This can never be true since zc_flags is unsigned and POOL_SCRUB_NORMAL = 0. Let's drop this first check, it's going to upset static code analysis utilities.

behlendorf · 2017-06-13T20:15:30Z

tests/zfs-tests/include/libtest.shlib

+{
+	check_pool_status "$1" "scan" "scrub paused since "
+	return $?
+}


You'll want to update the comment above is_pool_resilvering to include this additional helper function. Including changing the 5->6.

thanks, I've made the edits

behlendorf · 2017-06-13T20:17:14Z

tests/zfs-tests/tests/functional/cli_root/zpool_import/zpool_import_scrub_pause.ksh

+
+#
+# Copyright (c) 2012, 2016 by Delphix. All rights reserved.
+# Copyright (c) 2017 Datto Inc.


You can group all of the copyright lines together.

# Copyright 2007 Sun Microsystems, Inc. All rights reserved. # Copyright (c) 2012, 2016 by Delphix. All rights reserved. # Copyright (c) 2017 Datto Inc. # Use is subject to license terms.

behlendorf

Thanks, I'm happy with this and it worked nicely in the local testing I did. Let's see if we can get another review from @ahrens to see if he has and remaining concerns.

Concerns were addressed.

ahrens · 2017-06-16T16:47:21Z

cmd/zpool/zpool_main.c

@@ -2389,6 +2392,9 @@ zpool_do_import(int argc, char **argv)
 				mntopts = optarg;
 			}
 			break;
+		case 'p':
+			flags |= ZFS_IMPORT_SCRUB_PAUSE;
+			break;


Since the pausing is now persistent on disk, what's the use case for zpool import -p? Seems like you could accomplish (nearly?) the same thing with zpool import; zpool scrub -p.

We've had cases in the past where this would have been useful. For example issue #3658, where due to some unfortunate hardware/drivers the pool couldn't be imported and the scrub canceled quickly enough to avoid other problems. This might also be a useful feature to aid with pool recovery scenarios.

For pool recovery, importing readonly would be a better option.

I get that "import + cancel/pause scrub" could be useful in a few specific scenarios, but from a user interface design it seems arbitrary. There are a lot of other specific scenarios where other combo options could be helpful. e.g. what if I'm resilvering and for some reason the hardware doesn't like that? What if I'm doing a background destroy? What if one of the disks is sort of busted and I want to do a "import + offline "?

For pool recovery, importing readonly is absolutely the best option to start with. In fact, if scrubs were automatically paused for readonly pools that would address my use case.

I see your point about this option being somewhat arbitrary. I'm not opposed to dropping it particularly if we made the suggested readonly tweak. But perhaps @alek-p has another use case in mind?

Scrubs have always been (silently) paused on readonly pools. Scrub happens from spa_sync(), and requires modifying the on-disk state (the scn_queue_obj), so unfortunately it isn't possible to scrub a readonly pool.

I'm fine with dropping the import -p option. My use case was the same - to address #3658

ahrens · 2017-06-16T16:50:58Z

include/sys/dsl_scan.h

@@ -70,6 +71,7 @@ typedef struct dsl_scan_phys {

 typedef enum dsl_scan_flags {
 	DSF_VISIT_DS_AGAIN = 1<<0,
+	DSF_SCRUB_PAUSED = 1<<1,


We should reserve this flag in the other implementations ASAP. Would you mind opening an OpenZFS PR to add this one line, with a comment saying that we don't support this flag yet but it's reserved for future use?

I can just do a full upstream of scrub-pause to OpenZFS. Unless we want soak time in ZoL first?

Full upstream would be great!

Concurrent PRs against OpenZFS and ZoL would be great.

done, see openzfs/openzfs#407

ahrens · 2017-06-16T16:53:57Z

man/man8/zpool.8

+\fB\fB-p\fR\fR
+.ad
+.RS 6n
+Pause scrubbing. Scrub progress is periodically synced to disk so if the system


It might be worth noting that resilvers can't be paused.

I can add a sentence at the end: "Note, resilver can't be paused."
However, this is documenting the scrub command so I'm not sure resilver notes belong here?

That's true, maybe it isn't necessary to note anything here. Its just those of us who know that internally scrub and resilver are nearly the same, we might wonder but we can also just check the code :-)

ahrens · 2017-06-16T17:04:51Z

module/zfs/dsl_scan.c

+
+	/* can't pause a scrub when there is no in-progress scrub */
+	if (cmd == POOL_SCRUB_PAUSE && !dsl_scan_scrubbing(dp))
+		return (SET_ERROR(ENOENT));


I think this function would be easier to follow if it was overall structured like:

if (cmd == PAUSE) { // do checks // set fields } else { // ASSERT(cmd == NORMAL) if (paused_scrub()) { // set fields } }

ahrens · 2017-06-16T17:08:04Z

module/zfs/dsl_scan.c

@@ -1686,6 +1756,12 @@ dsl_scan_sync(dsl_pool_t *dp, dmu_tx_t *tx)
 		return;
 	}

+	if (dsl_scan_is_paused_scrub(scn)) {
+		zfs_dbgmsg("bailing on scrub since it's paused, sync txg %llu",
+		    (longlong_t)tx->tx_txg);


This message might be a bit excessive, since it will be printed every txg, even though we aren't doing anything. My general philosophy around zfs_dbgmsg is that we should use it when something exceptional happens, when we make roughly once-per-txg on-disk changes, and roughly once-per-txg when we make progress on background tasks. But simply saying "the system continues to be in this normal state" every txg seems like a waste of log space.

ok I'll drop the message

ahrens · 2017-06-16T17:10:08Z

module/zfs/txg.c

@@ -500,7 +501,8 @@ txg_sync_thread(dsl_pool_t *dp)
 		 * us, or we have reached our timeout.
 		 */
 		timer = (delta >= timeout ? 0 : timeout - delta);
-		while (!dsl_scan_active(dp->dp_scan) &&
+		while ((!dsl_scan_active(dp->dp_scan) ||
+		    dsl_scan_is_paused_scrub(dp->dp_scan)) &&


can we instead change dsl_scan_active() to return FALSE when it's paused?

ahrens · 2017-06-16T17:13:22Z

module/zfs/dsl_scan.c

+
+	if (cmd == POOL_SCRUB_PAUSE) {
+		spa->spa_scan_pass_scrub_pause = gethrestime_sec();
+		scn->scn_phys.scn_flags |= DSF_SCRUB_PAUSED;


Is it OK to do this from open context (I'm guessing no)? When will it be persisted to disk (I'm guessing never / by luck, since you are not calling dsl_scan_state_sync(), which can't be called from open context anyway)?

I would suggest that you do this from a synctask instead.

I belive dsl_scan_sync_state() is called every txg by way of spa_sync() -> dsl_scan_sync() -> dsl_scan_sync_state().

It can be called by dsl_scan_sync(), but I don't think it is called if the scrub is paused. dsl_scan_sync() will return before getting to the end, where it calls dsl_scan_sync_state().

Ok, I'll change it this to be done from a sync task

ahrens · 2017-06-16T17:19:56Z

module/zfs/dsl_scan.c

+		spa->spa_scan_pass_scrub_spent_paused +=
+		    gethrestime_sec() - spa->spa_scan_pass_scrub_pause;
+		spa->spa_scan_pass_scrub_pause = 0;
+		scn->scn_phys.scn_flags &= ~DSF_SCRUB_PAUSED;


same issue here with modifying scn_phys.

ahrens · 2017-06-16T17:21:13Z

tests/zfs-tests/tests/functional/cli_root/zpool_import/zpool_import_scrub_pause.ksh

+	log_must mkfile $FILE_SIZE $VDEV0 $VDEV1
+}
+
+log_assert "Importing a pool with the pause scrub option works as expected"


this doesn't seem accurate

alek-p · 2017-06-20T17:01:42Z

Thanks, @ahrens. I think I've addressed all the comments. Also fixed zpool_scrub_002_pos.ksh log_assert msg to reflect the fact that this test is testing scrub -p as well now.
Now working on the port to OpenZFS.

alek-p · 2017-06-30T15:56:50Z

I've added and set a verbose output option for is_pool_* functions in libtest.shlib so that if the test fails agian we'll have more insight into why.

alek-p · 2017-06-30T20:26:06Z

Ok I've confirmed that the test is failing because the scrub finishes before the last check. Seems the zinject delay needs to be longer or the check should be is pool scrubing or finished scrubbing

18:10:38.11 SUCCESS: zpool scrub testpool
18:10:38.13 NOTE: scan: scrub in progress since Fri Jun 30 18:10:36 2017
18:10:38.14 SUCCESS: is_pool_scrubbing testpool true
18:10:40.27 SUCCESS: zpool scrub -p testpool
18:10:40.29 NOTE: scan: scrub paused since Fri Jun 30 18:10:39 2017
18:10:40.29 SUCCESS: is_pool_scrub_paused testpool true
18:10:40.31 SUCCESS: zpool scrub -p testpool exited 1
18:10:40.32 NOTE: scan: scrub paused since Fri Jun 30 18:10:39 2017
18:10:40.33 SUCCESS: is_pool_scrub_paused testpool true
18:10:41.87 SUCCESS: zpool scrub testpool
18:10:41.89 NOTE: scan: scrub repaired 0B in 0h0m with 0 errors on Fri Jun 30 18:10:41 2017
18:10:41.89 
18:10:41.89 ERROR: is_pool_scrubbing testpool true exited 1

behlendorf · 2017-07-01T23:07:04Z

Right, let's try doubling the delay.

Currently, there is no way to pause a scrub. Pausing may be useful when the pool is busy with other I/O to preserve bandwidth. This patch adds the ability to pause and resume scrubbing. This is achieved by maintaining a persistent on-disk scrub state. While the state is 'paused' we do not scrub any more blocks. We do however perform regular scan housekeeping such as freeing async destroyed and deadlist blocks while paused. Signed-off-by: Alek Pinchuk <apinchuk@datto.com>

behlendorf · 2017-07-05T16:36:58Z

Looks good. @ahrens do you have any additional comments.

ahrens · 2017-07-05T23:33:12Z

@behlendorf I'll take another look at this and the OpenZFS version, but it might not be until next week.

behlendorf · 2017-07-06T20:33:50Z

@ahrens thanks! @alek-p unless you have any additional pending changes I'm going to go ahead and merges this. Let's incorporate any additional feedback in a followup PR if needed.

alek-p · 2017-07-07T03:18:15Z

@behlendorf sounds good, I don't have anything else currently

illumos/illumos-gate@1702cce illumos/illumos-gate@1702cce https://www.illumos.org/issues/8414 This issue tracks the port of scrub pause from ZoL: openzfs/zfs#6167 Currently, there is no way to pause a scrub. Pausing may be useful when the pool is busy with other I/O to preserve bandwidth. Description This patch adds the ability to pause and resume scrubbing. This is achieved by maintaining a persistent on-disk scrub state. While the state is 'paused' we do not scrub any more blocks. We do however perform regular scan housekeeping such as freeing async destroyed and deadlist blocks while paused. If you're testing this change, you probably want to include the patch from #6164 Motivation and Context Scrub pausing can be an I/O intensive operation and people have been asking for the ability to pause a scrub for a while. This allows one to preserve scrub progress while freeing up bandwidth for other I/O. How Has This Been Tested? Unit testing and zfs-tests. to the pool. This patch will also include the patch from https://github.com/zfsonlinux/zfs/ pull/6164 In certain cases (dsl_scan_sync() is one), we may end up calling Reviewed by: George Melikov <mail@gmelikov.ru> Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed by: Brad Lewis <brad.lewis@delphix.com> Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Alek Pinchuk <apinchuk@datto.com> git-svn-id: https://svn.freebsd.org/base/vendor/illumos/dist@323107 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f

illumos/illumos-gate@1702cce illumos/illumos-gate@1702cce https://www.illumos.org/issues/8414 This issue tracks the port of scrub pause from ZoL: openzfs/zfs#6167 Currently, there is no way to pause a scrub. Pausing may be useful when the pool is busy with other I/O to preserve bandwidth. Description This patch adds the ability to pause and resume scrubbing. This is achieved by maintaining a persistent on-disk scrub state. While the state is 'paused' we do not scrub any more blocks. We do however perform regular scan housekeeping such as freeing async destroyed and deadlist blocks while paused. If you're testing this change, you probably want to include the patch from #6164 Motivation and Context Scrub pausing can be an I/O intensive operation and people have been asking for the ability to pause a scrub for a while. This allows one to preserve scrub progress while freeing up bandwidth for other I/O. How Has This Been Tested? Unit testing and zfs-tests. to the pool. This patch will also include the patch from https://github.com/zfsonlinux/zfs/ pull/6164 In certain cases (dsl_scan_sync() is one), we may end up calling Reviewed by: George Melikov <mail@gmelikov.ru> Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed by: Brad Lewis <brad.lewis@delphix.com> Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Alek Pinchuk <apinchuk@datto.com> git-svn-id: https://svn.freebsd.org/base/vendor-sys/illumos/dist@323107 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f

illumos/illumos-gate@1702cce illumos/illumos-gate@1702cce FreeBSD note: rather than merging the zpool.8 update I copied the zpool scrub section from the illumos zpool.1m to FreeBSD zpool.8 almost verbatim. Now that the illumos page uses the mdoc format, it was an easier option. Perhaps the change is not in perfect compliance with the FreeBSD style, but I think that it is acceptible. https://www.illumos.org/issues/8414 This issue tracks the port of scrub pause from ZoL: openzfs/zfs#6167 Currently, there is no way to pause a scrub. Pausing may be useful when the pool is busy with other I/O to preserve bandwidth. Description This patch adds the ability to pause and resume scrubbing. This is achieved by maintaining a persistent on-disk scrub state. While the state is 'paused' we do not scrub any more blocks. We do however perform regular scan housekeeping such as freeing async destroyed and deadlist blocks while paused. Motivation and Context Scrub pausing can be an I/O intensive operation and people have been asking for the ability to pause a scrub for a while. This allows one to preserve scrub progress while freeing up bandwidth for other I/O. Reviewed by: George Melikov <mail@gmelikov.ru> Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed by: Brad Lewis <brad.lewis@delphix.com> Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Alek Pinchuk <apinchuk@datto.com> MFC after: 2 weeks git-svn-id: svn+ssh://svn.freebsd.org/base/head@323355 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f

illumos/illumos-gate@1702cce illumos/illumos-gate@1702cce FreeBSD note: rather than merging the zpool.8 update I copied the zpool scrub section from the illumos zpool.1m to FreeBSD zpool.8 almost verbatim. Now that the illumos page uses the mdoc format, it was an easier option. Perhaps the change is not in perfect compliance with the FreeBSD style, but I think that it is acceptible. https://www.illumos.org/issues/8414 This issue tracks the port of scrub pause from ZoL: openzfs/zfs#6167 Currently, there is no way to pause a scrub. Pausing may be useful when the pool is busy with other I/O to preserve bandwidth. Description This patch adds the ability to pause and resume scrubbing. This is achieved by maintaining a persistent on-disk scrub state. While the state is 'paused' we do not scrub any more blocks. We do however perform regular scan housekeeping such as freeing async destroyed and deadlist blocks while paused. Motivation and Context Scrub pausing can be an I/O intensive operation and people have been asking for the ability to pause a scrub for a while. This allows one to preserve scrub progress while freeing up bandwidth for other I/O. Reviewed by: George Melikov <mail@gmelikov.ru> Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed by: Brad Lewis <brad.lewis@delphix.com> Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Alek Pinchuk <apinchuk@datto.com> MFC after: 2 weeks

illumos/illumos-gate@1702cce illumos/illumos-gate@1702cce FreeBSD note: rather than merging the zpool.8 update I copied the zpool scrub section from the illumos zpool.1m to FreeBSD zpool.8 almost verbatim. Now that the illumos page uses the mdoc format, it was an easier option. Perhaps the change is not in perfect compliance with the FreeBSD style, but I think that it is acceptible. https://www.illumos.org/issues/8414 This issue tracks the port of scrub pause from ZoL: openzfs/zfs#6167 Currently, there is no way to pause a scrub. Pausing may be useful when the pool is busy with other I/O to preserve bandwidth. Description This patch adds the ability to pause and resume scrubbing. This is achieved by maintaining a persistent on-disk scrub state. While the state is 'paused' we do not scrub any more blocks. We do however perform regular scan housekeeping such as freeing async destroyed and deadlist blocks while paused. Motivation and Context Scrub pausing can be an I/O intensive operation and people have been asking for the ability to pause a scrub for a while. This allows one to preserve scrub progress while freeing up bandwidth for other I/O. Reviewed by: George Melikov <mail@gmelikov.ru> Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed by: Brad Lewis <brad.lewis@delphix.com> Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Alek Pinchuk <apinchuk@datto.com> MFC after: 2 weeks git-svn-id: https://svn.freebsd.org/base/head@323355 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f

illumos/illumos-gate@1702cce illumos/illumos-gate@1702cce FreeBSD note: rather than merging the zpool.8 update I copied the zpool scrub section from the illumos zpool.1m to FreeBSD zpool.8 almost verbatim. Now that the illumos page uses the mdoc format, it was an easier option. Perhaps the change is not in perfect compliance with the FreeBSD style, but I think that it is acceptible. https://www.illumos.org/issues/8414 This issue tracks the port of scrub pause from ZoL: openzfs/zfs#6167 Currently, there is no way to pause a scrub. Pausing may be useful when the pool is busy with other I/O to preserve bandwidth. Description This patch adds the ability to pause and resume scrubbing. This is achieved by maintaining a persistent on-disk scrub state. While the state is 'paused' we do not scrub any more blocks. We do however perform regular scan housekeeping such as freeing async destroyed and deadlist blocks while paused. Motivation and Context Scrub pausing can be an I/O intensive operation and people have been asking for the ability to pause a scrub for a while. This allows one to preserve scrub progress while freeing up bandwidth for other I/O. Reviewed by: George Melikov <mail@gmelikov.ru> Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed by: Brad Lewis <brad.lewis@delphix.com> Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Alek Pinchuk <apinchuk@datto.com> MFC after: 2 weeks git-svn-id: svn+ssh://svn.freebsd.org/base/head@323355 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f

illumos/illumos-gate@1702cce illumos/illumos-gate@1702cce FreeBSD note: rather than merging the zpool.8 update I copied the zpool scrub section from the illumos zpool.1m to FreeBSD zpool.8 almost verbatim. Now that the illumos page uses the mdoc format, it was an easier option. Perhaps the change is not in perfect compliance with the FreeBSD style, but I think that it is acceptible. https://www.illumos.org/issues/8414 This issue tracks the port of scrub pause from ZoL: openzfs/zfs#6167 Currently, there is no way to pause a scrub. Pausing may be useful when the pool is busy with other I/O to preserve bandwidth. Description This patch adds the ability to pause and resume scrubbing. This is achieved by maintaining a persistent on-disk scrub state. While the state is 'paused' we do not scrub any more blocks. We do however perform regular scan housekeeping such as freeing async destroyed and deadlist blocks while paused. Motivation and Context Scrub pausing can be an I/O intensive operation and people have been asking for the ability to pause a scrub for a while. This allows one to preserve scrub progress while freeing up bandwidth for other I/O. Reviewed by: George Melikov <mail@gmelikov.ru> Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed by: Brad Lewis <brad.lewis@delphix.com> Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Alek Pinchuk <apinchuk@datto.com>

illumos/illumos-gate@1702cce illumos/illumos-gate@1702cce https://www.illumos.org/issues/8414 This issue tracks the port of scrub pause from ZoL: openzfs/zfs#6167 Currently, there is no way to pause a scrub. Pausing may be useful when the pool is busy with other I/O to preserve bandwidth. Description This patch adds the ability to pause and resume scrubbing. This is achieved by maintaining a persistent on-disk scrub state. While the state is 'paused' we do not scrub any more blocks. We do however perform regular scan housekeeping such as freeing async destroyed and deadlist blocks while paused. If you're testing this change, you probably want to include the patch from #6164 Motivation and Context Scrub pausing can be an I/O intensive operation and people have been asking for the ability to pause a scrub for a while. This allows one to preserve scrub progress while freeing up bandwidth for other I/O. How Has This Been Tested? Unit testing and zfs-tests. to the pool. This patch will also include the patch from https://github.com/zfsonlinux/zfs/ pull/6164 In certain cases (dsl_scan_sync() is one), we may end up calling Reviewed by: George Melikov <mail@gmelikov.ru> Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed by: Brad Lewis <brad.lewis@delphix.com> Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Alek Pinchuk <apinchuk@datto.com>

illumos/illumos-gate@1702cce illumos/illumos-gate@1702cce FreeBSD note: rather than merging the zpool.8 update I copied the zpool scrub section from the illumos zpool.1m to FreeBSD zpool.8 almost verbatim. Now that the illumos page uses the mdoc format, it was an easier option. Perhaps the change is not in perfect compliance with the FreeBSD style, but I think that it is acceptible. https://www.illumos.org/issues/8414 This issue tracks the port of scrub pause from ZoL: openzfs/zfs#6167 Currently, there is no way to pause a scrub. Pausing may be useful when the pool is busy with other I/O to preserve bandwidth. Description This patch adds the ability to pause and resume scrubbing. This is achieved by maintaining a persistent on-disk scrub state. While the state is 'paused' we do not scrub any more blocks. We do however perform regular scan housekeeping such as freeing async destroyed and deadlist blocks while paused. Motivation and Context Scrub pausing can be an I/O intensive operation and people have been asking for the ability to pause a scrub for a while. This allows one to preserve scrub progress while freeing up bandwidth for other I/O. Reviewed by: George Melikov <mail@gmelikov.ru> Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed by: Brad Lewis <brad.lewis@delphix.com> Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Alek Pinchuk <apinchuk@datto.com> git-svn-id: https://svn.freebsd.org/base/stable/11@324010 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f

illumos/illumos-gate@1702cce illumos/illumos-gate@1702cce FreeBSD note: rather than merging the zpool.8 update I copied the zpool scrub section from the illumos zpool.1m to FreeBSD zpool.8 almost verbatim. Now that the illumos page uses the mdoc format, it was an easier option. Perhaps the change is not in perfect compliance with the FreeBSD style, but I think that it is acceptible. https://www.illumos.org/issues/8414 This issue tracks the port of scrub pause from ZoL: openzfs/zfs#6167 Currently, there is no way to pause a scrub. Pausing may be useful when the pool is busy with other I/O to preserve bandwidth. Description This patch adds the ability to pause and resume scrubbing. This is achieved by maintaining a persistent on-disk scrub state. While the state is 'paused' we do not scrub any more blocks. We do however perform regular scan housekeeping such as freeing async destroyed and deadlist blocks while paused. Motivation and Context Scrub pausing can be an I/O intensive operation and people have been asking for the ability to pause a scrub for a while. This allows one to preserve scrub progress while freeing up bandwidth for other I/O. Reviewed by: George Melikov <mail@gmelikov.ru> Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed by: Brad Lewis <brad.lewis@delphix.com> Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Alek Pinchuk <apinchuk@datto.com> (cherry picked from commit b605203)

illumos/illumos-gate@1702cce illumos/illumos-gate@1702cce https://www.illumos.org/issues/8414 This issue tracks the port of scrub pause from ZoL: openzfs/zfs#6167 Currently, there is no way to pause a scrub. Pausing may be useful when the pool is busy with other I/O to preserve bandwidth. Description This patch adds the ability to pause and resume scrubbing. This is achieved by maintaining a persistent on-disk scrub state. While the state is 'paused' we do not scrub any more blocks. We do however perform regular scan housekeeping such as freeing async destroyed and deadlist blocks while paused. If you're testing this change, you probably want to include the patch from #6164 Motivation and Context Scrub pausing can be an I/O intensive operation and people have been asking for the ability to pause a scrub for a while. This allows one to preserve scrub progress while freeing up bandwidth for other I/O. How Has This Been Tested? Unit testing and zfs-tests. to the pool. This patch will also include the patch from https://github.com/zfsonlinux/zfs/ pull/6164 In certain cases (dsl_scan_sync() is one), we may end up calling Reviewed by: George Melikov <mail@gmelikov.ru> Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed by: Brad Lewis <brad.lewis@delphix.com> Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Alek Pinchuk <apinchuk@datto.com>

illumos/illumos-gate@1702cce illumos/illumos-gate@1702cce FreeBSD note: rather than merging the zpool.8 update I copied the zpool scrub section from the illumos zpool.1m to FreeBSD zpool.8 almost verbatim. Now that the illumos page uses the mdoc format, it was an easier option. Perhaps the change is not in perfect compliance with the FreeBSD style, but I think that it is acceptible. https://www.illumos.org/issues/8414 This issue tracks the port of scrub pause from ZoL: openzfs/zfs#6167 Currently, there is no way to pause a scrub. Pausing may be useful when the pool is busy with other I/O to preserve bandwidth. Description This patch adds the ability to pause and resume scrubbing. This is achieved by maintaining a persistent on-disk scrub state. While the state is 'paused' we do not scrub any more blocks. We do however perform regular scan housekeeping such as freeing async destroyed and deadlist blocks while paused. Motivation and Context Scrub pausing can be an I/O intensive operation and people have been asking for the ability to pause a scrub for a while. This allows one to preserve scrub progress while freeing up bandwidth for other I/O. Reviewed by: George Melikov <mail@gmelikov.ru> Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed by: Brad Lewis <brad.lewis@delphix.com> Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Alek Pinchuk <apinchuk@datto.com>

illumos/illumos-gate@1702cce illumos/illumos-gate@1702cce FreeBSD note: rather than merging the zpool.8 update I copied the zpool scrub section from the illumos zpool.1m to FreeBSD zpool.8 almost verbatim. Now that the illumos page uses the mdoc format, it was an easier option. Perhaps the change is not in perfect compliance with the FreeBSD style, but I think that it is acceptible. https://www.illumos.org/issues/8414 This issue tracks the port of scrub pause from ZoL: openzfs/zfs#6167 Currently, there is no way to pause a scrub. Pausing may be useful when the pool is busy with other I/O to preserve bandwidth. Description This patch adds the ability to pause and resume scrubbing. This is achieved by maintaining a persistent on-disk scrub state. While the state is 'paused' we do not scrub any more blocks. We do however perform regular scan housekeeping such as freeing async destroyed and deadlist blocks while paused. Motivation and Context Scrub pausing can be an I/O intensive operation and people have been asking for the ability to pause a scrub for a while. This allows one to preserve scrub progress while freeing up bandwidth for other I/O. Reviewed by: George Melikov <mail@gmelikov.ru> Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed by: Brad Lewis <brad.lewis@delphix.com> Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Alek Pinchuk <apinchuk@datto.com> Former-commit-id: 962ee1895449e77d03e9bdd28a19c016eb222b25

illumos/illumos-gate@1702cce illumos/illumos-gate@1702cce FreeBSD note: rather than merging the zpool.8 update I copied the zpool scrub section from the illumos zpool.1m to FreeBSD zpool.8 almost verbatim. Now that the illumos page uses the mdoc format, it was an easier option. Perhaps the change is not in perfect compliance with the FreeBSD style, but I think that it is acceptible. https://www.illumos.org/issues/8414 This issue tracks the port of scrub pause from ZoL: openzfs/zfs#6167 Currently, there is no way to pause a scrub. Pausing may be useful when the pool is busy with other I/O to preserve bandwidth. Description This patch adds the ability to pause and resume scrubbing. This is achieved by maintaining a persistent on-disk scrub state. While the state is 'paused' we do not scrub any more blocks. We do however perform regular scan housekeeping such as freeing async destroyed and deadlist blocks while paused. Motivation and Context Scrub pausing can be an I/O intensive operation and people have been asking for the ability to pause a scrub for a while. This allows one to preserve scrub progress while freeing up bandwidth for other I/O. Reviewed by: George Melikov <mail@gmelikov.ru> Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed by: Brad Lewis <brad.lewis@delphix.com> Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Alek Pinchuk <apinchuk@datto.com>

illumos/illumos-gate@1702cce illumos/illumos-gate@1702cce FreeBSD note: rather than merging the zpool.8 update I copied the zpool scrub section from the illumos zpool.1m to FreeBSD zpool.8 almost verbatim. Now that the illumos page uses the mdoc format, it was an easier option. Perhaps the change is not in perfect compliance with the FreeBSD style, but I think that it is acceptible. https://www.illumos.org/issues/8414 This issue tracks the port of scrub pause from ZoL: openzfs/zfs#6167 Currently, there is no way to pause a scrub. Pausing may be useful when the pool is busy with other I/O to preserve bandwidth. Description This patch adds the ability to pause and resume scrubbing. This is achieved by maintaining a persistent on-disk scrub state. While the state is 'paused' we do not scrub any more blocks. We do however perform regular scan housekeeping such as freeing async destroyed and deadlist blocks while paused. Motivation and Context Scrub pausing can be an I/O intensive operation and people have been asking for the ability to pause a scrub for a while. This allows one to preserve scrub progress while freeing up bandwidth for other I/O. Reviewed by: George Melikov <mail@gmelikov.ru> Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed by: Brad Lewis <brad.lewis@delphix.com> Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Alek Pinchuk <apinchuk@datto.com> MFC after: 2 weeks

illumos/illumos-gate@1702cce illumos/illumos-gate@1702cce FreeBSD note: rather than merging the zpool.8 update I copied the zpool scrub section from the illumos zpool.1m to FreeBSD zpool.8 almost verbatim. Now that the illumos page uses the mdoc format, it was an easier option. Perhaps the change is not in perfect compliance with the FreeBSD style, but I think that it is acceptible. https://www.illumos.org/issues/8414 This issue tracks the port of scrub pause from ZoL: openzfs/zfs#6167 Currently, there is no way to pause a scrub. Pausing may be useful when the pool is busy with other I/O to preserve bandwidth. Description This patch adds the ability to pause and resume scrubbing. This is achieved by maintaining a persistent on-disk scrub state. While the state is 'paused' we do not scrub any more blocks. We do however perform regular scan housekeeping such as freeing async destroyed and deadlist blocks while paused. Motivation and Context Scrub pausing can be an I/O intensive operation and people have been asking for the ability to pause a scrub for a while. This allows one to preserve scrub progress while freeing up bandwidth for other I/O. Reviewed by: George Melikov <mail@gmelikov.ru> Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed by: Brad Lewis <brad.lewis@delphix.com> Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Alek Pinchuk <apinchuk@datto.com>

alek-p force-pushed the scrub-pause branch from 07f8603 to 9ef49b2 Compare May 25, 2017 21:21

loli10K previously requested changes May 28, 2017

View reviewed changes

alek-p force-pushed the scrub-pause branch from 9ef49b2 to 4edad26 Compare May 29, 2017 10:31

behlendorf requested changes Jun 1, 2017

View reviewed changes

alek-p force-pushed the scrub-pause branch 2 times, most recently from bf05fdd to d6cd08a Compare June 5, 2017 20:14

behlendorf requested changes Jun 6, 2017

View reviewed changes

ahrens requested changes Jun 6, 2017

View reviewed changes

alek-p force-pushed the scrub-pause branch from d6cd08a to ce79b4d Compare June 8, 2017 17:42

loli10K reviewed Jun 9, 2017

View reviewed changes

ahrens reviewed Jun 9, 2017

View reviewed changes

alek-p force-pushed the scrub-pause branch from ce79b4d to 70668e6 Compare June 10, 2017 17:43

behlendorf requested changes Jun 13, 2017

View reviewed changes

alek-p force-pushed the scrub-pause branch from 70668e6 to 01df9c2 Compare June 13, 2017 23:02

behlendorf approved these changes Jun 14, 2017

View reviewed changes

ahrens requested changes Jun 16, 2017

View reviewed changes

alek-p force-pushed the scrub-pause branch from 01df9c2 to 21f82e5 Compare June 20, 2017 00:25

alek-p force-pushed the scrub-pause branch from 21f82e5 to 3ac2ae2 Compare June 20, 2017 18:33

alek-p force-pushed the scrub-pause branch from c9d48af to aa38b11 Compare July 3, 2017 05:34

alek-p force-pushed the scrub-pause branch from aa38b11 to 388a9ab Compare July 3, 2017 16:04

behlendorf merged commit 0ea05c6 into openzfs:master Jul 7, 2017

gmelikov mentioned this pull request Jul 7, 2017

Can't import and cancel scrub at the same time #3658

Closed

alek-p deleted the scrub-pause branch July 7, 2017 15:22

		@@ -141,9 +142,9 @@ dsl_scan_init(dsl_pool_t *dp, uint64_t txg)
		*/
		if (err == EOVERFLOW) {

Implemented zpool scrub pause/resume #6167

Implemented zpool scrub pause/resume #6167

Conversation

alek-p commented May 25, 2017 • edited

Description

Motivation and Context

How Has This Been Tested?

Types of changes

Checklist:

mention-bot commented May 25, 2017

alek-p commented May 25, 2017 • edited

loli10K commented May 25, 2017

alek-p commented May 25, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

behlendorf left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ahrens left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

behlendorf Jun 6, 2017 • edited

Choose a reason for hiding this comment

behlendorf commented Jun 6, 2017

alek-p commented Jun 7, 2017

alek-p commented Jun 8, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alek-p commented Jun 12, 2017

ahrens commented Jun 12, 2017

behlendorf commented Jun 12, 2017

behlendorf left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

behlendorf Jun 13, 2017 • edited

Choose a reason for hiding this comment

behlendorf left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ahrens Jun 16, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alek-p commented Jun 20, 2017 • edited

alek-p commented Jun 30, 2017

alek-p commented Jun 30, 2017 • edited

alek-p commented May 25, 2017 •

edited

alek-p commented May 25, 2017 •

edited

behlendorf Jun 6, 2017 •

edited

alek-p commented Jun 8, 2017 •

edited

behlendorf Jun 13, 2017 •

edited

ahrens Jun 16, 2017 •

edited

alek-p commented Jun 20, 2017 •

edited

alek-p commented Jun 30, 2017 •

edited