You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Spurious resilver to same device immediately after previous resilver completed.
Describe how to reproduce the problem
All I did was run
zpool replace tank 272646635384699889 /dev/mapper/sdb1crypt
Once the initial resilver completed, it apparently started over from scratch without exiting.
Include any warning/errors/backtraces from the system logs
% zpool status -v
pool: tank
state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Sun Sep 29 18:58:47 2019
1.61T scanned at 254M/s, 784G issued at 121M/s, 2.88T total
784G resilvered, 26.60% done, 0 days 05:05:31 to go
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
replacing-0 DEGRADED 0 0 0
272646635384699889 UNAVAIL 0 0 0 was /dev/mapper/sdb1crypt/old
sdb1crypt ONLINE 0 0 0 (resilvering)
sda1crypt ONLINE 0 0 0
errors: No known data errors
The text was updated successfully, but these errors were encountered:
If a device is participating in an active resilver, then it will have a
non-empty DTL. Operations like vdev_{open,reopen,probe}() can cause the
resilver to be restarted (or deferred to be restarted later), which is
unnecessary if the DTL is still covered by the current scan range. This
is similar to the logic in vdev_dtl_should_excise() where the DTL can
only be excised if it's max txg is in the resilvered range.
Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: John Gallagher <[email protected]>
Reviewed-by: Kjeld Schouten <[email protected]>
Signed-off-by: John Poduska <[email protected]>
Issue openzfs#840Closesopenzfs#9155Closesopenzfs#9378Closesopenzfs#9551Closesopenzfs#9588
If a device is participating in an active resilver, then it will have a
non-empty DTL. Operations like vdev_{open,reopen,probe}() can cause the
resilver to be restarted (or deferred to be restarted later), which is
unnecessary if the DTL is still covered by the current scan range. This
is similar to the logic in vdev_dtl_should_excise() where the DTL can
only be excised if it's max txg is in the resilvered range.
Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: John Gallagher <[email protected]>
Reviewed-by: Kjeld Schouten <[email protected]>
Signed-off-by: John Poduska <[email protected]>
Issue #840Closes#9155Closes#9378Closes#9551Closes#9588
System information
Describe the problem you're observing
Spurious resilver to same device immediately after previous resilver completed.
Describe how to reproduce the problem
All I did was run
Once the initial resilver completed, it apparently started over from scratch without exiting.
Include any warning/errors/backtraces from the system logs
% zpool status -v
pool: tank
state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Sun Sep 29 18:58:47 2019
1.61T scanned at 254M/s, 784G issued at 121M/s, 2.88T total
784G resilvered, 26.60% done, 0 days 05:05:31 to go
config:
errors: No known data errors
The text was updated successfully, but these errors were encountered: