zfs discuss - Jan 2010 - abusing zfs boot disk for fun and DR

I''m in the process of standing up a couple of t5440''s, of
which the
config will eventually end up in another data center 6k miles from
the original config, and I''m supposed to send disks to the data
center and we''ll start from there (yes, I know how to flar and
jumpstart.
When the boss says do something, sometimes you *just* have to do it)

As I''ve already run into the boot failsafe when moving a root disk from
one sparc host to another, I recently found out that a sys-unconfig''d
disk
does  not suffer from the same problem.

While I am probably going to be told, I shouldn''t be doing this,
I ran into an interesting "semantics" issue that I think zfs should
at least be able to avoid (and which I have seen in other non-abusive
configurations..... ;-)

2 zfs disk, root mirrored. c2t0 and c2t1.

hot unplug c2t0, (and I should probably have removed the
busted mirror from c2t1, but I didn''t)

sys-unconfig disk in c2t1

move disk to new t5440

boot disk, and it enumerates everything correctly and then I notice
zpool thinks it''s degraded.  I had added the mirror after I realized
I wanted to run this by the list....

  pool: rpool
 state: DEGRADED
status: One or more devices could not be used because the label is missing or
        invalid.  Sufficient replicas exist for the pool to continue
        functioning in a degraded state.
action: Replace the device using ''zpool replace''.
   see: http://www.sun.com/msg/ZFS-8000-4J
 scrub: resilver completed after 0h7m with 0 errors on Thu Jan  7 12:10:03 2010
config:

        NAME          STATE     READ WRITE CKSUM
        rpool         DEGRADED     0     0     0
          mirror      DEGRADED     0     0     0
            c2t0d0s0  ONLINE       0     0     0
            c2t0d0s0  FAULTED      0     0     0  corrupted data
            c2t3d0s0  ONLINE       0     0     0  13.8G resilvered


Anyway, should zfs report a faulted drive of the same ctd# which is
already active?  I understand why this happened, but from a logistics
perspective, shouldn''t zfs be smart enough to ignore a faulted disk
like this?  And this is not the first time I''ve had this scenario
happen
(I had an x4500 that had suffered through months of marvell driver
bugs and corruption, and we probably had 2 or 3 of these types of
things happen while trying to "soft" fix the problems).  This also
happened with hot-spares, which caused support to spend some time
with back-line to figure out a procedure to clear those fauled disks
which had the same ctd# as a working hot-spare.......

Ben
-- 
This message posted from opensolaris.org

Ben,
I have found that booting from cdrom and importing the pool on the new host,
then boot the hard disk will prevent these issues.
That will reconfigure the zfs to use the new disk device.
When running, zpool detach the missing mirror device and attach a new one.

Mark.
-- 
This message posted from opensolaris.org

> Ben,
> I have found that booting from cdrom and importing
> the pool on the new host, then boot the hard disk
> will prevent these issues.
> That will reconfigure the zfs to use the new disk
> device.
> When running, zpool detach the missing mirror device
> and attach a new one.
Thanks.  I''m well versed in dealing with zfs issues. The reason
I reported this boot/rpool issue, was that it was similar in
nature to issues that occured trying to remediate an
x4500 which had suffered may sata disks go offline (due to
the buggy Marvell driver) as well as corruption that occured
while trying to fix said issue.  Backline spent a fair amount 
of time just trying to remediate the issue with hot spares
that looked exactly like the faulted config in my rpool.
-- 
This message posted from opensolaris.org