My customer's zfs pools and their 6540 disk array had a firmware upgrade that
changed GUIDs so we need a procedure to let the zfs know it changed. They are
getting errors as if they replaced drives. But I need to make sure you know
they have not "replaced" any drives, and no drives have failed or are "bad". As
such, they have no interest in wiping any disks clean as indicated in 88130
info doc.
Some background from customer:
We have a large 6540 disk array, on which we have configured a series of
large RAID luns. A few days ago, Sun sent a technician to upgrade the
firmware of this array, which worked fine but which had the deleterious
effect of changing the "Volume IDs" associated with each lun. So, the
resulting luns now appear to our solaris 10 host (under mpxio) as disks in
/dev/rdsk with different 'target' components than they had before.
Before the firmware upgrade we took the precaution of creating duplicate
luns on a different 6540 disk array, and using these to mirror each of our
zfs pools (as protection in case the firmware upgrade corrupted our luns).
Now, we simply want to ask zfs to find the devices under their new
targets, recognize that they are existing zpool components, and have it
correct the configuration of each pool. This would be similar to having
Veritas vxvm re-scan all disks with vxconfigd in the event of a
"controller renumbering" event.
The proper zfs method for doing this, I believe, is to simply do:
zpool export mypool
zpool import mypool
Indeed, this has worked fine for me a few times today, and several of our
pools are now back to their original mirrored configuration.
Here is a specific example, for the pool "ospf".
The zpool status after the upgrade:
diamond:root[1105]->zpool status ospf
pool: ospf
state: DEGRADED
status: One or more devices could not be opened. Sufficient replicas
exist for
the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
see: http://www.sun.com/msg/ZFS-8000-D3
scrub: resilver completed with 0 errors on Tue Dec 11 18:26:53 2007
config:
NAME STATE READ WRITE CKSUM
ospf DEGRADED 0 0 0
mirror DEGRADED 0 0 0
c27t600A0B8000292B0200004BDC4731A7B8d0 UNAVAIL 0 0 0
cannot open
c27t600A0B800032619A0000093747554A08d0 ONLINE 0 0 0
errors: No known data errors
This is due to the fact that the LUN which used to appear as
c27t600A0B8000292B0200004BDC4731A7B8d0 is now actually
c27t600A0B8000292B0200004D5B475E6E90d0. It's the same LUN, but since the
firmware changed the Volume ID, the target portion is different.
Rather than treating this as a "replaced" disk (which would incur an
entire mirror resilvering, and would require the "trick" you sent of
obliterating the disk label so the "in use" safeguard could be avoided),
we simply want to ask zfs to re-read its configuration to find this disk.
So we do this:
diamond:root[1110]->zpool export -f ospf
diamond:root[1111]->zpool import ospf
and sure enough:
diamond:root[1112]->zpool status ospf
pool: ospf
state: ONLINE
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.
scrub: resilver in progress, 0.16% done, 2h53m to go
config:
NAME STATE READ WRITE CKSUM
ospf ONLINE 0 0 0
mirror ONLINE 0 0 0
c27t600A0B8000292B0200004D5B475E6E90d0 ONLINE 0 0 0
c27t600A0B800032619A0000093747554A08d0 ONLINE 0 0 0
errors: No known data errors
(Note that it has self-initiated a resilvering, since in this case the
mirror has been changed by users since the firmware upgrade.)
The problem that Robert had was that when he initiated an export of a pool
(called "bgp") it froze for quite some time. The corresponding "import"
of the same pool took 12 hours to complete. I have not been able to
replicate this myself, but that was the essence of the problem.
So again, we do NOT want to "zero out" any of our disks, we are not trying
to forcibly use "replaced" disks. We simply wanted zfs to re-read the
devices under /dev/rdsk and update each pool with the correct disk
targets.
If you can confirm that a simple export/import is the proper procedure for
this (followed by a "clear" once the resulting resilvering finishes), I
would appreciate it. And, if you can postulate what may have caused the
"freeze" that Robert noticed, that would put our minds at ease.
TIA,
Any assistance on this would be greatly appreciated and or pointers on helpful
documentation.
--
S U N M I C R O S Y S T E M S I N C.
Jill Manfield - TSE-OS Administration Group
email: [EMAIL PROTECTED]
phone: (800)USA-4SUN (Reference your case number)
address: 1617 Southwood Drive Nashua,NH 03063
mailstop: NSH-01- B287
OS Support Team 9AM to 6PM EST
Manager [EMAIL PROTECTED] x74110
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
