File system used and available space descrepancy

[Tom Wolf_3]

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
VGDA 2
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
vxfs
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

[Matti_Kurkela]

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:
1.)
If that particular process can accept commands to stop using that particular file and close it, you can use that.

2.)
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.

3.)
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.

MK

[Dennis Handly]

>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]

>MK: This can happen if someone has deleted some files while they're still open and in use by another process.

Are you sure about this? Tom is talking about a discrepancy in the df output, not comparing df and du which is the deleted files.

Some threads about both issues:
http://h30499.www3.hp.com/t5/LVM-and-VxVM/file-system-full-discrepancy-bdf-vs-fstyp-vs-syslog/m-p/3788235#M27241

http://h30499.www3.hp.com/t5/System-Administration/Difference-in-df-and-du-output/m-p/4037730#M302319

http://h30499.www3.hp.com/t5/System-Administration/Discrepancy-value-of-disk-space-between-du-and-bdf-of-file/m-p/5100987#M444193

http://h30499.www3.hp.com/t5/System-Administration/bdf-and-du-shows-different-values/m-p/4644174#M379692

http://h30499.www3.hp.com/t5/System-Administration/Filesystem-show-66-used-while-it-is-free/m-p/4218366#M327077

http://h30499.www3.hp.com/t5/System-Administration/bdf-and-df-outputs/m-p/2990777#M124286

http://h30499.www3.hp.com/t5/System-Administration/Filesystem-free-space-is-not-releasing-completly/m-p/4768347#M389660

http://h30499.www3.hp.com/t5/System-Administration/var-displaying-incorrect-disk-usage/m-p/2927728#M110933

[V.P]

Hi,

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]

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]

Shalom,

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.

SEP

[Tuan Nguyen_2 · Accepted solution]

The explanation can be found at:

http://h30499.www3.hp.com/t5/LVM-and-VxVM/hpux-shows-bdf-wrongly/m-p/4795727#M39255