On 10/18/06, Brett Albertson <brett.albertson at stratech.com> wrote:
> To Solaris, you grew a disk with a label already on it. The label says > that each slice represents a certain number of sectors on the disk. So, > for example, let's say SVM was using slice 0 which went from sector 0 > to 5,000. You grew the disk from 5,000 sectors to 10,000 sectors, but > that didn't grow slice 0 at all. Yup, we understand that :-) > So, there are two ways to do this, the easy way or the hard way. > Easy way: Just add a new LUN (not grow the old one) and grow > the metadevice with metainit, metattach, and growfs. We are trying to avoid using this method. We tend to do a lot of growing FSes as out end users never know how much space they need. We have been using Soft Partitions for this with very good resulsts. Given that we do a lot of growing, we will end up using many more LUNs this way, and we have a limited number of them. > Hard way: This is completely unsupported (I would think), but you > could try to grow the disk, then go into format and make the slice you > are using bigger, then you could try to get SVM to use this new space > (This is the part that I don't know if it can work), and then growfs. This is what we are trying to do. Here is what we have tried: 1. go into SAN management and grow underlying Volume 2. go into FORMAT and _carefully_ relabel and partition the LUN so that the slice we are using starts at the same block but extends to the end of the new larger LUN. 3. try to get SLVM to recognize the new, larger LUN that a Concat/Stripe is based on ... this is where we have been unsuccessful. We could destroy (metaclear) the device and rebuild it (metainit), but that is dicey if we have many soft partitions on the device. > I would say, use the easy way. This is why you are using SVM and not > straight slices, right? Not really. If we use the device directly, once the Volume on the SAN is grow, then we just have to label and partition (carefully) and then run growfs. The metadevice layer gets us a management abstraction (via Disk Sets) and the ability to move the FSes to other storage (via the mirror device) transparently. Our current plan (and this is still up for review) is to use a configuration similar to the following: d100 1 1 /dev/dsk/<MPxIO device for LUN on the SAN> d101 -m d100 d102 -p d101 10g d103 -p d101 10g d104 -p d101 30g ... etc. where d102-d10x are filesystems related to one service (like and Oracle non-global zone ... I know, I know, there are issues upgrading MPxIO filesystems with zones ...) The above metadevices may all be in a Disk Set associated with a certain non-global zone (to facilitate migrating a non-global zone to another server). We are _trying_ to plan for the future. The one-way mirror will allow us to migrate the filesystems to other storage (a new SAN, for example) with no outage to the end users. Or to migrate from a concat device to a stripe device ... we like to keep our oprions open, as we have had to do some really weird stuff in the past. We could just add another LUN to the d100 concat device, but that isn't as clean. Being able to resize the concat device d100 would be the simplest answer from our perspective :-) I suspect that the only 'meta...' command that understands changing device sizes is metattach (can grow a mirror to fill components, can grow a soft partition). I suspect that there is no function (yet ???) to grow a concat to fill an underlying device (and that is really what we want). metainit sets the size of the concat (or stripe) device when initialized and I don't know of any way to update that size. -- Paul Kraus
