reconfiguring stripes
in [Solaris]
|
From: David Mathog on 14 Jul 2010 19:09 (Also posted to comp.sys.sun.admin) On a Solaris 9 v880 system we currently have two stripe sets (probably not the right Solaris terminology) like this (A): d50 1 4 /dev/dsk/c1t2d0s0 \ /dev/dsk/c1t3d0s0 \ /dev/dsk/c1t4d0s0 \ /dev/dsk/c1t5d0s0 d60 1 4 /dev/dsk/c4t0d0s2 \ /dev/dsk/c4t1d0s2 \ /dev/dsk/c3t8d0s2 \ /dev/dsk/c3t9d0s2 d50 disks are internal 73GB fiber channel, d60 disks are 147GB u320. One of the internal disks is starting to fail (accumulate write errors) and it will be removed, with another 147 GB u320 disk added to the external array. So the end point will be this (B): d50 1 3 /dev/dsk/c1t2d0s0 \ /dev/dsk/c1t3d0s0 \ /dev/dsk/c1t5d0s0 d60 1 5 /dev/dsk/c4t0d0s2 \ /dev/dsk/c4t1d0s2 \ /dev/dsk/c4t2d0s2 \ /dev/dsk/c3t8d0s2 \ /dev/dsk/c3t9d0s2 Is it correct that the only way to get from (A) to (B) is to backup d50 and d60, metaclear, remake d50 and d60, and restore? Also, is "format" run after a "boot -s" the only way to label a new disk? I recall last time a new disk was added to the system that it was impossible to boot until that disk had a label applied, Solaris wouldn't get beyond the unrecognized disk label problem. Eventually "format" was found to be able to do this, but I remember wondering at the time if there was not a way to accomplish this in openboot instead. Thanks, David Mathog
From: Cydrome Leader on 15 Jul 2010 00:39 David Mathog <dmathog(a)gmail.com> wrote: > (Also posted to comp.sys.sun.admin) > > On a Solaris 9 v880 system we currently have two stripe sets (probably > not the right Solaris terminology) like this (A): > > d50 1 4 /dev/dsk/c1t2d0s0 \ > /dev/dsk/c1t3d0s0 \ > /dev/dsk/c1t4d0s0 \ > /dev/dsk/c1t5d0s0 > > d60 1 4 /dev/dsk/c4t0d0s2 \ > /dev/dsk/c4t1d0s2 \ > /dev/dsk/c3t8d0s2 \ > /dev/dsk/c3t9d0s2 > > d50 disks are internal 73GB fiber channel, d60 disks are 147GB u320. > One of the internal disks > is starting to fail (accumulate write errors) and it will be removed, > with another 147 GB u320 disk added > to the external array. So the end point will be this (B): > > d50 1 3 /dev/dsk/c1t2d0s0 \ > /dev/dsk/c1t3d0s0 \ > /dev/dsk/c1t5d0s0 > > d60 1 5 /dev/dsk/c4t0d0s2 \ > /dev/dsk/c4t1d0s2 \ > /dev/dsk/c4t2d0s2 \ > /dev/dsk/c3t8d0s2 \ > /dev/dsk/c3t9d0s2 > > Is it correct that the only way to get from (A) to (B) is to backup > d50 and d60, metaclear, remake d50 and d60, and restore? I'm not quite following why you want to shrink d50 and grow d60. I've not tried to relocate a disk in a stripe with disksuite, but it would not surprise me if it doesn't support this correctly or it just doesn't work at all. In general, growing a disksuite stripe is no problem, and you can do this on a live filesystem. Shrinking a filesytem is another issue, and might requite having free space and a backup and restore. Veritas can do this (disk relocation) , if you have the correct level of licensing. Shrinking a live vxfs file sytem is sort of hit or miss. In my opinion, disksuite is heap of garbage and tends to cause more problems that it solves most of the time. > Also, is "format" run after a "boot -s" the only way to label a new > disk? I recall last time a new disk was added to the system that it no. you can label a fresh disk with format while a machine is running, even if a disk has been added "hot". just run cfgadm -al; devfsadm -Cv then run format and select your new disk. format will probably tell you it's not labelled and ask if you want or do so. Say yes and that's it. your disk is ready for use with disksuite or whatever volume manager you like. > was impossible to boot until that disk had a label applied, Solaris > wouldn't get beyond the unrecognized disk label problem. Eventually > "format" was found to be able to do this, but I remember wondering at > the time if there was not a way to accomplish this in openboot > instead. I'm not aware of a way to do this from the PROM.
From: David Mathog on 15 Jul 2010 11:50 On Jul 14, 9:39 pm, Cydrome Leader <prese...(a)MUNGEpanix.com> wrote: > David Mathog <dmat...(a)gmail.com> wrote: > I'm not quite following why you want to shrink d50 and grow d60. d50 has a failing disk for which we have no replacement, we do have a disk that can be added to d60. So shrink d50, and grow d60. A disk isn't moving from one to the other, the d50 disk is going into the ewaste and a new disk is going into d60. >. In general, growing a disksuite stripe is no problem, and you can > do this on a live filesystem. By concatenating, but not, as far as I can tell, by redoing the stripes. All the examples I could find where a single disk was added concatenated the whole disk to the existing stripe set (but not apparently striping it). That is, the new bigger part of the grown file system would be sequential over the new disk, and so several times slower than the parts striped across the other 4 disks. > > was impossible to boot until that disk had a label applied, Solaris > > wouldn't get beyond the unrecognized disk label problem. Eventually > > "format" was found to be able to do this, but I remember wondering at > > the time if there was not a way to accomplish this in openboot > > instead. > > I'm not aware of a way to do this from the PROM. OK, just wanted to be sure I wasn't missing something. Thanks, David Mathog
From: hume.spamfilter on 15 Jul 2010 14:44 David Mathog <dmathog(a)gmail.com> wrote: > By concatenating, but not, as far as I can tell, by redoing the > stripes. All the examples I could find where a single disk was added > concatenated the whole disk to the existing stripe set (but not A stripe isn't a high-availability disk arrangement... in fact, it could be argued it's a high-UNavailability arrangement (your risk of failure is multiplied by the number of disks in the stripe...) The data on each unit in the stripe isn't replicated onto any of the others. So when you tear that disk out, it's portion of the data is simply gone, the others can't fill it in. You *might* be able to get away with a raw byte-for-byte copy of the underlying device to the new disk, but that'd be very risky. I think you're pretty much in a backup, rebuild, and restore situation. If you have the money for more disks, it might be a very good time to switch to a raid 1+0 setup. -- Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/
|
Pages: 1 Prev: Solaris 8 and 10 producing different assembly with gcc 3.4.4 Next: T5220 can't load specfs |