BDF and filesystem info.

[Richard Pereira_1]

Hi,

Heres a classic problem but maybe a new solution has been found.

My /var filesystem blew up to 94% full due to a at job going astray. I have deleted the offending file but bdf shows no difference. However, the du command does , I would need to resolve bdf in order to calm my users.

In an attempt to fix this, I have moved and rebuilt /etc/mnttab, no changes. The problem file was deleted, so im assuming there are no remanant processes.

I know i dont have the latest bdf patch, but am looking for any other suggestions before rebooting the box (not really an option right now) any new ideas?

Thanks in advance,
Richard

[Pete Randall]

Richard,

It certainly sounds like a process is still holding that file table entry open. Are you sure there are no processes still referencing the file?


Pete

[Richard Pereira_1]

Well, maybe not 100% sure. The commands were started through AT so I stopped and restarted cron, at -l , shows no jobs running. i tried ps -ef| grep (some commands and the script's name) , before the deleting the file i had run fuser and didnt see it, is there another way to find any related processes?

[Steven E. Protter]

fsuser -cu /var will give you a process list.

lsof can help you id the process to kill.

Don't do a general kill (fuser -cuk) on /var it will stop your system cold.

SEP

[Richard Pereira_1]

Found it, i tried a ps -ef and this time looked for any -sh processes running since i had schedualed it. found 1 orphan, did a kill -9 and pouf! down to 50% usage.

[A. Clay Stephenson · Accepted solution]

The problem file was deleted, so im assuming there are no remanant processes.

You can easily remove a file (more properly unlink it) and all that really happens is that the file's link count is decreased by one. Only when a file's link count goes to zero AND the file is not open by any process will the space actually be freed. As soon as the link count goes to zero, the directory entry is removed but the files contents remain intact and can even been extended. This is actually a standard way of creating a temporary file. After opening it, you instantly unlink it but can continue to operate on it until the file is closed. All traces then dissappear. Get yourself a copy of lsof and use it; it'a better than using fuser for finding these.

[Richard Pereira_1]

Clay, thanks for the explanation, you make a valid point. I'll take that into account next time.

Thanks gents

[Richard Pereira_1]

closing thread