Lost disk space.

[Phil Davey]

I have just created a new volume group and vxfs filesystem on a HP-UX 11.11 box, and appear to have lost a significant amount of space.
Lv created as 600000MB and newfs'd
df- k only shows 576010448 total allocated, but in a similar LV on a different server (only difference is the PE size) I get 613836952 total allocated. I have tried rebuilding the VG and LV several times with different settings, including changes to the PE size) but I still get the same results.

I have included output from the server below which might help diagnosis.

--- Logical volumes ---
LV Name /dev/vg01/lvol1
VG Name /dev/vg01
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 600000
Current LE 18750
Allocated PE 18750
Stripes 0
Stripe Size (Kbytes) 0
Bad block NONE
Allocation strict
IO Timeout (Seconds) default

df -k shows
/apps/CRM2ITPS (/dev/vg01/lvol1 ) :
576010448 total allocated Kb
575843398 free allocated Kb
167050 used allocated Kb
0 % allocation used

fstyp -v /dev/vg01/lvol1
vxfs
version: 4
f_bsize: 8192
f_frsize: 1024
f_blocks: 614400000
f_bfree: 614232950
f_bavail: 575843391
f_files: 153558268
f_ffree: 153558236
f_favail: 153558236
f_fsid: 1073872897
f_basetype: vxfs
f_namemax: 254
f_magic: a501fcf5
f_featurebits: 0
f_flag: 16
f_fsindex: 7
f_size: 614400000

[Peter Godron]

Phil,
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 */"

[Phil Davey]

Peter,
Thanks for the response, but I think I may have worded the problem wrong. The problem lies with the fact I have created a 600000MB filesystem, but I only have 575843MB available to use. On other servers, I do not lose nearly 40GB in a filesystem of this size.

[Steve Lewis]

Did you use sam to create the filesystem in one case and newfs in another? Or did you use mkfs -F vxfs -o logsize=2048 ...
Are they both vxfs, or is the other one an hfs type filesystem with no rollback log?

The log size could explain the difference.

In a vxfs filesystem of that size, a 16Mb log is actually quite sensible, so I would use mkfs...-o logsize=[maximum available]
anyway.

Steve

[Phil Davey]

Both were created on the command line using lvcreate -r N -L 600000 ...
newfs -o largefiles

Thee only significant difference in the VG is the PE size, although even with the same PE size I get the same problem.

Both are vxfs.

[Hein van den Heuvel]

I think you need to show use the lvdisplay for the other system as well such that we can more easily compare.

Attached them in a .txt file ?
Use the same PE size as the other system?
Toss in a vgdisplay for good measure?

Same hpux version?

The difference between bfree and bavail appears to be exactly files * 256 bytes.
So 256 bytes per inode.
So it corresponds to the number of inodes the vxfs ESTIMATES to need for the device.

Did it know more, was it told more, on the other system>

hth,
Hein.

[Phil Davey]

I think I have found what the discrepancy was. I am almost certain the missing space was the journal, which, because the filesystem had never been used, was empty. As soon as the filesystem starts to be used, the discrepancy between used+avail and allocated narrows right down.

I suspect it happens on all filesystems, but was never noticed until now due to the size of this particular filesystem.

[Hein van den Heuvel]

>> I think I have found what the discrepancy was. I am almost certain the missing space was the journal, which, because the filesystem had never been used, was empty.

I beg to differ.
The 'missing space' was too big for a journal. That is just 1024 block by default.

The missing space EXACTLY fits 'number-of-files-expected times vxfs inode size (256)'

Only one explanation can be valid at a time.

See: http://docs.hp.com/en/B3929-90011/ch02.html

>> As soon as the filesystem starts to be used, the discrepancy between used+avail and allocated narrows right down.

That I agree with. It now knows better what to expect as far as file sizes go. Apparently it assumes worst case: 1 extent per file to begin with.

>> I suspect it happens on all filesystems, but was never noticed until now due to the size of this particular filesystem

Agreed.

Regards,
Hein van den Heuvel