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

[Carl]

Robert Watson wrote:
> It would be interesting to get kernel stack traces of the involved 
> processes/threads; there are various ways to do this, such as using 
> DDB.  If you have a kernel.symbols for the kernel, then you can run kgdb 
> on kernel.symbols and /dev/mem to generate traces without interrupting 
> operation (although if the system is in the throes of deadlocking, that 
> may not be a concern or even possible).  You can also use procstat -kk 
> to retrieve kernel stack traces, with a bit less information (such as no 
> arguments) to help narrow things down more.
> 
> Unfortunately, debugging this type of problem, as you've intuited, is 
> best done with serial console access and a local box so that the 
> debugging information can be extracted.  It would be interesting to know 
> if you can force a crashdump on the box to get the information for 
> post-mortem debugging. This may be possible using "reboot -d" -- I've 
> never used this, but have every reason to think it will work.

I have both a local and remote box. The problems I'm seeing are all 
occurring on the local box because as yet I cannot afford to cause them 
on a remote box.

If you were to guess I've never used DDB or any other kernel debugging, 
you'd be spot on. I'm currently running the 7.0-RELEASE GENERIC kernel. 
I see a /boot/kernel/kernel.symbols in the filesystem. The system is 
nominally headless with a serial console, although I primarily use SSH. 
Even if I knew what to do with them, actually collecting kernel dumps is 
a hit or miss affair because of gmirror, but this particular problem 
doesn't cause kernel core dumps on its own (thankfully, since gmirror 
resyncs take a long time on terabyte drives). So, if you were able to 
clearly spell out the stripped down steps I should take in conjunction 
with my earlier truncate sequence and if it doesn't require rebuilding 
the kernel, I might be able to accommodate. Learning all about kernel 
debugging would be interesting but doesn't fit in my schedule right now.

Anyone willing to attempt to reproduce this problem on their system?

Carl                                             / K0802647