From: Mark on 9 Dec 2008 15:44 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 9 Dec 2008 16:42 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 10 Dec 2008 00:07 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 10 Dec 2008 13:38 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 11 Dec 2008 04:52 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.
|
Next
|
Last
Pages: 1 2 Prev: Changing HostID of a Solaris 10 Zone Next: ddi_remove_minor_node not working |