Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Jul 2009 19:57:36 +0100
From:      Bruce Simpson <bms@incunabulum.net>
To:        freebsd-stable@freebsd.org
Subject:   ataraid's revenge! (Was: Re: A nasty ataraid experience.)
Message-ID:  <4A68B2A0.8050509@incunabulum.net>
In-Reply-To: <46acbb3e-71bc-4cff-93d7-59b48a1a9302@exchange01.ecp.noc>
References:  <200901232244.n0NMiRmM098646@lurza.secnetix.de> <46acbb3e-71bc-4cff-93d7-59b48a1a9302@exchange01.ecp.noc>

next in thread | previous in thread | raw e-mail | index | archive | help
6 months on, ataraid(4) did it again.

    This time, I was lucky -- I caught in in time, but the damage to the 
filesystem meant having to use fsdb to NULL out the affected inodes; 
mounting read-only, tarring, and untarring across the network, after a 
newfs, let me save the affected partition.
    All I was doing at the time was srm'ing a few sensitive files; all 
the processes wedged in WCHAN getblk. It seems ataraid(4) is not robust 
against temporary drive/controller problems. The SMART logs on the 
affected array drives all check out just fine, there are no bad block 
remaps.

So, time to either buy a hardware RAID controller, or move to ZFS...



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A68B2A0.8050509>