Eventually most people run out of space at some time or another. Fortunately GFS provides functionality essentially identical to software raid. For example, your company’s website lives on a 4 node cluster that shares its webroot on GFS. Your website becomes extremely successful and the storage requirements grow dramatically. You check the SAN and find that you have additional resources that you can allocate as a new LUN to the cluster that are available on the same DAE. Ideally, you would recreate the LUN as one allocation, but this would require down time and you can’t afford it at the moment.
Assuming that you are load balancing your webfarm you restart each of the nodes without your customers noticing. This will make the new LUN visible so that you can create a new partition on it. Afterwards you will need to modify the pool configuration to reflect the new subpool.
Pool_tool –p pool_name > pool_name_new.cfg
Vi pool_name_new.cfg

Example output:
#--- begin pool_name --------------------
poolname pool_name
#minor
subpools 2
subpool 0 0 1 gfs_data
subpool 1 0 1 gfs_data
pooldevice 0 0 /dev/emcpowerd2
pooldevice 1 0 /dev/emcpowere1

We can edit the config to include the additional device as follows:

Example output:
#--- begin pool_name --------------------
poolname pool_name
#minor
subpools 3
subpool 0 0 1 gfs_data
subpool 1 0 1 gfs_data
subpool 2 0 1 gfs_data
pooldevice 0 0 /dev/emcpowerd2
pooldevice 1 0 /dev/emcpowere1
pooldevice 2 0 /dev/emcpowerg1

After you have saved the changes you can grow the pool with the following command:
Pool_tool –g pool_name_new.cfg

The last step is to actually tell the GFS partition to grow to take advantage of the new found space. You can test the grow with the T switch:

Gfs_grow –vT /dev/pool/pool_name

Afterwards we can commit the changes:

Gfs_grow –v /dev/pool/pool_name