missing free space after lvreduce

[Babs_1]

Hi me again,
Just trying to free up some space on my hpux 11 system, ran fsadm then lvreduce on an unused lvol and reduced from under 2gb to 4mb. When I tried to allocate the freed space I SAM told me I only had 50 or so Mb free? Where has my space gone???
Any ideas

[Helen French · Accepted solution]

Check the free space available on the VG and LV with:

# vgdisplay -v /dev/vg_name (check free PE)
# lvdisplay -v /dev/vg_name/lv_name (check for LV size)

[Sridhar Bhaskarla]

Hi,

what does 'lvdisplay /dev/vgxx/yourlvol' say?. Does it list as 2gb or 4gb?.

Did you try unmount and mount the filesystem again?. What does 'bdf /your_filesystem' say?

Do a 'vgdisplay vgxx" and note down the 'free PE' and multiply with 'PE size'. That is the space available to you in that vg. If it is not more than 2GB, then your lvreducing process was not successful.

-Sri

[Pete Randall]

Babs,

After yesterday's ordeal, I would suggest that you might want to consider using SAM for these tasks - for your own protection and peace of mind.

Pete

[James R. Ferguson]

Hi Babs:

My first quess, if you did this a commandline, is that you mixed the '-l' or '-L' option's value. '-L' denotes megabytes. '-l' specifies *extents*. In either case the value represents the final size.

Do an 'lvdisplay /dev/vgXX/lvolN' and look at the current size and number of logical extents.

Regards!

...JRF...

[Babs_1]

Hi all,
I allocated soem of the free space I did have as I am under pressure to install something and I only just short a few mb..

vgdisplay tells me I have 2 free PE

lvdisplay tells me that I have a 4mb LV

So I guess it did work?

[Helen French]

1)If vgdisplay shows you have only few PEs left, then you might have to thibk about adding another disk to the VG so that you get more free space.
2) If lvdisplay shows the size is reduced (a few PE), then your lvreduce worked well.
3) Now, you might have already allocated those freed space to somewhere else. Check the sizes of other LVs in that VG and the output of 'bdf'

[Babs_1]

Hi Pete :)
I did the fsadm and lvreduce at the command line and added the space to another lvol in Sam.
Here are the commands I ran
fsadm -b 307200 /u03
then
lvreduce -L 4 /dev/vg00/lvol11

I was able to recreate my lvol and restore all my data from backups after yesterday. All my dbases are running fine so it was not so bad after all.
I am back to my original problem of trying to free space for installing some new software.

[Helen French]

What's the use of a 4MB LV? If you don't use it, then remove that LV. Also, do you have any additional disk? If yes, you can just vgextend the VG and get free space out of it.

Normally, if you have a good backup, I would remove the LV and recreate it with new size instead of doing a lvreduce just to reduce risks. Which file system are you trying to increase? (/var, /opt?)

[Babs_1]

Shiju, I just wanted to keep the mountpoint as it was an unused oracle dbase folder, so I could give back space at a later date if necessary so thats why I kept it :)

I have run bdf and added up all the space that I have allocated to lvols I have 2 18gb scsi disks so I should have 36gb of space....

Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 143360 130035 12544 91% /
/dev/vg00/lvol1 83733 29587 45772 39% /stand
/dev/vg00/lvol8 2129920 901005 1152471 44% /var
/dev/vg00/lvol7 1196032 529801 624621 46% /usr
/dev/vg00/lvol12 71680 1125 66151 2% /u04
/dev/vg00/lvol11 2048 1111 884 56% /u03
/dev/vg00/lvol9 8704000 1401494 6846463 17% /u01
/dev/vg00/lvol4 65536 11548 50660 19% /tmp
/dev/vg00/lvol13 655360 114803 506811 18% /projects
/dev/vg00/lvol6 4096000 1111716 2798213 28% /opt
/dev/vg00/lvol5 512000 26193 455680 5% /home
/dev/vg00/lvol10 13312000 10154800 3058596 77% /u02

