UFS2 and/or sparse file bug causing copy process to land in 'D''
k0802647 at telus.net
Tue Feb 24 00:42:39 PST 2009
The same truncate sequence has now been tried on a second system which
is hardware- and OS-identical. The same hanging scenario occurs on it.
That should eliminate the possibility of a defective hard disk as the cause.
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.
Given the latest hang opportunity, "reboot -q" and "reboot -nq" were
tried as suggested by Kevin Day. The former didn't work and itself went
into the 'D' state permanently. The "-nq" option *did* work, but
obviously one has to recognize it's needed before totally hanging the
remote system. Once the tar process has hung, screen keeps working,
which gives a chance to create/change to a new window and issue the
reboot. New SSH connections don't work. Commands like ps and date still
work, but commands like ls go straight into a permanent 'D' state
themselves. Bad scene for a remote system :-(
Dimitar Vasilev wrote:
> 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 ?
I'll take them ;-)
Sorry, Dimitar, if I was unclear. I've already got equipment connected
to the serial console on my local machine, so capturing output is no
problem. It's all the kernel debugging stuff I've no knowledge of.
Carl / K0802647
More information about the freebsd-fs