I noticed this yesterday as well, when removing a core dump so that I could
savecore another without filling up the partition. I had to sync and then
savecore to make it work. Are the performance improvements from this
signifigant enough to justify the annoyance of situations like that?

On Fri, Jun 28, 2002 at 05:01:42PM +1200, Gregory McGarry wrote:
> More to consider wrt sorted I/O requests.  If I fill a partition
> by creating a large file, delete the file and attempt to create
> another large file in its place, the delayed deletion operation
> causes the second creation to fail.
> 
> $ pwd
> /storage/scratch
> $ dd if=/dev/zero of=bigfile bs=1024k count=200 
> 200+0 records in
> 200+0 records out
> 209715200 bytes transferred in 8.326 secs (25187989 bytes/sec)
> $ rm bigfile 
> $ df 
> Filesystem  1K-blocks     Used     Avail Capacity  Mounted on
> /dev/wd0a       63248    31634     28451    52%    /
> /dev/wd0e      253615    83672    157262    34%    /var
> /dev/wd0f     1465278   372914   1019100    26%    /usr
> mfs:123         31727     2175     27965     7%    /tmp
> /dev/wd0g     1018329    56420    909297     5%    /home
> /dev/wd0h    12766536 11862460    265748    97%    /storage
> $ dd if=/dev/zero of=bigfile bs=1024k count=200 
> 
> /storage: write failed, file system is full
> dd: bigfile: No space left on device
> 60+0 records in
> 59+0 records out
> 61865984 bytes transferred in 2.729 secs (22669836 bytes/sec)
> 
> 	-- Gregory McGarry <g.mcgarry@ieee.org>

-- 
/~\ The ASCII                         Sean Davis
\ / Ribbon Campaign                    aka dive
 X  Against HTML
/ \ Email!                   http://endersgame.net/~dive/