Very Computer

Can someone makes sense of what shown below.

I truncated a file with "> list.trc", and it works
because /var capacity dropped dramatically.
But the size of list.trc comes back when shown with "ls".
It does not make sense since the used space is
"35006" per df so we can not have a file with size 117175216
as shown by ls.

How can I make things consistent? Thank you.

# df -k .
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/dsk/c0t0d0s4     246167   35006  186545    16%    /var
# ls -ls
total 104
  64 -rw-r--r--   1 oracle   dba      117175216 Apr 26 14:32 list.trc
# > list.trc
# ls -ls
total 40
   0 -rw-r--r--   1 oracle   dba            0 Apr 26 14:32 list.trc
# ls -ls
total 40
   0 -rw-r--r--   1 oracle   dba            0 Apr 26 14:32 list.trc
# ls -ls
total 88
  48 -rw-r--r--   1 oracle   dba      117175237 Apr 26 14:33 list.trc
# df -k .
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/dsk/c0t0d0s4     246167   34998  186553    16%    /var
--
Michael Wang
http://www.mindspring.com/~mwang

Notice the first column, which says that it's only taking up 48K in actual
disk space.  The file has an enormous hole.

This is probably a log file that some other process has open.  Although
you've truncated it, the other process's file pointer doesn't change.  The
next time it writes something, it writes it starting at byte 117175216.
The rest of the file is empty, and doesn't take up any disk space.

You probably need to kill that process, truncate the file, and then restart
it.

Quote:>How can I make things consistent? Thank you.

># df -k .
>Filesystem            kbytes    used   avail capacity  Mounted on
>/dev/dsk/c0t0d0s4     246167   35006  186545    16%    /var
># ls -ls
>total 104
>  64 -rw-r--r--   1 oracle   dba      117175216 Apr 26 14:32 list.trc
># > list.trc
># ls -ls
>total 40
>   0 -rw-r--r--   1 oracle   dba            0 Apr 26 14:32 list.trc
># ls -ls
>total 40
>   0 -rw-r--r--   1 oracle   dba            0 Apr 26 14:32 list.trc
># ls -ls
>total 88
>  48 -rw-r--r--   1 oracle   dba      117175237 Apr 26 14:33 list.trc
># df -k .
>Filesystem            kbytes    used   avail capacity  Mounted on
>/dev/dsk/c0t0d0s4     246167   34998  186553    16%    /var
>--
>Michael Wang
>http://www.mindspring.com/~mwang

--

GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

Quote:

>Notice the first column, which says that it's only taking up 48K in actual
>disk space.  The file has an enormous hole.

>This is probably a log file that some other process has open.  Although
>you've truncated it, the other process's file pointer doesn't change.  The
>next time it writes something, it writes it starting at byte 117175216.
>The rest of the file is empty, and doesn't take up any disk space.

>You probably need to kill that process, truncate the file, and then restart
>it.

Indeed it is a log file used by oracle listener. Restarting it
will disrrupt the service.

Thank you for your analysis.
--
Michael Wang
http://www.mindspring.com/~mwang

I had/have similar problems with my WWW server. It turned out to
be twofold:

1) Some software doesnt write their log files in O_APPEND mode.
   If it would do so, the effect you see would not happen because
   a truncate would not allow the other process to continue
   writing at the filepointer it wrote last (the meaning of O_APPEND
   is: always correct the filepointer to the real EOF before
   commiting any write operation).
   ==> Either tell the software writer to fix it or, if you are
       the implementor (like with shell scripts), make sure the
       log is written in O_APPEND mode. See thread
       "2.6 O_APPEND/truncate bug?" for more information.

2) Solaris 2.6 /bin/sh behaves differently from all other sh I have
   access to in that it will execute the sequence

   for f in f1 f2 f3 ; do
    echo $f
    : > $f
   done

   by writing *only* to f1 and *never* to f2 or f3. I dont know
   if that is a real bug or a Bourne shell quirk one should know
   about, but ksh, bash and Digital Unix /bin/sh execute the code
   as expected. Its probably due to sh doing such loops as if
   they would be a one-liner and never evaluating the redirect
   twice...

--

 "the big bang: the ultimate hero of low frequency;
  the divine intergalactical bassdrum" -- Yello, "solar driftwood"

+-o-+--------------------------------------------------------+-o-+
| o |               \\\- Brain Inside -///                   | o |
| o |                   ^^^^^^^^^^^^^^                       | o |
| o | Andre' Beck (ABPSoft)   AB10-RIPE    Xlink PoP Dresden | o |
+-o-+--------------------------------------------------------+-o-+