Unix

Hi All,

Can anybody tell what is the reason
when I type df . the result shows as below
Filesystem 1024-blocks Used Available Capacity Mounted on
data3_domain#data3 35556784 31222753 3809472 90% /data3

so, in /data3 still 10% available to used, when I create a file with single line its giving the message "No space left on device"
unable to create a file.

Thanks
Krishna

Hi

If U use vi editor to create a file , it uses temporary files to process your activities. Default path for these temp files is either "/opt/tmp" or some some "tmp" .

Eventhough you are working in /data3 , you need to check the "df" for the above mentioned directory or change the default temporay file path to "/data3 " area in ".exhrc" file

Bye:cool:

df -k (gives you them all at once in a 'nice' format).

If you want to see if you can create a file on /data3, just use echo.

echo This is a test file for data3 > file.out

This will read from stdout to the file named...

Or you can use touch to just create a 0 byte file in the directory.

touch file.out

Also, check your /tmp and /var/tmp for available space as well.

:cool:

I do beleive only root can write to a filesystem over 90% full.

As a user account you will be unable to create a file.

Are you creating the file as root?

halfling,

That is very interesting. I have never heard of that. Can you tell me where you heard that from and what OS it was referring to?

It is hard for me to believe that is the case now. If a user has permission to write to a filesystem, why should they be restricted at 90%?

This could have been setup with Quotas. Can you provide more information on this?

Thanks!

:wink:

That is way unix has worked for quite a long time. Do a "man tunefs" and look at the minfree parameter.

But df takes this into account. A ordinary user can use 100% of the disk as reported by df. root can run a disk up to 111%. I've seen that many times.

My guess is that the OP is out of inodes. No inodes, no new files.

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/getfile?id=/hpux/onlinedocs/os/KCparam.AcctngThresholdTut.html&searchterms=minfree&queryid=20020611-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

:smiley: :wink:

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.