Date: Sun, 29 Jun 2008 18:09:31 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@FreeBSD.ORG> To: Steven Hartland <killing@multiplay.co.uk> Cc: Garrett Cooper <yanefbsd@gmail.com>, Benjamin Close <Benjamin.Close@clearchain.com>, current@FreeBSD.ORG, Rainer Duffner <rainer@ultra-secure.de> Subject: Re: URGENT: Need help rebuilding iir RAID5 array with failed drive Message-ID: <43FD37E0-207A-4400-A95C-2301B5CD2B24@FreeBSD.ORG> In-Reply-To: <FAEE486EB48B440A866156003FBA41C9@multiplay.co.uk> References: <7d6fde3d0806260649t6619521bv92b65c472ddb7e1@mail.gmail.com> <6.0.0.22.2.20080627170323.02591528@mail.computinginnovations.com> <7d6fde3d0806272057p795277a2ie60ac7d7d10f0a6e@mail.gmail.com> <7d6fde3d0806280129i31874960ofbc7627598e1426f@mail.gmail.com> <735A937C-89A9-411A-AA3F-377F576E635E@freebsd.org> <7d6fde3d0806280348r65875755pf7dc3917bba2bcb5@mail.gmail.com> <7d6fde3d0806280349j7eace513idb5cd81f9e2e4e0a@mail.gmail.com> <6.0.0.22.2.20080628132240.0255ba38@mail.computinginnovations.com> <7d6fde3d0806281410r781a6a77k98ffe237c10e3eee@mail.gmail.com> <D0A03968-B9F2-4EF8-B754-D0EFA90A9C1E@FreeBSD.ORG> <7d6fde3d0806282011x472f8d27s955a8e1ab43a7341@mail.gmail.com><F8F21D91-0BF9-4525-A397-D2632821C7E5@ultra-secure.de> <48679898.3000905@clearchain.com> <FAEE486EB48B440A866156003FBA41C9@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29Jun, 2008, at 16:24 , Steven Hartland wrote: > > ----- Original Message ----- From: "Benjamin Close" = <Benjamin.Close@clearchain.com=20 > > > >> Perhaps a lesson as developers we should take from this, is to put =20= >> a warning in ata about raid5. It's fooled Garret into believing he =20= >> had a raid5, how many others are also using ata believing their =20 >> raid5 is a raid5. We should warn people in the future rather than =20 >> just saying 'its in the docs'. A kernel warning at attach is much =20 >> more visible. > > Although it is more visible, personally I would prefer it to just fail > instead of proceeding. RAID5 is not RAID5 without parity so why even > allow it to continue and hence risk such an unrecoverable situation? Well, this has been rehashed many times before, it has been disabled, =20= put a warning in the boot log, warning in the docs, all 3 was the =20 favorite at the time it was done. I'm all ears for what the decision might be this time, just get =20 consensus and I'll flip the right switch. -S=F8ren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43FD37E0-207A-4400-A95C-2301B5CD2B24>