Very Computer

I've had this problem in SunOS 4.1.3 and in Solaris 2.4. If a filesystem
becomes full and I delete a lot of files so that it has a lot of free
space, that fact is not noticed by the system. df report 100% and any
write operation report "file system full". I have tried a lot of
things but the only solution is to reboot. I have seen this bug
reported in SunSolve, but without solution.

Does anybody know how to solve it ?

--
+-----------------------------------^---------------------------------------+

| Centro de Calculo Cientifico      ^  Tlf: 957-218119                      |
| Universidad de Cordoba (SPAIN)    ^  MIME Spoken Here                     |
| gopher://gopher.uco.es            ^  http://www.uco.es                    |
+-----------------------------------^---------------------------------------+

Quote:>I've had this problem in SunOS 4.1.3 and in Solaris 2.4. If a filesystem
>becomes full and I delete a lot of files so that it has a lot of free
>space, that fact is not noticed by the system. df report 100% and any
>write operation report "file system full". I have tried a lot of
>things but the only solution is to reboot. I have seen this bug
>reported in SunSolve, but without solution.

>Does anybody know how to solve it ?

>--

You could observe that kind of behaviour if the files you delete are still opened
by an other process. The directory entries are no longer there, but the file space
will be reclaimed only when the last process that has the file open closes it.

Just because you delete a file does not mean the it is removed from use.
This can be seen when you attempt to delete a log file that is still opened
for use.  The disk storage is not released until the file is closed, even
though it no longer appears in a directory listing.  I'll bet that the
files you tried to delete were in /var where there are a lot of files
that are in use by daemon programs.

The effect of rebooting solving your problem is really killing the daemon
programs that own the files, thus releasing the disk space.  What you really
want to do is to use "fuser" to determine which process(es) is/are using the
file, kill the process, remove the file, restart the process.

Rather than deleting the pesky log file, do the following:

% cat > /var/tmp/pesky_log_file
^D
%

this causes the file to be truncated in place so the space can
be reclaimed w/o killing processes....

---
Bart Smaalders                  OS Performance          SunSoft

http://playground.sun.com/~barts                   2550 Garcia Ave
                                                        Mt View, CA 94043-1100

Quote:> I've had this problem in SunOS 4.1.3 and in Solaris 2.4. If a filesystem
> becomes full and I delete a lot of files so that it has a lot of free
> space, that fact is not noticed by the system. df report 100% and any
> write operation report "file system full". I have tried a lot of
> things but the only solution is to reboot. I have seen this bug
> reported in SunSolve, but without solution.

> Does anybody know how to solve it ?

 Most likely the process that has the offending file space allocated still
has the file OPEN. the space will not be release to the disk until the file
is closed. (IE: the process closes the file, is killed (thus closing the file),
or the system is rebooted, thus killing the process, thus freing up the space.
The trick is to figure out which process is hogging the disk space..
--
 Name:Trevor Paquette      |Alberta Energy Company Ltd |Work:(403) 266-8400

I disagree.  Your procedure does nothing to reset the write pointer in the
offending process.  What happens is that the next time the processs writes,
the file is back with a long ton of leading nulls.

: >Rather than deleting the pesky log file, do the following:
: >
: >% cat > /var/tmp/pesky_log_file
: >^D
: >%
: >
: >this causes the file to be truncated in place so the space can
: >be reclaimed w/o killing processes....

: I disagree.  Your procedure does nothing to reset the write pointer in the
: offending process.  What happens is that the next time the processs writes,
: the file is back with a long ton of leading nulls.

But are those leading nulls actually stored on disk?

        mike

--

Any opinions expressed are mine only, and not necessarily
those of any other entity.  They may not even be mine.

I think I'd run fsck -N on the volume to see how many files
you have that are no longer part of the filesystem.

The -N says reply N to anything fsck tries to do.

Check which flag will ensure NO-write operation BEFORE you run fsck

Ivan Bishop
<my opinions, my mistakes>

But certain operations which don't deal with 'holey' files can be adversely
affected and can even cause the file to fill in (when copying or the like).

When you truncate a log file you want the real AND logical sizes to be
reduced.
--
  Frank Peters - UNIX Systems Group Leader - Mississippi State University

                  <URL:http://www2.msstate.edu/~fwp/>

Even in those circumstances, the space is still relaimed.

But in the case of cronlog, truncating the logfile
does work.

Of course, Bart does get a "useless use of cat" award.
In ksh/sh you can truncate a file with:

        >log

and in virtually all shells with:

        :>log

or even:
        true > log

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.