PowerPath: How to expand a Linux file system even though there is no partition table on a PowerPath LUN

The customer was trying to expand two in native Linux LVM file system SAN LUNS that is mapped in native Linux LVM and it failed.

A VNX5500 serving multiple LUNs over PowerPath 5.3 SP 1 (build 111) to RHEL5 and RHEL6 servers, running Linux 2.6.18-128.el5

Customer had already expanded the user capacity for these two LUNS on the VNX.
The previous capacity was 82 GB and 60 GB and it was expanded to 136 GB and 90 GB, respectively.

The procedure the customer was following:

1. lvdisplay -v /dev/[volgroup]/[logicalvolume] - to identify physical device
2. fdisk -l /dev/[device] - to verify partition table
3. df -h /[mountpoint] - to verify existing capacity
4. grep mpt /sys/class/scsi_host/host?/proc_name - to identify scsi bus to rescan
5. echo "- - -" > /sys/class/scsi_host/hostX/scan - to rescan device 'hostX'
6. pvs /dev/[device] - to check physical volume size
7. pvresize /dev/[device] - to grow the physical volume to the new LUN size
8. pvs /dev/[device] - to check new physical volume size
9. vgscan - to rebuild volume group caches
10. vgs [volgroup] - to verify volume group information
11. lvextend -l +100%FREE /dev/[volgroup]/[logicalvolume] - to extend the logical volume to fill the disk
12. resize2fs /dev/[volgroup]/[logicalvolume] - to resize the file system on the logical volume
13. df -h /[mountpoint] - to verify new capacity

The PowerPath mounted LUNs do not seem to have a valid partition table:

fdisk -l /dev/emcpowercb

Disk /dev/emcpowercb: 91.2 GB, 91268055040 bytes
255 heads, 63 sectors/track, 11096 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/emcpowercb doesn't contain a valid partition table

The first 512 bytes of /dev/emcpowercb are as follows:

 hexdump -Cn512 /dev/emcpowercb
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200

Yet, the LUNs are mounted, and are accessible to the system (for example):

 df -h /DCCDBUNIX/data01
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg2dccdbnx2pd01-lvdccdbnxd01
84G 67G 13G 84% /DCCDBUNIX/data01

The above example is for the following PowerPath mapped LUN:

 vgdisplay -v vg2dccdbnx2pd01
Using volume group(s) on command line
Finding volume group "vg2dccdbnx2pd01"
--- Volume group ---
VG Name vg2dccdbnx2pd01

--- Logical volume ---
LV Name /dev/vg2dccdbnx2pd01/lvdccdbnxd01
VG Name vg2dccdbnx2pd01
LV Size 85.00 GB
Block device 253:9

--- Physical volumes ---
PV Name /dev/emcpowercb
Total PE / Free PE 21759 / 0

Trying to expand the Linux file system even though there is no partition table on the PowerPath LUN?

Per Red Hat, using the command to reveal the physical volume is correct.

pvs -o+pv_used /dev/[pseudo_device]

Then when adding a disk to a system and extending the volume group in a stripe over the added disk.

To show the unused raw disk space when the original LUN was expanded.

pvs -av /dev/[pseudo_device]

In addition to scan the device from the host the blockdev commands for all the PowerPath native devices WORKED as designed.
:

blockdev --rereadpt /dev/sds
blockdev --rereadpt /dev/sdbr
blockdev --rereadpt /dev/sddq

The command down below echoing the wildcards to /sys/class/scsi_host/hostX/scan so that using the host to rescan the entire HBA to refresh the LUN device DID NOT WORK.

echo "1" >/sys/block/sds/device/rescan
echo "1" >/sys/block/sdbr/device/rescan
echo "1" >/sys/block/sddq/device/rescan

Then expanding the LUN in Unisphere as a last step, have to be in root for it to work.

# powermt display dev=emcpowerai
Pseudo name=emcpowerai
VNX ID=APMXXXXXXXXXXX [xxxxx]
Logical device ID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [xxxxx_dccdbnx2i02_RV]
state=alive; policy=CLAROpt; queued-IOs=0
Owner: default=SP A, current=SP A Array failover mode: 4
==============================================================================
--------------- Host --------------- - Stor - -- I/O Path -- -- Stats ---
### HW Path I/O Paths Interf. Mode State Q-IOs Errors
==============================================================================
3 lpfc sds SP A5 active alive 0 0
3 lpfc sdbr SP B5 active alive 0 0
4 lpfc sddq SP A4 active alive 0 0


 pvs -o+pv_used,dev_size |grep /dev/emcpowerai
/dev/emcpowerai vg2dccdbnx2qi01 lvm2 a-- 60.00G 0 60.00G 60.00G

 umount /DCCDBUNIX/index01

 blockdev --rereadpt /dev/sds
 blockdev --rereadpt /dev/sdbr
 blockdev --rereadpt /dev/sddq

 pvs -o+pv_used,dev_size |grep /dev/emcpowerai
/dev/emcpowerai vg2dccdbnx2qi01 lvm2 a-- 60.00G 0 60.00G 92.00G

 pvresize /dev/emcpowerai
Physical volume "/dev/emcpowerai" changed
1 physical volume(s) resized / 0 physical volume(s) not resized

 pvs -o+pv_used,dev_size |grep /dev/emcpowerai
/dev/emcpowerai vg2dccdbnx2qi01 lvm2 a-- 92.00G 32.00G 60.00G 92.00G

 pvscan |grep '/dev/emcpowerai'
PV /dev/emcpowerai VG vg2dccdbnx2qi01 lvm2 [92.00 GB / 32.00 GB free]

 vgscan |grep 'vg2dccdbnx2qi01'
Found volume group "vg2dccdbnx2qi01" using metadata type lvm2

 vgs |grep vg2dccdbnx2qi01
vg2dccdbnx2qi01 1 1 0 wz--n- 92.00G 32.00G

 lvextend -l +100%FREE /dev/vg2dccdbnx2qi01/lvdccdbnxi01

 lvextend -l +100%FREE /dev/vg2dccdbnx2qi01/lvdccdbnxi01
Extending logical volume lvdccdbnxi01 to 92.00 GB
Logical volume lvdccdbnxi01 successfully resized

 resize2fs /dev/vg2dccdbnx2qi01/lvdccdbnxi01
resize2fs 1.39 (29-May-2006)
Please run 'e2fsck -f /dev/vg2dccdbnx2qi01/lvdccdbnxi01' first.

e2fsck -f /dev/vg2dccdbnx2qi01/lvdccdbnxi01
e2fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/vg2dccdbnx2qi01/lvdccdbnxi01: 43/7864320 files (16.3% non-contiguous), 12034277/15727616 blocks

 resize2fs /dev/vg2dccdbnx2qi01/lvdccdbnxi01
resize2fs 1.39 (29-May-2006)
Resizing the filesystem on /dev/vg2dccdbnx2qi01/lvdccdbnxi01 to 24116224 (4k) blocks.
The filesystem on /dev/vg2dccdbnx2qi01/lvdccdbnxi01 is now 24116224 blocks long.

 mount /DCCDBUNIX/index01

 df -h
/dev/mapper/vg2dccdbnx2qi01-lvdccdbnxi01
91G 45G 41G 53% /DCCDBUNIX/index01

Another option is to reboot, which also works, since it creates a full rescan.