UFS2 and/or sparse file bug causing copy process to land in 'D'' state?

[Carl]

Peter Jeremy wrote:
>> The same sequence has also now been tried on a laptop, both natively and in 
>> a virtual machine on top of WinXP, although both were FreeBSD 7.1 rather 
>> than 7.0. Neither have failed so far.
> 
> So it's possible that the bug you are hitting was fixed between 7.0
> and 7.1.  Is it possible for you to upgrade to 7.1?

It is and it will happen, but not for a while yet, especially for the 
remote system.

I should note that the 7.0 systems that fail are entirely different 
hardware using gmirror and gjournal whereas the 7.1 laptop and VM 
instances are not - rather a lot of variables changed at once.

Peter, are you aware of some specific fixes between 7.0 and 7.1 that 
might explain my problem?

> At this stage, all I can suggest is that it's time for you to expand
> your knowledge :-)

Oh I am, Peter, I am. But I need a whole lot more hours in a day to add 
that to the list right now :-)

Seriously though, are there some FreeBSD developers with even vaguely 
similar configurations that might be interested enough to inflict the 
following simple loop on their system to see if they can reproduce this?

         #!/bin/csh
         set count = 0
         while( $count < 20 )
           @ count = $count + 1
           echo "truncate attempt $count..." >> /tmp/ouch.log
           truncate -s 671088640 target
           mdconfig -f target -S 512 -y 255 -x 63 -u 7
           bsdlabel -w /dev/md7 auto
           newfs -O2 -m 0 -o space /dev/md7a
           mount /dev/md7a /mnt
           tar -cvf - -C /usr/src . | tar -xvpof - -C /mnt
           umount /mnt
           mdconfig -d -u 7
           rm target
         end

Carl                                             / K0802647