LVM and VxVM

Re: File system used and available space descrepancy

Go to solution
Tom Wolf_3
Valued Contributor

File system used and available space descrepancy

Hello all.
I created a 150 GB VxFS file system on our HP-UX 11.31 ia64 server.
I'm noticing a 10 GB descrepancy between the size of the file system, the used space, and the available space.
The df output below shows this descrepancy.
Does anyone have any idea why this is occurring?
Below I also listed the vgdisplay output for this volume group and fstyp output for the logical volume.
Any feedback would be appreciated.

Thanks everyone.

Filesystem Size Used Avail Capacity Mounted on
/dev/vgupgrade/lvupgrade 150G 103M 140G 0% /ora_dbutil/125upd

# vgdisplay -v /dev/vgupgrade
--- Volume groups ---
VG Name /dev/vgupgrade
VG Write Access read/write
VG Status available
Max LV 511
Cur LV 1
Open LV 1
Max PV 511
Cur PV 1
Act PV 1
Max PE per PV 524288
PE Size (Mbytes) 32
Total PE 9433
Alloc PE 4800
Free PE 4633
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0
VG Version 2.0
VG Max Size 1p
VG Max Extents 33554432

--- Logical volumes ---
LV Name /dev/vgupgrade/lvupgrade
LV Status available/syncd
LV Size (Mbytes) 153600
Current LE 4800
Allocated PE 4800
Used PV 1

--- Physical volumes ---
PV Name /dev/disk/disk13
PV Status available
Total PE 9433
Free PE 4633
Autoswitch On
Proactive Polling On

# fstyp -v /dev/vgupgrade/lvupgrade
version: 7
f_bsize: 8192
f_frsize: 1024
f_blocks: 157286400
f_bfree: 157181205
f_bavail: 147357380
f_files: 39295332
f_ffree: 39295300
f_favail: 39295300
f_fsid: 2147557377
f_basetype: vxfs
f_namemax: 254
f_magic: a501fcf5
f_featurebits: 0
f_flag: 16
f_fsindex: 9
f_size: 157286400

Honored Contributor

Re: File system used and available space descrepancy

This can happen if someone has deleted some files while they're still open and in use by another process. Any Unix sysadmin worth his/her salt should learn to understand this, as this behaviour is a necessary result of POSIX standard filesystem semantics.

Normally, any Unix-like operating system deals with this situation as follows: the file vanishes from the directory listings immediately, so it will not be accessible any more. But the data will not really be deleted until the file is closed: the process(es) that had the file open at the time of deletion can still access the file as usual while it's still open. When the file is closed, the disk space allocated to it will be freed.

If you have the freeware tool "lsof" installed, you can see if this is happening by using a command like:

lsof +aL1 /ora_dbutil/125upd

If the filesystem contains deleted-but-still-open files, this command will display the PIDs of the processes holding those files open. It may also be able to tell the original names of those deleted files (because the directory entries are already deleted, the filename will not be detectable in the normal fashion).

Ways to go on from here:
If that particular process can accept commands to stop using that particular file and close it, you can use that.

If there is no known way to send such commands to that process, killing & restarting the process will force it to close all its files.

Rebooting the system is an overkill, but it works too: as all the running processes are shut down, any files held open by them are automatically closed.

Dennis Handly
Acclaimed Contributor

Re: File system used and available space descrepancy

>MK: the freeware tool "lsof" installed

Ideally a superior kernel would have this builtin and not have to search every process to produce this info.
Dennis Handly
Acclaimed Contributor
Frequent Advisor

Re: File system used and available space descrepancy


Create the LV using the block size of 8192KB. By default it will be 1024.
# newfs -F vxfs -b 8192 -o largefiles RAW_LV_NAME.
Tom Wolf_3
Valued Contributor

Re: File system used and available space descrepancy

Thanks for the responses.
I noticed this descrepancy right after I created the file system so deletion of open files is definetly not the source. We had to use a block size of 1 KB to accomadate our vendor's request. This file system is going to be used for Oracle logging. Would the 1024 block size cause this descrepancy?
Steven E. Protter
Exalted Contributor

Re: File system used and available space descrepancy


No, the discrepancy is caused by one of a few causes.

1) A file handle being open on a file that was recently deleted. fuser -cu /filesystem to see if this is the case. lsof might be of some assistance as well.

2) A failed fsadm command to expand the the file system. The process of expanding an existing file system involves more than one step. lvextend then either fsadm for Online JFS users or extendfs which requires a umount prior to being run.


Steven E Protter
Owner of ISN Corporation
Tuan Nguyen_2
Frequent Advisor

Re: File system used and available space descrepancy