On 2013-01-19 20:23, Jim Klimov wrote:
On 2013-01-19 20:08, Bob Friesenhahn wrote:
On Sat, 19 Jan 2013, Jim Klimov wrote:
On 2013-01-19 18:17, Bob Friesenhahn wrote:
Resilver may in fact be just verifying that the pool disks are coherent
via metadata. This might happen if the fiber channel is flapping.
Correction: that (verification) would be scrubbing ;)
I don't think that zfs would call it scrubbing unless the user requested
scrubbing. Unplugging a USB drive which is part of a mirror for a short
while results in considerable activity when it is plugged back in. It
is as if zfs does not trust the device which was temporarily unplugged
and does a full validation of it.
Now, THAT would be resilvering - and by default it should be a limited
one, with a cutoff at the last TXG known to the disk that went MIA/AWOL.
The disk's copy of the pool label (4 copies in fact) record the last
TXG it knew safely. So the resilver should only try to validate and
copy over the blocks whose BP entries' birth TXG number is above that.
And since these blocks' components (mirror copies or raidz parity/data
parts) are expected to be missing on this device, mismatches are likely
not reported - I am not sure there's any attempt to even detect them.
And regarding the "considerable activity" - AFAIK there is little way
for ZFS to reliably read and test "TXGs newer than X" other than to
walk the whole current tree of block pointers and go deeper into those
that match the filter (TLVDEV number in DVA, and optionally TXG numbers
in birth/physical fields).
So likely the resilver does much of the same activity that a full scrub
would - at least in terms of reading all of the pool's metadata (though
maybe not all copies thereof).
My 2c and my speculation,
//Jim
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
