meta device recover

I am running two solaris 10 /x86 servers which see via a fibre channel switch 5 RAIDs

and a total of 48 "disk" devices. On one of the servers there are 4 filesystems configured with between 4 - 8 TBytes capacity. One the other server there are 3 filesystems configured.

3 of the 4 and the 3 of the 3 filesystems are created using lvm and striping over

two RAID systems each.

This works a treat and is fast.

Recently one of the Raids developed a controller problem and had to be replaced.

All precaution were taken to make sure that all of the NVRAM configuration data were

saved on disk and re-loaded onto the new RAID. However when the fileservers were

booted up the 11 "devices" offered by the replacement RAID had changed. and the

metadevices could not be rebuilt.

There are still 11 devices; I can clearly identify the ones were the names were changed

and I have md.dat file with the "old" configuration. Could I carefully edit the

md.dat file replacing the names of the devices offered by the replaced RAID with the new

names? and could I use a metacommand on this md.dat file to re-import the metadevices without jeopardizing the data. If I can and people know about the procedure I would be grateful if this you could tell me.

The replacement RAID and the second RAID participating in the stripes are all in full

working order and deemed as "good".

format0. c1t0d0 <DEFAULT cyl 4455 alt 2 hd 255 sec 63>

/pci@0,0/pci1022,7450@a/pci9005,286@2/sd@0,0

1. c6t600D0230006A5D7A0A550B64D149980Ad0 <DEFAULT cyl 43984 alt 2 hd 255 sec 126>

/scsi_vhci/disk@g600d0230006a5d7a0a550b64d149980a

2. c6t600D0230006A5D7A0A550B64D1499800d0 <DEFAULT cyl 63738 alt 2 hd 255 sec 126>

/scsi_vhci/disk@g600d0230006a5d7a0a550b64d1499800

3. c6t600D0230006A5D7A0A550B64D1499801d0 <DEFAULT cyl 63738 alt 2 hd 255 sec 126>

/scsi_vhci/disk@g600d0230006a5d7a0a550b64d1499801

4. c6t600D0230006A5D7A0A550B64D1499802d0 <DEFAULT cyl 63738 alt 2 hd 255 sec 126>

/scsi_vhci/disk@g600d0230006a5d7a0a550b64d1499802

5. c6t600D0230006A5D7A0A550B64D1499803d0 <DEFAULT cyl 63738 alt 2 hd 255 sec 126>

/scsi_vhci/disk@g600d0230006a5d7a0a550b64d1499803

6. c6t600D0230006A5D7A0A550B64D1499804d0 <DEFAULT cyl 63738 alt 2 hd 255 sec 126>

/scsi_vhci/disk@g600d0230006a5d7a0a550b64d1499804

7. c6t600D0230006A5D7A0A550B64D1499805d0 <DEFAULT cyl 63738 alt 2 hd 255 sec 126>

/scsi_vhci/disk@g600d0230006a5d7a0a550b64d1499805

8. c6t600D0230006A5D7A0A550B64D1499806d0 <DEFAULT cyl 63739 alt 2 hd 255 sec 126>

/scsi_vhci/disk@g600d0230006a5d7a0a550b64d1499806

9. c6t600D0230006A5D7A0A550B64D1499807d0 <DEFAULT cyl 63738 alt 2 hd 255 sec 126>

/scsi_vhci/disk@g600d0230006a5d7a0a550b64d1499807

10. c6t600D0230006A5D7A0A550B64D1499808d0 <DEFAULT cyl 42072 alt 2 hd 255 sec 126>

/scsi_vhci/disk@g600d0230006a5d7a0a550b64d1499808

11. c6t600D0230006A5D7A0A550B64D1499809d0 <DEFAULT cyl 42072 alt 2 hd 255 sec 126>

/scsi_vhci/disk@g600d0230006a5d7a0a550b64d1499809

12. c6t600D0230006A5D9E0C25552F7DCF8E0Ad0 <DEFAULT cyl 43984 alt 2 hd 255 sec 126>

/scsi_vhci/disk@g600d0230006a5d9e0c25552f7dcf8e0a

13. c6t600D0230006A5D9E0C25552F7DCF8E00d0 <transtec-T6100F24R1-E-347B-976.56GB>

/scsi_vhci/disk@g600d0230006a5d9e0c25552f7dcf8e00

