From: Mark on
Hi all,

V215 server attached to an IBM DS8300. It has one LUN, vpath1, that
has been grown on the back-end, as in, the SAN software tools on the
server see the increased size:

# ./datapath query essmap|grep vpath1
vpath1 c2t20d0 75FRMR1100E IBM 2107900
140.0GB 10 14 0000 0e Y R1-B3-H3-ZA 230 RAID5
vpath1 c2t21d0 75FRMR1100E IBM 2107900
140.0GB 10 14 0000 0e Y R1-B4-H1-ZA 300 RAID5
vpath1 c3t22d0 75FRMR1100E IBM 2107900
140.0GB 10 14 0000 0e Y R1-B3-H3-ZB 231 RAID5
vpath1 c3t23d0 75FRMR1100E IBM 2107900
140.0GB 10 14 0000 0e Y R1-B4-H1-ZB 301 RAID5
#

But format still sees the "old" size:

partition> p
Current partition table (original):
Total disk cylinders available: 15358 + 2 (reserved cylinders)

Part Tag Flag Cylinders Size Blocks
0 unassigned wm 0 - 15357 119.98GB (15358/0/0)
251625472
1 unassigned wu 0 0
(0/0/0) 0
2 backup wu 0 - 15357 119.98GB (15358/0/0)
251625472
3 unassigned wm 0 0
(0/0/0) 0
4 unassigned wm 0 0
(0/0/0) 0
5 unassigned wm 0 0
(0/0/0) 0
6 unassigned wm 0 0
(0/0/0) 0
7 unassigned wm 0 0
(0/0/0) 0

partition>

Is there some way to get format to see the new size without rebooting
the system? I've tried "update_drv -f sd" and "devfsadm -i vpathdd",
but neither of those has worked.

Thanks,
Mark
From: Darren Dunham on
Mark <md2600(a)gmail.com> wrote:
> But format still sees the "old" size:

Because it is coded into the label written on the LUN by solaris.

> partition> p
> Current partition table (original):
> Total disk cylinders available: 15358 + 2 (reserved cylinders)
>
> Part Tag Flag Cylinders Size Blocks
> 0 unassigned wm 0 - 15357 119.98GB (15358/0/0)
> 251625472
> 1 unassigned wu 0 0
> (0/0/0) 0
> 2 backup wu 0 - 15357 119.98GB (15358/0/0)
> 251625472

So you have a VTOC label (standard for LUNs < 1TB).

> Is there some way to get format to see the new size without rebooting
> the system? I've tried "update_drv -f sd" and "devfsadm -i vpathdd",
> but neither of those has worked.

Rebooting isn't the issue.

Fortunately, your layout on the disk is trivial (a single large slice).
It makes recreating it very easy.

Is this a raw UFS slice, or are you using a volume manager of some sort?
Assuming just a raw slice, you need to:

Have a valid backup of the data,
Unmount the filesystem,
Destroy the original disk label
(dd if=/dev/zero of=/dev/rdsk/cxtxdxs2 bs=1 count=1)
Create a new (larger) disk label
(Run format, should prompt to label disk, accept)
Slice disk as needed (apply all space to slice 0)
Run fsck on slice 0 to confirm data is still present
Mount UFS filesystem
Run 'growfs' to enlarge the mounted UFS filesystem to new size of slice.

Solaris currently doesn't have any tools that work to support changes in
LUN size. So you have to rewrite the disk label. As long as you don't
rewrite anything else on the disk, and as long as you can recreate the
old layout, all the data remains intact.

Good luck,
--
Darren
From: Cydrome Leader on
Darren Dunham <ddunham(a)taos.com> wrote:
> Mark <md2600(a)gmail.com> wrote:
>> But format still sees the "old" size:
>
> Because it is coded into the label written on the LUN by solaris.
>
>> partition> p
>> Current partition table (original):
>> Total disk cylinders available: 15358 + 2 (reserved cylinders)
>>
>> Part Tag Flag Cylinders Size Blocks
>> 0 unassigned wm 0 - 15357 119.98GB (15358/0/0)
>> 251625472
>> 1 unassigned wu 0 0
>> (0/0/0) 0
>> 2 backup wu 0 - 15357 119.98GB (15358/0/0)
>> 251625472
>
> So you have a VTOC label (standard for LUNs < 1TB).
>
>> Is there some way to get format to see the new size without rebooting
>> the system? I've tried "update_drv -f sd" and "devfsadm -i vpathdd",
>> but neither of those has worked.
>
> Rebooting isn't the issue.
>
> Fortunately, your layout on the disk is trivial (a single large slice).
> It makes recreating it very easy.
>
> Is this a raw UFS slice, or are you using a volume manager of some sort?
> Assuming just a raw slice, you need to:
>
> Have a valid backup of the data,
> Unmount the filesystem,
> Destroy the original disk label
> (dd if=/dev/zero of=/dev/rdsk/cxtxdxs2 bs=1 count=1)

Interesting. I've run into LUNS from a SAN that when re-used again are detected as the wrong size by solaris. I'm pretty sure I've tried
dd-ing over them and just formatted then in the SAN to get the size to be detected correctly again. This seems to happen if a 100GB lun is
unified with another for say 200GB.


From: Darren Dunham on
Cydrome Leader <presence(a)mungepanix.com> wrote:
> Darren Dunham <ddunham(a)taos.com> wrote:

>> Have a valid backup of the data,
>> Unmount the filesystem,
>> Destroy the original disk label
>> (dd if=/dev/zero of=/dev/rdsk/cxtxdxs2 bs=1 count=1)
>
> Interesting. I've run into LUNS from a SAN that when re-used again are detected as the wrong size by solaris. I'm pretty sure I've tried
> dd-ing over them and just formatted then in the SAN to get the size to be detected correctly again. This seems to happen if a 100GB lun is
> unified with another for say 200GB.

Which is the procedure above, yes? I don't know what "formated them in
the SAN" means.

--
Darren
From: Cydrome Leader on
Darren Dunham <ddunham(a)taos.com> wrote:
> Cydrome Leader <presence(a)mungepanix.com> wrote:
>> Darren Dunham <ddunham(a)taos.com> wrote:
>
>>> Have a valid backup of the data,
>>> Unmount the filesystem,
>>> Destroy the original disk label
>>> (dd if=/dev/zero of=/dev/rdsk/cxtxdxs2 bs=1 count=1)
>>
>> Interesting. I've run into LUNS from a SAN that when re-used again are detected as the wrong size by solaris. I'm pretty sure I've tried
>> dd-ing over them and just formatted then in the SAN to get the size to be detected correctly again. This seems to happen if a 100GB lun is
>> unified with another for say 200GB.
>
> Which is the procedure above, yes? I don't know what "formated them in
> the SAN" means.

formatted them in the SAN is supposed to the SAN was told to completely erase anything on the LUN.