How to Shrink a VG 11.31 using fsadm

[chindi]

We have a vg 0f 800 GB , rx2800i4 11iv3 .

Break up is as follows;

Three luns of size 600,100,100 .

Now we would like to shrink a vg to 600GB only .

We do have Onlinejfs , kindly let us know how do we go ahead ?

Can we do it online ?

[Bill Hassell]

It is not clear what you want to accomplish. A VG is just a collection of LUNs that may have some logical volumes (lvols) defined. You have to decide what to do with the lvols. If there are no lvols defined, just use vgreduce to remove the 2ea 100GB LUNs. But if there are lvols, they must be reduced or removed. lvols might be swap areas, raw database volumes or filesystems. Since you did not document the distribution and usage of any lvols, your question is incomplete.

Please run the following commands (where: <your_VGname> is the VG you want to reduce:

# vgdisplay -v <your_VGname>
# bdf -l | grep <your_VGname>
# for LV in $(vgdisplay -v | awk '/LV Name/{print $NF}')
   do
   lvdisplay -v $LV | awk '/LV Name/{print $NF}' | head -40
   done

[Patrick Wallek]

You don't shrink a volume group (VG) with fsadm.  fsadm is used to expand / shring file systems.

If your goal is to get rid of the 2 x 100GB LUNs then you will first need to determine if anything is using those LUNs.

You can do that with the commands that Bill mentioned above.

Once we have that information it will be easier to determine if you actually need to use fsadm or not.

[chindi]

Hi ,

Sorry for the incomplete info.

root #/ >vgdisplay -v /dev/vg_pugb24_hr_day_new
--- Volume groups ---
VG Name /dev/vg_pugb24_hr_day_new
VG Write Access read/write
VG Status available, exclusive
Max LV 255
Cur LV 1
Open LV 1
Max PV 16
Cur PV 2
Act PV 2
Max PE per PV 60000
VGDA 4
PE Size (Mbytes) 128
Total PE 6398
Alloc PE 6398
Free PE 0
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0
VG Version 1.0
VG Max Size 120000g
VG Max Extents 960000

--- Logical volumes ---
LV Name /dev/vg_pugb24_hr_day_new/lvol1
LV Status available/syncd
LV Size (Mbytes) 818944
Current LE 6398
Allocated PE 6398
Used PV 2

--- Physical volumes ---
PV Name /dev/disk/disk554
PV Status available
Total PE 3199
Free PE 0
Autoswitch On
Proactive Polling On

PV Name /dev/disk/disk557
PV Status available
Total PE 3199
Free PE 0
Autoswitch On
Proactive Polling On

root #/ >bdf -l | grep vg_pugb24_hr_day_new
/dev/vg_pugb24_hr_day_new/lvol1

root #/ >lvdisplay -v /dev/vg_pugb24_hr_day_new/lvol1|head -40
--- Logical volumes ---
LV Name /dev/vg_pugb24_hr_day_new/lvol1
VG Name /dev/vg_pugb24_hr_day_new
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 818944
Current LE 6398
Allocated PE 6398
Stripes 0
Stripe Size (Kbytes) 0
Bad block on
Allocation strict
IO Timeout (Seconds) default

--- Distribution of logical volume ---
PV Name LE on PV PE on PV
/dev/disk/disk554 3199 3199
/dev/disk/disk557 3199 3199

--- Logical extents ---
LE PV1 PE1 Status 1
00000 /dev/disk/disk554 00000 current
00001 /dev/disk/disk554 00001 current
00002 /dev/disk/disk554 00002 current
00003 /dev/disk/disk554 00003 current
00004 /dev/disk/disk554 00004 current
00005 /dev/disk/disk554 00005 current
00006 /dev/disk/disk554 00006 current

[Patrick Wallek]

This volume group is currently made up of only 2 disks / LUNs (disk554 and disk557).  You mentioned a 600 GB LUN and 2 x 100 GB LUNs originally -- that is NOT the case in this VG.

Each disk is 409,472 MB in size (3,199 PE per disk x 128 MB PE size).

There are currently NO extents free on either disk as the LV is using all available space (818, 944 MB or 799 GB).

The only way to shrink this VG would be to reduce the filesystem and the LV to 409,472 MB or less via fsadm and lvreduce.  However, if  the data in this LV is occupying more than 50% of the space you will NOT be able to reduce it.

[chindi]

Hi Patrick ,

You are right.

We can consider this vg only , which is made up of 2 luns each of 400GB . Total 800GB .

If we reduce data of say 200GB , how can we accomodate the same in 600GB online.

Do we have any offline options.

Basically we dont want to create new filesystem and then take downtime to restore backed up data .

[Patrick Wallek]

To shrink a logical volume, there are 2 major steps.  First you shrink the file system, and then you shring the logical volume.

Your 'bdf' command was cut off (due to the long LV name, the output was split between 2 lines so we did not see the usage or the mount point) so I will assume a mount point of /mnt.

In your case, if you want to shrink down to 600GB, then you would have to do the following:

# fsadm -b 600000m /mnt

This will likely take a while since you are shrinking the file system by a large amount.

If that is successful then you shrink the LV:

# lvreduce -L 600000 /dev/vg_pugb24_hr_day_new/lvol1

Now the LV is 600GB and you should be able to do what you need.

[chindi]

Hi Patrick ,

Filesystem kbytes used avail %used Mounted on
/dev/vg_pugb24_hr_day_new/lvol1
838598656 752111887 81102178 90% /oradata_p012band

Say my used space comes down to 550GB , then i hve to do the following right ?;

1 fsadm -b 600000m /mnt

2 lvreduce -L 600000 /dev/vg_pugb24_hr_day_new/lvol1

[Patrick Wallek · Accepted solution]

According to the 'bdf' output, you are using about 750GB out of the 800 GB in the LV.  There's going to be no way to shrink this down to 600 GB without (re)moving data to get your space used so it is less than 600 GB.

If the mount point you are talking about is different from this one, and you are just using 550 GB out of 800 GB, then yes you may be able to shrink it.

The commands should work.  Just make sure you replace the '/mnt' in the fsadm command with the correct mount point for the file system.