Date: Mon, 27 Jul 2009 15:53:35 +0100 From: Bruce Simpson <bms@incunabulum.net> To: Gavin Atkinson <gavin@FreeBSD.org> Cc: freebsd-stable@FreeBSD.org Subject: Re: ataraid's revenge! (Was: Re: A nasty ataraid experience.) Message-ID: <4A6DBF6F.7050806@incunabulum.net> In-Reply-To: <1248424208.50198.2.camel@buffy.york.ac.uk> References: <200901232244.n0NMiRmM098646@lurza.secnetix.de> <46acbb3e-71bc-4cff-93d7-59b48a1a9302@exchange01.ecp.noc> <4A68B2A0.8050509@incunabulum.net> <1248424208.50198.2.camel@buffy.york.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Gavin Atkinson wrote: > On Thu, 2009-07-23 at 19:57 +0100, Bruce Simpson wrote: > >> 6 months on, ataraid(4) did it again. >> > > Which ataraid(4) controller is this? Seeing a verbose dmesg would help. > There are several patches in the PR database for ataraid problems, it > would be worth having a look. > Not much to report; it is a JMicron PCI-e card. I switched to the JMicron because it actually worked. The on-board controller is VIA and I don't use it; I've had problems managing the VIA based software RAID. Occasionally the mirror degrades, usually on boot, if something panics the machine. This leads to interesting inconsistencies and panics. All I was doing at the time was srm'ing a bunch of sensitive files, and running some CPU (not disk) intensive regression tests for Boost. I found it's difficult to recover from errors. See my post from 6 months ago about how 'atacontrol rebuild' often just plain fails. As per original post, the process(es) just wedged in getblk, and I had to take the system down to get some sense out of it as disk access ground to a halt.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A6DBF6F.7050806>