Thank you for reading and replying :-)
2012-05-22 6:18, Bob Friesenhahn wrote:
On Mon, 21 May 2012, Jim Klimov wrote:
This is so far a relatively raw idea and I've probably missed
something. Do you think it is worth pursuing and asking some
zfs developers to make a POC? ;)
I did read all of your text. :-)
This is an interesting idea and could be of some use but it would be
wise to test it first a few times before suggesting it as a general
course. Zfs is still totally not foolproof. I still see postings from
time to time regarding pools which panic/crash the system (probably due
to memory corruption).
Zfs will try to keep the data compacted at the beginning of the
partition so if you have a way to know how far out it extends, then the
initial 'dd' could be much faster when the pool is not close to full.
For a not-full not-fragmented pool it is likely that a run
of the original resilvering would be faster and known to
be correct ;)
Zfs scrub does need to do many more reads than a resilver since it reads
all data and metadata copies. Triggering a resilver operation for the
specific disk would likely hasten progress.
Well, the point in this case was for a "selective scrub" as
I called it in the text, which would indeed read all blocks
and dittos, if their DVA lies on that VDEV where we replaced
the disk and expect discrepancies. In this limitation it is
like a resilver, but is indeed a scrub in effect.
Besides, from what I've seen, a resilver just rewrites the
given range of TXGs (like [0-current]) on the target disk
based on reads from other disks in the TLVDEV and on the
assumption that up to some TXG point (zero or above) that
disk had valid data matching other disks in the array.
Here, after the DD-stage, we have no guarantee that the
source disk was fully valid (just a hope, augmented by
lack of read errors and timeouts during the DD-phase),
and to some degree we don't know if the writes that came
in during the replacement process were properly written
onto the target disk as well as its counterpart being
replaced and still a (more) valid part of the pool.
If we do that write-cloning and if the source disk was
okay, the scrub shouldn't find any errors I think.
//Jim Klimov
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
