Asset ID:	1-72-1020033.1
Update Date:	2009-06-14
Keywords:

---

Solution Type  Problem Resolution Sure

Solution  1020033.1 :   SE3xxx - After growing LD, new size is not reflected on host  


PreviouslyPublishedAs
251226

Symptoms
SYMPTOMS
Even after growing an LD on an SE3xxx array (SE3510, SE3310, SE3511, or SE3320), the LUN remains the same size on the server.

EXAMPLE

Originally, the LD definitions, as shown by the 'sccli show logical' command, are as follows:

   LD    LD-ID        Size  Assigned  Type   Disks Spare  Failed Status
   ------------------------------------------------------------------------
   ld0   583CA30F 930.51GB  Primary   RAID5  5     1      0      Good
                            Write-Policy Default          StripeSize 128KB
   ld1   1837A0AD 930.51GB  Secondary RAID5  5     1      0      Good
                            Write-Policy Default          StripeSize 128KB

after the LD0 was grown to 1.14TB, the output now appears as:

   LD    LD-ID        Size  Assigned  Type   Disks Spare  Failed Status
   ------------------------------------------------------------------------
   ld0   583CA30F   1.14TB  Primary   RAID5  6     1      0      Good
                            Write-Policy Default          StripeSize 128KB
   ld1   1837A0AD 930.51GB  Secondary RAID5  5     1      0      Good
                            Write-Policy Default          StripeSize 128KB

However, the 'format' command and the 'prtvtoc' command on the solaris host still see only the old size of ~930GB.

   * /dev/rdsk/c4t600C0FF000000000006B2E1837A0AD00d0s0 partition map
   *
   *                          First     Sector    Last
   * Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
          0      2    00          0    267840    267839
          1      3    01     267840    267840    535679
          2      5    01          0 1950262080 1950262079
          6      4    00     535680 1949726400 1950262079

Resolution
RESOLUTION
Remember first and foremost that when an LD is grown on an SE3xxx array, the new space is appended to the end of the existing device and a new "partition" is create dwith this space.  The 'sccli' command 'show partition' is useful in illustrating this.  Originally, our partitions would have looked like this:

   LD/LV    ID-Partition        Size
   -------------------------------------
   ld0-00   583CA30F-00     930.51GB
   ld1-00   1837A0AD-00     930.51GB

but after expanding LD0 to 1.14TB, we will see the following partitions:

   LD/LV    ID-Partition        Size
   -------------------------------------
   ld0-00   583CA30F-00     930.51GB
   ld0-01   583CA30F-01     236.85GB
   ld1-00   1837A0AD-00     930.51GB

Since it's the partition that is mapped to the host, not the LD, the host will never see the additional 236GB as being part of the existing LUN.  In fact, to see the 236GB on the host at all, you will need to map that new partition yourself, but it will show up on the host as a separate LUN.

However, what if you wanted to see a 1.14TB LUN on the host?  Well, you could use the sccli command or the array's firmware menu interface to remove the newly created partition (in our case, partition ld0-1), which will shift the extra space on that LD over to the previous partition (ld0-00).  Then, you will see something similar to the following:

   LD/LV    ID-Partition        Size
   -------------------------------------
   ld0-00   583CA30F-00    1167.36GB
   ld1-00   1837A0AD-00     930.51GB

Now, the problem still remains: how to get the host to recognize the LUN'snew size.  Read on...

One of the things that could be causing this is that since the device was grown, it must be relabeled using the 'format' utility.

If you are using VxVM (Veritas Volume Manager), see SunSolve[SM] knowledge technical instruction <Document: 1006141.1> , titled "How to get VxVM to recognize that a hardware-RAID LUN has been grown", which explains specific ways to get VxVM to recognize the new size of the device.

Outside of VxVM, however, devices do not just automatically relabel themselves when the underlying device (LUN) is grown.  In order to relabel a disk, start the 'format' utility and select this specific disk.  Then, use the 'type' submenu.  When asked to specify the disk type, enter "0" (for"Auto Configure").

Specify disk type (enter its number)[19]: 0
Auto configuration via format.dat[no]? no
Auto configuration via generic SCSI-2[no]? no

That typically will write a new standard SUN SMI label to the disk.  Of course, if you had created a customer partition table on the disk previously, that will be gone now, so you will have to repartition the disk so that you can access the data that was on there previously. This can be tricky, and is outside the scope of this document.

In our example above, however, we grew a LUN which was LESS than 1TB to one that is GREATER than 1 TB.  Since all devices larger than 1TB require an EFI label (as opposed to an SMI VTOC label), you will have to use the 'format -e' command to relabel the disk, and you will need to change the label type to EFI.  Be well aware that this change will most likely result in the loss of data on this disk because of the differences between SMI VTOC labels and EFI labels.  See technical instruction <Document: 1019743.1> , titled "Converting disks from SMI labels to EFI labels (and recovering data on them)", for a complete discussion of this.

Product
Sun StorageTek 3310 SCSI Array
Sun StorageTek 3320 SCSI Array
Sun StorageTek 3510 FC Array JBOD
Sun StorageTek 3511 SATA Array

grow, lun, LD, logical volume, vxdisk resize, vtoc, efi, partition

Attachments

This solution has no attachment