file system full discrepancy - bdf vs fstyp vs syslog

[Robert_Jewell]

Good day to all! It has been a long time since my last post, but I am sure that the wealth of knowledge here has not diminished.

Anyway, my question today is one regarding file system full messages I am receiving in syslog. This occurs when writing files under /var (which are written sucessfully by the way). A bdf output shows a good amount of space left however. Another thing noted as strange is the f_bfree value compared to f_bavail from the fstyp command.

Some supporting data:

HP-UX version is 10.20 w/ Dec 2000 patch bundle and /var is vxfs.

Filesystem options used:
ninode=unlimited,bsize=1024,version=3,inosize=256,logsize=1024,nolargefiles

bdf output:
Filesystem kbytes used avail %used Mounted on

/dev/vg00/lvol3 86016 62164 22398 74% /
/dev/vg00/lvol1 47829 18118 24928 42% /stand
/dev/vg00/lvol8 819200 744100 72283 91% /var
/dev/vg00/lvol7 819200 551591 250976 69% /usr
/dev/vg00/lvol4 409600 220966 177402 55% /tmp
/dev/vg00/lvol6 1024000 853356 165451 84% /opt
/dev/vg00/lvol5 151552 95362 52707 64% /home

df -k
/var (/dev/vg00/lvol8 ) : 816383 total allocated Kb
72283 free allocated Kb
744100 used allocated Kb
91 % allocation used
lvdisplay for lvol8:
LV Name /dev/vg00/lvol8
LV Status available/syncd
LV Size (Mbytes) 800
Current LE 200
Allocated PE 400
Used PV 2

fstyp -v /dev/vg00/lvol8
vxfs
version: 3
f_bsize: 1024
f_frsize: 1024
f_blocks: 819200
f_bfree: 75072
f_bavail: 0
f_files: 19200
f_ffree: 1073771904
f_favail: 1073771904
f_fsid: 1073741832
f_basetype: vxfs
f_namemax: 254
f_magic: a501fcf5
f_featurebits: 0
f_flag: 0
f_fsindex: 7
f_size: 819200

As you see, the bavail value now is 0, so I suspect that is the reason for the file system full messages. But since bfree is over 75000 I have bdf stating there is space left and since I am writing file sucessfully that value must be correct???

Has anyone seen/heard of such a discrepancy between these two values? Any chance of recovery or correction?

Thanks as usual in advance,

-Bob

[Peter Godron]

Bob,
bdf is not always absolutely to be trusted.

http://forums1.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=1026611
and the reverse to your problem:
http://forums1.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=1016850

[Robert_Jewell]

True, I understand that. However, the difference is over 70 MB. not much in comparision these days, but its still a significant amount of space. Its really the difference is free blocks vs available blocks that is strange. On most occasions these values are closer in numbers and sometimes are the same.

-Bob

[Ninad_1 · Accepted solution]

Hi,

Does du -sk /var also report same as bdf ?
Usually I have seen decrepancies from output of du and bdf and the reason is some open file due to a process which was killed/terminated without releasing/closing the file.
You can check from lsof for open files in /var.
The other thing about f_bfree and f_bavail - I guess a normal user cannot write if b_avail is 0 but root can still write to the filesystem - but i am not 100% sure on this.

Regards,
Ninad

[Peter Godron]

Bob,
the difference between the two values is the amount of data that can be written by root, even if the filesystem is full to normal users.
man statvfs
"ulong f_bfree; /* free blocks*/
ulong f_bavail; /* blocks available to non-superuser */"

So it appears to be a safety, allowing vital root processes to continue.

[Robert_Jewell]

I would guess that the reason for some file systems having these the at the same value would be because those mount points wouldnt normally have user access (like /var/tmp) or have a negative affect on the system in the event that it runs out of space.

Thanks for the info and tips.

-Bob

[Mike Myers_5]

I think the missing space can be accounted for by the VxFS intent log. I don't believe the Veritas File system does the "10%" reserve that UFS used to do (still does?). UFS did this because the allocation strategy it used hit a serious bend in the efficiency curve at 90% full.