Hi! > > Several of our RedHat 5.2 servers have LUN's presented from HP-EVA > 8000 > > SAN's, configured with multipath. Multipath does not detect a resized > LUN > > until after a reboot. I've found this thread which 'blames' the block > > layer: > > > > http://www.linux-archive.org/device-mapper-development/138757-status- > resizing-growing-dm-multipath-devices-fly.html > > > > Looking at the 5.3beta release nodes, I can't find any info regarding > > on-line resizing multipath devices. Am I overlooking a note or is > RedHat > > scheduling this for an other release? > > > > Hi! > > I did successful online resizes using iSCSI storage: > http://pasik.reaktio.net/rhel5-online-iscsi-resize-test.txt > > Both the kernel SCSI resize patch, and the dm-multipath online resize > support were both targeted for RHEL 5.3.. at least initially. I don't > know > about the current status.
Just tested on a RHEL 5.3 server and resizing now works on-line :
- Red Hat Enterprise Linux Server release 5.3 (Tikanga)
- kernel 2.6.18-128.el5
- device-mapper-multipath 0.4.7-23.el5
- 2 Qlogic HBA's and 4 paths
- 115GB ext3 file system , LVM PV/VG on top of mpath device
]# multipath -ll san4_Data
san4_Data (3600508b4001078340000d00004d80000) dm-10 HP,HSV210
[size=115G][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=100][active]
\_ 0:0:3:2 sdg 8:96 [active][ready]
\_ 1:0:3:2 sdq 65:0 [active][ready]
\_ round-robin 0 [prio=20][enabled]
\_ 0:0:2:2 sdb 8:16 [active][ready]
\_ 1:0:2:2 sdl 8:176 [active][ready]
- get the new size, issue a rescan per device
]# for varTmp in `multipath -ll san4_Data | grep sd | awk '{print $2}'`; do
echo 1 > /sys/class/scsi_device/$varTmp/device/rescan ;done ; unset varTmp
Or use blockdev per device (is there a preferred method?)
]# for varTmp in `multipath -ll san4_Data | grep sd | awk '{print $3}'`; do
blockdev --rereadpt /dev/$varTmp ;done ; unset varTmp
]# multipathd -k"resize multipath san4_Data"
ok
]# multipath -ll san4_Data
san4_Data (3600508b4001078340000d00004d80000) dm-10 HP,HSV210
[size=120G][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=100][enabled]
\_ 0:0:3:2 sdg 8:96 [active][ready]
\_ 1:0:3:2 sdq 65:0 [active][ready]
\_ round-robin 0 [prio=20][enabled]
\_ 0:0:2:2 sdb 8:16 [active][ready]
\_ 1:0:2:2 sdl 8:176 [active][ready]
]# pvresize /dev/mapper/san4_Data
Physical volume "/dev/dm-10" changed
1 physical volume(s) resized / 0 physical volume(s) not resized
]# lvresize /dev/vg_san4_Data/lv_san4_Data -l +100%FREE
Extending logical volume lv_san4_Data to 120.00 GB
Logical volume lv_san4_Data successfully resized
]# resize2fs /dev/vg_san4_Data/lv_san4_Data
resize2fs 1.39 (29-May-2006)
Filesystem at /dev/vg_san4_Data/lv_san4_Data is mounted on /san4; on-line
resizing required
Does this make sense? Did not test it on a running Oracle server which
normally has it's databases active on this resized file system, but do you
think this procedure is safe (no file corruption or other culprits to
expect)?
Cheers,
Andre
> -- Pasi
>
>
> _______________________________________________
> rhelv5-list mailing list
> rhelv5-list@redhat.com
> https://www.redhat.com/mailman/listinfo/rhelv5-list
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
