Disk space

[Simon Abbott_1]

Hello,

Silly question, I've had this before but for the life of me I can't remember what the problem is. I have my /var filesystem full. I delete some large files but bdf still shows 100% although du shows 87%. What is it that is still holding on to the space?

Thanks,

Simon.

[Stuart Abramson_2]

The space doesn't really go away if the file is still held open by someone. It might be you. cd / and then check again. I think that "lsof" will tell you who has the file open. Standard HP-UX won't tell you.

[Kent Ostby]

The programs that are running and using those log files are probably still holding the space as temporary files now that the permanent ones are gone.

Stoping and restarting the appropriated programs would probably clean it up .

So if (for instance) you trimmed the syslogd files and that was where the problem was, you'd do:

/sbin/init.d/syslogd stop

wait about 10 seconds then do:

/sbin/init.d/syslogd start

[doug mielke]

I've noticed the same thing. du shows deleted space immediatly, while bdf can take a few minutes. Is bdf an average over time?

[Robert-Jan Goossens]

Hi Simon,

There are some processes keeping /var occupied, best thing is to reboot your server.

You can try using lsof if you can find the process wich keeps /var full, but there are a lot of processes using /var.

Regards,

Robert-Jan.

[Mark Greene_1]

In addition to the log files, another culprit is /var/tmp. If you remove files in this directory, even ones dated prior to the current day, you run the risk of taking out a file that a proces has open. It's always best to run lsof or fuser on files in /var/tmp/ before removing them.

mark

[twang]

bdf will show the filesystem is full even though you just deleted a bunch of files, because there are open process on those files.
du will show the space as clear.

To identify the processes using:
# fuser -cu /var

To kill all open processes on /var:
# fuser -cuk /var

To check the result now:
# bdf
# du -ks /var

[A. Clay Stephenson]

To understand this you reaaly have to look at how the underlying system call unlink() works. This is what is actually invoked via the rm command. Unlink() removes the directory entry and reduces the link count by one. Because the directory entry has been removed, new processes cannot open the file but any processes that currently have the file open are free to use the file. Only when the last process closes the file, is the space occupied by the file released.

Man 2 unlink for details.

[Helen French]

The issue is some old process are still holding the space. This will be released when that process it terminated or stopped. If you want to manually release the space, use fuser or lsof commands to find which process is holding the space and kill it in order.

# man fuser
# man lsof

[Simon Abbott_1]

Hello,

Cheers for the replies, it all makes sense, especially the details of unlink(). A reboot sorted the problem but fuser rings a bell about how we solved the problem before so we should be OK for the future (unless of course I forget again!).

Thanks,

Simon.