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

Carl k0802647 at telus.net
Wed Feb 25 01:53:17 PST 2009

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?

         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

Carl                                             / K0802647

More information about the freebsd-fs mailing list