How to CLONE (not replace) ZFS members to new disks.

Hello,

I built a RAIDZ array of 8 x 2TB member disks. Long story short, the array is FAULTED due to a power failure, but all drives are ONLINE.

I am taking steps to restore the array to a previous uberblock, and will update my thread soon chronicling what worked and what didn't. At the moment, my attempts to restore with
Code:
zpool import -f -T  ZFSstore
terminate prematurely with repeated read/time out errors on three drives. The three culprits are ALL WD20EARS drives, and these three are only the WD20EARS drives in the array. Apparently the heavy I/O (16+ hours) involved in the forced import doesn't suit them, no matter if I connect them via the 8-bay enclosure + SATA controller card, or directly to the motherboard's SATA connectors.

Now I am thinking to CLONE the ZFS slices on these drives--not offlining and replacing them via ZFS commands (which aren't available for non-imported pools). Instead, I want perfect, working clones that can be substituted in without zpool knowing the difference.

Q1: Please, how do I do this? I think dd is the answer, but how?

Consider how I set up the drives: For each member disk, I created a small waste slice at the beginning, so that I'd never have problems replacing failing members with 2TB drives of slightly different sector numbers or size. See below for an example of the structure, which is the same on all 8 drives:

Geom name: da1
1. Name: da1p1
Mediasize: 2147483648 (2.0G)
2. Name: da1p2
Mediasize: 1998251367936 (1.8T)

Here are all further details which I don't really understand:

Code:
Geom name: da1
state: OK
fwheads: 255
fwsectors: 63
last: 3907029134
first: 34
entries: 128
scheme: GPT
Providers:
1. Name: da1p1
   Mediasize: 2147483648 (2.0G)
   Sectorsize: 512
   Mode: r0w0e0
   rawuuid: d7266a00-fdc4-11e0-bcfc-000c291d584e
   rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
   label: (null)
   length: 2147483648
   offset: 65536
   type: freebsd-swap
   index: 1
   end: 4194431
   start: 128
2. Name: da1p2
   Mediasize: 1998251367936 (1.8T)
   Sectorsize: 512
   Mode: r0w0e0
   rawuuid: d72e4077-fdc4-11e0-bcfc-000c291d584e
   rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
   label: (null)
   length: 1998251367936
   offset: 2147549184
   type: freebsd-zfs
   index: 2
   end: 3907029134
   start: 4194432
Consumers:
1. Name: da1
   Mediasize: 2000398934016 (1.8T)
   Sectorsize: 512
   Mode: r0w0e0

With that structure in mind, and the fact that ZFS/zpool must take the clones as the originals:

Q2: What are the dd commands to create perfect clone of each WD20EARS disk. More specifically, how do I create the duplicate structure and/or shrink the waste-slice as necessary to accommodate slightly different disks without zpool getting annoyed?

I've scoured the Internet about WDEARS20, TLER, RAID and ZFS and found the reports inconsistent. Some articles/posts say that with FreeBSD and ZFS the limitations of WDEARS20 shouldn't matter, and that ZFS will wait until the disks recover. <-- This has not been my experience. Others say WDEARS20 is a definite no-no in ANY RAID configuration.

Q3: Given that ALL and ONLY these three WD20EARS drives are reporting problems, do you think I'm right that cloning them to non-WD20EARS 2TB drives will cure my problem and allow the forced import command to complete?

Q4: Are there any commands I could use to help with the timeouts and read errors related to these three drives, thereby obviating the need for clones?

Q5: Any other thoughts on my problem and strategy? I am basically a Unix newb and definitely on a steep learning curve here, but desperate to get my array back online.


Many thanks,
LSDave
 
I was 99% through a long post when Firefox's brain-dead key and mouse shortcuts took me to Google and erased it all.

So, hell with it. Blah, gpart(8) show, ZFS may be too smart to fall for copies, gpart(8) backup and recover, disconnect all other disks, make sure of device numbers, dd(1) to copy each partition to the matching partition on the new drive, take your time.
 
wblock@ said:
I was 99% through a long post when Firefox's brain-dead key and mouse shortcuts took me to Google and erased it all.

So, hell with it. Blah, gpart(8) show, ZFS may be too smart to fall for copies, gpart(8) backup and recover, disconnect all other disks, make sure of device numbers, dd(1) to copy each partition to the matching partition on the new drive, take your time.

Thanks for the reply. I would have appreciated a long post and am sorry to hear you lost it. :(

I am running
Code:
dd if=/dev/ada6p2 of=/dev/null bs=1m
on one of the WD20EARS right now, just to see if timeout errors occurs. So far it's run fine.

While I wait, are there any "hints.something.something = " or something like "kern.geom.mirror.timeout:" values I can play with (as an alternative to cloning) that might give these drives more time to respond or recover from read errors?

What do you think about the fact that all three problematic drives are the same make? This is a valuable clue, yes? Unlikely that we are talking about data corruption and more likely a timing issue, don't you think?
 
wblock@ said:
Oh, timeout suggestions were in there also. Disabling power save with sysutils/ataidle, maybe some sysctls(8) for the controller or even ZFS, possibly settings with camcontrol(8).

Disabling power save would be the first thing to try, but some WD drives ignore that.

ATAidle: I can't believe there is NO power management support.

Code:
root@temp:/sbin # ataidle /dev/ada6
Model:                  WDC WD20EARS-60MVWB0
Serial:                 WD-WCAZA8381769
Firmware Rev:           51.0AB51
ATA revision:           ATA-8
LBA 48:                 yes
Geometry:               16383 cyls, 16 heads, 63 spt
Capacity:               1863GB
SMART Supported:        yes
SMART Enabled:          yes
Write Cache Supported:  yes
Write Cache Enabled:    yes
APM Supported:          no
AAM Supported:          no

sysctls: I read through the whole man page. I can't see anything there that would help.

camcontrol: I had some luck with this man page. I ran these:

Code:
root@temp:/sbin # camcontrol idle ada6 -t 0
root@temp:/sbin # camcontrol standby ada6 -t 0
root@temp:/sbin # camcontrol standby ada7 -t 0
root@temp:/sbin # camcontrol standby ada8 -t 0
root@temp:/sbin # camcontrol idle ada7 -t 0
root@temp:/sbin # camcontrol idle ada8 -t 0

Retrying the forced zpool import now....
 
Back
Top