John Franklin wrote:
 
> On Friday, June 28, 2002, at 01:26 AM, Sean Davis wrote:
> 
> > 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.
> 
> I've noticed this before.  It's not an I/O order issue.  I had a root 
> partition that was close to full and copying a new kernel into it would 
> fail the first time but succeed the second (since the old kernel had 
> been deleted by the previous failed copy.)  Turning off softdeps "fixed" 
> the problem.

You are right.  This is a phenomenon of softdeps, not the I/O sorting.
Turning off softdeps fixed the problem:

$ dd if=/dev/zero of=bigfile bs=1024k count=200 
200+0 records in
200+0 records out
209715200 bytes transferred in 8.040 secs (26083980 bytes/sec)

	-- Gregory McGarry <g.mcgarry@ieee.org>