14. c6t600D0230006A5D9E0C25552F7DCF8E01d0 <DEFAULT cyl 63738 alt 2 hd 255 sec 126>

/scsi_vhci/disk@g600d0230006a5d9e0c25552f7dcf8e01

15. c6t600D0230006A5D9E0C25552F7DCF8E02d0 <DEFAULT cyl 63738 alt 2 hd 255 sec 126>

/scsi_vhci/disk@g600d0230006a5d9e0c25552f7dcf8e02

16. c6t600D0230006A5D9E0C25552F7DCF8E03d0 <DEFAULT cyl 63738 alt 2 hd 255 sec 126>

/scsi_vhci/disk@g600d0230006a5d9e0c25552f7dcf8e03

17. c6t600D0230006A5D9E0C25552F7DCF8E04d0 <DEFAULT cyl 63738 alt 2 hd 255 sec 126>

...

...

IN the following md,dat file (which I made readable for this purpose by putting each device on a separate line )

the first 4 devices in each of the sets would have to be replaced with a modified

device name. where c6t600D0230006A29610A249403E28A8D0

would have to be replaced by c6t600D0230006B37C60A249403E28A8D0

cat md.dat

data1/d1 1 8

/dev/dsk/c6t600D0230006A29610A249403E28A8D00d0s0

/dev/dsk/c6t600D0230006A29610A249403E28A8D01d0s0

/dev/dsk/c6t600D0230006A29610A249403E28A8D02d0s0

/dev/dsk/c6t600D0230006A29610A249403E28A8D03d0s0

/dev/dsk/c6t600D0230006A5D990F54325A25614400d0s0

/dev/dsk/c6t600D0230006A5D990F54325A25614401d0s0

/dev/dsk/c6t600D0230006A5D990F54325A25614402d0s0

/dev/dsk/c6t600D0230006A5D990F54325A25614403d0s0 -i 256b

data2/d1 1 8

/dev/dsk/c6t600D0230006A29610A249403E28A8D04d0s0

/dev/dsk/c6t600D0230006A29610A249403E28A8D05d0s0

/dev/dsk/c6t600D0230006A29610A249403E28A8D06d0s0

/dev/dsk/c6t600D0230006A29610A249403E28A8D07d0s0

/dev/dsk/c6t600D0230006A5D990F54325A25614404d0s0

/dev/dsk/c6t600D0230006A5D990F54325A25614405d0s0

/dev/dsk/c6t600D0230006A5D990F54325A25614406d0s0

/dev/dsk/c6t600D0230006A5D990F54325A25614407d0s0 -i 256b

fcnew/d1 1 4

/dev/dsk/c6t600D0230006BB56D0A296548E2550200d0s0

/dev/dsk/c6t600D0230006BB56D0A296548E2550201d0s0

/dev/dsk/c6t600D0230006BB56D0A296548E2550202d0s0

/dev/dsk/c6t600D0230006BB56D0A296548E2550203d0s0 -i 256b

data3/d1 1 6

/dev/dsk/c6t600D0230006A29610A249403E28A8D08d0s0

/dev/dsk/c6t600D0230006A29610A249403E28A8D09d0s0

/dev/dsk/c6t600D0230006A29610A249403E28A8D0Ad0s0

/dev/dsk/c6t600D0230006A5D990F54325A25614408d0s0

/dev/dsk/c6t600D0230006A5D990F54325A25614409d0s0

/dev/dsk/c6t600D0230006A5D990F54325A2561440Ad0s0 -i 256b

[6002 byte] By [lydia.heck] at [2007-11-26 9:25:52]
# 1

When I replaced the RAID system the device numbers on the slices changed.

The WWN stayed the same.

In the documentation on the LVM software I could find only one reference to this for a RAID 0 system::

it said that if the controller on one of the RAID0 partners failed the device would have to be redefined. However there was no reference on how to do that.

I would like to urge the software developers of the LVM software to consider the possibility of giving access to the mddb such that a name could be changed.

In my case I knew that all the data were fully intact, that the device layout was absolutely perserved. The only thing which had changed was a name. On studying the documentation of metainit and metaset I found that by instating the new names I would fully obliterate all original structure.

With RAID space becoming cheaper and the limitations of the OS being 1 TByte, striping and concatenation is a must.

Lydia

lydiaheck at 2007-7-7 0:03:39 > top of Java-index,Solaris Operating System,Solaris 10 Features...