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

[Dimitar Vasilev]

2009/2/24 Carl <k0802647 at telus.net>

> 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
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>
Hi Carl,
How about a soekris board, a USB stick and a null modem cable for collecting
data from the local box? Or a laptop with a USB to serial adapter ?
Cheers,
Dimitar