When I have added it all up I only have 29.54gb of space?
could I have unallocated space that is unseen as its unmounted etc.?
Yes I know my / is too full :(

[James R. Ferguson]

HI (again) Babs:

There are several things you need to seriously consider. First, buy some more disk and move everything that isn't part of the OS *off* vg00. Your performance will be better and your backup strategies will be simplier. Should you ever need to recreate or clone your server, life will be much easier.

Second, download and install Ignite software. Routinely recreate a recovery tape with 'make_tape_recovery'. Download the software from here.

http://www.software.hp.com/products/IUX/download.html

Installation takes a few minutes and no reboot is required.

Until such time as you segregate your database into a volume group other than vg00, exclude it from your Ignite recovery tape:

# make_tape_recovery -x inc_entire=vg00 -x exclude=/database -I -v -a /dev/rmt/0mn

Third, never panic; work methodically. The fastest way to make a problem worse is to feel that you have to do "something, right now".

Regards!

...JRF...

[Helen French]

First, keeping all your data file systems under vg00 (root VG) is not a good practise! The vgdisplay command should tell you if there is any free PEs available, it cannot hide anything from you.

But a possible chance is some LVs where created, but not mounted by you. If these LVs are there and if you are not using them, then you may remove and allocate those space to the one which you needed. You could check this with 'vgdisplay -v /dev/vg00' or from SAM -> disk and file system. You need to consider removing junk files from your root file system too.

[Pete Randall]

After creating your ignite tape, consider using it to reallocate some of your file systems to get you through until you can acquire more disk space. It appears that /var, /opt, and /home are seriously under-utilized.

Pete

[Babs_1]

I hve found something strange....
When I run vgdisplay my /tmp shows up as 3.5gb when I run bdf /tmp it is showing up as 65536kb
How can this be?

[Pete Randall]

Babs,

Can you show the command you used and it's output, please?

Pete

[Babs_1]

Hi Pete, thanks again for sticking with me :)

Here they are
# bdf
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 143360 130037 12542 91% /
/dev/vg00/lvol1 83733 29587 45772 39% /stand
/dev/vg00/lvol8 2129920 900231 1153191 44% /var
/dev/vg00/lvol7 1196032 529801 624621 46% /usr
/dev/vg00/lvol12 4096 1109 2806 28% /u04
/dev/vg00/lvol11 4096 1111 2804 28% /u03
/dev/vg00/lvol9 8704000 1401622 6846343 17% /u01
/dev/vg00/lvol4 65536 11548 50660 19% /tmp
/dev/vg00/lvol13 733184 114827 579749 17% /projects
/dev/vg00/lvol6 4096000 1111716 2798213 28% /opt
/dev/vg00/lvol5 512000 26193 455680 5% /home
/dev/vg00/lvol10 13312000 10154800 3058596 77% /u02

Output of vgdisplay -v vg00 |more

LV Name /dev/vg00/lvol4
LV Status available/syncd
LV Size (Mbytes) 3500
Current LE 875
Allocated PE 875
Used PV 2

Hope this helps :)

[Michael Duthie]

Babs,

Your system needs a bit of work, I would seriously consider getting some down time, using IUX to image the whole system to tape and then rebuild. /home, /var & /usr have plenty of space but / is starting to struggle. You should also move all your non root filesystems to VG01.

[Helen French]

What about the lvdisplay? Check the lvdisplay output of /home and see how much space it holds:

# lvdisplay -v /dev/vg00/lvol5

[Pete Randall]

Babs,

The vgdisplay output got truncated. I need to see the section for lvol4. Or a lvdisplay /dev/vg00/lvol4 would do.

Pete

[Babs_1]

Hi Mike,
I know, I have been learning as I go with this system, which started of as a dev/test system and has now sneakily grown into a production server. If I can get past this point rebuild is the next thing on my to do list :)

[Michael Duthie]

Babs,

Looks like /tmp has been lvextend'ed but not extendfs'ed.

Mike

[Pete Randall]

Sorry, I read that wrong, you gave us exactly what we needed. I think Mike has the answer - lvextend with no fsextend.

Pete

[Babs_1]

Here you go Pete :)

# lvdisplay /dev/vg00/lvol4
--- Logical volumes ---
LV Name /dev/vg00/lvol4
VG Name /dev/vg00
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 3500
Current LE 875
Allocated PE 875
Stripes 0
Stripe Size (Kbytes) 0
Bad block on
Allocation strict
IO Timeout (Seconds) default

Hi Mike, do you reckon if I extendfs for /tmp I can get my space?

[Michael Duthie]

Jeasus, this is a fast moving post, the guys smell woman in the air :-)

Babs, thrown in the deep end is the best way to learn, as long as you have a good backup!

I am sure HP in Dublin will be only too willing to help.

[Pete Randall]

Babs,

I would think, since you're after more space and /tmp is only 19% full, you would rather do a lvreduce on lvol4 than do an extendfs - that would expand the /tmp file system and I don't think that's where you need the space.

Pete