UNIX for Advanced & Expert Users

Thanks for that info. My minfree is set to 0. So I guess that means any user can use 100%.

Regarding the inode issue, I believe that this is correct for HPUX. With OnlineJFS for HPUX vxfs filesystems, inodes are created dynamically so you never run out. For the hfs file systems in HPUX, inodes are static and are created at filesystem creation and you can run out here even though you may still have disk space remaining.

You're right, not all filesystem types can run out of inodes. But the OP has space remaining in his filesystem and gets the error message anyway. Something must be wrong, and inodes are a possibility.

And minfree also is a filesystem type thing. The McKusick filesystem, which HP calls hfs, does need some minfree. Do you really have an HFS filesystem with minfree set to 0? That's not a good idea, but with HP your only problem should be file fragmentation.

All of my / filesystems segregated from the others so it shouldn't be an issue for hfs.

And yes, all of my 11.x and 11.i boxes have minfree at 0. I have inherited these systems, but I think it is by design. There are Oracle 10-15 filesystems on 14 different boxes that are anywhere from 20GB to 70GB each. That would be an incredible amount of space to give up.

If I get close to 85-90% we usually order more disks. That's just my environment...

Actually, I just went back to the www.itrc.hp.com site and read this.

http://docs.hp.com/cgi-bin/otsearch/...0020611-120828

The default value for minfree on HP-UX file systems is 10 percent. To determine the current value of minfree, use the df command with the -t option (see HP-UX Reference entry df(1M)). The value is determined by the current value of fs_minfree in the file-system data structure (see fs(4)).

For example, to find the current value of minfree on the mounted file system /users, use the command:


# df -t /home
/home (/dev/vg00/home ): 560488 blocks 74718 i-nodes
614400 total blocks 75356 total i-nodes
16634 used blocks 638 used i-nodes
6 percent minfree

Hey,

I don't know if still have the problem, but my comment to that situation ( even its a little bit late ):

If you have a file which is still open by a process and somebody deletes this file the process can still write to or lock this file . But as the inode is marked as deleted a df cann't see it and don't uses it for its calculation. But the space an the filesystem is still allocated. As soon as the process ends the space will be free.

Saw this already some times on different hpux systems, don't know if this can also happen on othe ux's.

There are two solutions to solve this problem.
1. You can find a process which uses this filesystem. Maybe you know that only a specific application uses this fs or you see a process which normaly doesn't run. But normaly you will not find anything.
2. which always works ... reboot. Then all processes dies and after the system is up again the space will be free again.

br
martin

Actually, when a file has zero names, the space it consumes still shows up in df (and on HP-UX, bdf). We have this situation at least once a week on both HP-UX and SunOS. df reports 100% space used but du can't find the culprit. That must be what you're think of, it's du that can't see files with zero names.

Another solution by the way, is lsof. It can tell you which processes are using the filesystem.