available space 0, but used is 40 %

[Satya Vedamtam]

hi all,

this the bdf output:
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 47829 16375 0 100% /
/dev/vg00/lvol1 31829 17078 11568 60% /stand
/dev/vg00/lvol7 107501 10106 86644 10% /var
/dev/vg00/lvol6 279189 173051 78219 69% /usr
/dev/vg00/lvol5 145877 12 131277 0% /tmp
/dev/vg00/lvol4 19861 10477 7397 59% /opt


As you can see the root file system %used is 100, but the actual KB used is only around 40 %. I tried fsck / but it bails out with a:

CANNOT READ: BLK 8

Little help please !

Satya

[Jeff Schussele]

Hi Satya,

You've probably got a process that's currently trying to write to something in / & the "used" value won't update 'til it completes.

You need to check what's using the space. If you're already (I hope) logged in do this

du -akx / | sort -nr | more

This will show you the biggest space users up top.
Coluld be as simple as someone backing up to
/dev/rmt/Omn (Note that's an O not a zero)

Rgds,
Jeff

[Helen French]

The 'bdf' will not be accurate in some cases, when some process is still holding the file system space. You will get the correct values with 'du' command:

# cd /
# du -kx (the x will limit the search on root file system only)

You may need to restart/kill that process which holds the file system space or just wait for that process to release the space.

[Michael Tully]

Sounds like someone has deleted a file that is still in memory. There is a tool called 'lsof' which can deal with this:

Here's an example of lsof usage:

To which files are open for a given process id (pid)

# lsof -p

To see all the open files associated with a particular command.

# lsof -c midaemon

User name.

# lsof -u
# lsof -u

processes being used via a socket.

# lsof -i tcp:23
# lsof -i udp:123

Michael

[Robert-Jan Goossens]

Hi,

In case you do not have losf, download it here.

http://hpux.connect.org.uk/hppd/hpux/Sysadmin/lsof-4.64/

Robert-Jan.

[MANOJ SRIVASTAVA]

do fuser -c / to know what si holding the root , if the same is not cleared you may have to bounce the server to get abck to normal.


Manoj Srivastava

[Steven E. Protter]

A common situation when I filled up root was I copied large files unto unmounted directories.

Example

Got a filesystem named /var for whatever reason it didn't mount at boot time.

Then I accidentally or the system started logging lots of stuff to /var Lets say 150 MB worth

I fix the underlying problem, and go mount /var

/var is back up, root is really full and I can't find any extra files.

If you copy files into the directory /var or any other directory and then mount a fs on it, you can no longer see what was there before.

How do you fix it?

You boot into single user mode and poke around without any filesystems mounted.

Boot the box
Interupt the 10 second prompt

bo
hpux -is

after boot, you then start looking around. If you are sure /usr is okay, you can mount /usr and run some of the commands above and find the offending files.

If root is 100% it might not be able to update the counters for the bdf command.

This is serious and your system is in danger of halting.

P

[Bill Hassell]

You don't want to fsck the mounted filesystem. The correct device to use is the disk device file, like /dev/vg00/lvol3. fsck fixes structural problems (missing links between filenames and disk space) but for occupied space, the problem is goofy programs opening temp files and then getting clobbered with a kill -9 or getting hung with a bad LAN connection.

The / directory is never to be used for general purposes, and most likely the problem was created because root's $HOME is / and must be changed to something safer (like /home/root).

The only practical fix here is a reboot which will get rid of the broken program that is using the space and make sure nothing is stored in / that isn't part of HP-UX.