Does unix ever misreport free space? We're having a problem running a utility, and the error message looks for all the world like the utility has no free space for its work files:
HOST ERROR\(D10681C\). No space left on device.
But the device itself shows ample free space.
I know that VMS drives (or controllers?) will occasionally show that they have more free space than they actually have; I wondered if any of you have had the same experience with unix.
I'm asking you folk because I need ammunition: my system administrator flatly refuses to even entertain the idea, and my users are wondering what's been going on the last few days.
Hmm.... Could there be disk quotas in place on your system? Try repquota -v filesystem where filesystem should be replaced (obviously) with something like /tmp. repquota -av will report on all filesystems. To check your own quota, run "quota -v".
I doubt if it's this, but I know that there is a "minfree" value associated with certain UNIX filesystems (which OS are you using?).
This value is normally set to 10% (at least it is under HP-UX), and this space will not be available for use by users. It can be adjusted with tunefs. Lowering the value can reclaim space, but at the con of lowering throughput on the device.
You can check the current setting with "tunefs -v /dev/vg01/lvol1" where /dev/vg01/lvol1 should be replaced with whatever device you're checking.
On our system, we sometimes reduce minfree to 5% when we are backing up our databases, and then increase back to it 10% once the data has been archived off the disk.
Well, never say never and all, but I think it would be extremely unlikely that Unix would report the free space on a filesystem wrong. The only time I've ever seen that is when somebody has deleted a file but a process had a lock on the file. So some utilities would see that the space was available since the inodes were freed, but others wouldn't since the process still claimed to be using the space. As soon as the process died (or you rebooted if the process was a zombie) they got back in sync.
My guesses as to why you are seeing that problem are (in roughly the order of likelyhood I expect)
The utility is using way more disk than you expect while it is running. It could be a case where when the utility is done it cleans up most of the space it used, but while running it doesn't have enough for its temp files and so on.
Quotas are in place (agree with ZB on that)
If you're using a volume manager like Veritas, some kind of configuration problem means the filesystem is smaller than the volume or something like that, so when you check the device it has room but the filesystem itself has run out of space.
The minfree setting. ZB mentioned that too above, but I doubt it is the problem. The reason is, for Solaris which I know best at least, only root can see the actual size. If you are checking space as a normal user it only shows you what is available not including that "padding" from minfree. So when your users check and see free space that means the space is free below the minimum cap and thus that shouldn't be an issue. But if all else fails you could try reducing minfree and see if that helps.
I remembered encounting a problem when I do a df -k as a normal user, I see x number of digits. When I do the same as root, I see x+1 number of digits.
Upon invetigation, i noticed some of the huge directories have 700 as the permission. I guess that could be the reason. It might be also due to the overflowing digit in df -k i guess....