Disk Space Query

[Gary March]

Below is bdf -i for whole system

cheers



/>#bdf -i
Filesystem kbytes used avail %used iused ifree %iuse Mounted on
/dev/vg00/lvol3 212992 147088 65416 69% 6844 2052 77% /
/dev/vg00/lvol1 298928 57024 212008 21% 80 32688 0% /stand
/dev/vg01/work 31440896 24261360 7067868 77% 176908 448708 28% /work
/dev/vg01/wrms 10485760 9448052 1006050 90% 171773 129707 57% /wrms
/dev/vg01/w 2621440 2473674 147766 94% 103375 608305 15% /w
/dev/vg00/lvol8 4718592 3386976 1327928 72% 22865 41583 35% /var
/dev/vg00/lvol7 2015232 1164584 844064 58% 31029 26571 54% /usr
/dev/vg00/lvol4 1032192 279048 747944 27% 3468 23508 13% /tmp
/dev/vg00/lvol6 2211840 1951624 258488 88% 37499 8101 82% /opt
/dev/vg01/nib 524288 1229 490375 0% 5 130763 0% /nib
/dev/vg01/home 1048576 649087 374558 63% 13007 99869 12% /home
/dev/vg01/data 2097152 1748883 326534 84% 72833 87067 46% /data
/dev/vg01/apps 2097152 1350727 699982 66% 11966 186606 6% /apps

[Senthil Kumar .A_1]

Hi Gary,

As of from you "bdf -i" output, I do not see any hidden files due to mounting. Please do refer the following thread, it might shed some light on the issue you have...

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=989077

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=992662

Also my suggestion , can u check the same after unmount the File system ,perform fsck and remount during your change window.

Regards,
Senthil Kumar .A

[Carl Munnelly]

Has anyone removed any files from /w.

If files where being used by a process (ie application logfile) and was removed without stopping application then although file removed the inode will not be release and therefore will still be allocation the file size in space even though no file listed.

If this is the case then recycle application and this will free up inode (therefore the space)

[Carl Munnelly]

Has anyone removed any files from /w.

If files where being used by a process (ie application logfile) and this file was removed without stopping the application then although the file would be removed the inode will not be released and therefore neither would allocation space for the file, so the file size in space is still reserved even though the file isn't listed.

If this is the case then recycle the application (or umount filesystem and remount) and this will free up inode (therefore the space)

[Carl Munnelly]

sorry for duplication IE told me site unavailable so refreshed and resubmitted. Only noticed upon checking

[Antonio Cardoso_1]

Hi Gary,

to find which process is holding a deleted file, you can try using lsof.
For example:
# lsof /fs1
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sh 5333 root cwd DIR 64,0xe 1024 2 /fs1
cat 20195 root 1u REG 64,0xe 68 10 /fs1 (/dev/vg00/lvol14)

=> I think you will get the mention of logical volume only in line of process with orphaned inode.

If not yet installed, you can get lsof from http://hpux.connect.org.uk/hppd/cgi-bin/search?package=&term=/lsof

[LoC_1]

"du" shows output in a positive view: it shows the number of currently allocated
blocks and counts the blocks you've just deleted as free.
"bdf" has a more negative perspective: it shows the free disk space available.

The difference is here: if a still-active process has allocated blocks (such as
for a logfile that you've just deleted), "bdf" counts these as still occupied.
This won't change until the process closes the file ("deallocates the blocks")
as it usually happens when the process terminates.


I would umount the file system and run a full fsck to see if you can clean it.

[Gary March]

I ran lsof on the file system and found a process consuming 1.7 GB. This process had been running for quite some time. When I stopped and restarted the process this space was freed up.

We do not normally reboot this server but it was restarted after a couple of power failures. After these restarts the size of the file system was not reduced at all. I do not understand why. (?) As a precaution, I am going to use cron to stop and start the troublesome process on a regular basis.

I found the support and contributions from everybody to be excellent (thanks very much). I also found the lsof tool to be extremely useful in identifying the problem process.