Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 29 Jun 2008 18:05:15 +0100
From:      "Steven Hartland" <killing@multiplay.co.uk>
To:        =?iso-8859-1?Q?S=F8ren_Schmidt?= <sos@FreeBSD.ORG>
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:  <B14F86C7175B42628E15687A263C8DA1@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> <43FD37E0-207A-4400-A95C-2301B5CD2B24@FreeBSD.ORG>

next in thread | previous in thread | raw e-mail | index | archive | help

----- Original Message ----- 
From: "Søren Schmidt" <sos@FreeBSD.ORG>
>> 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,  put a warning in the boot log, warning in the docs, all 3 
> was the  favorite at the time it was done.
>
> I'm all ears for what the decision might be this time, just get  consensus and I'll flip the right switch.

As a small expansion to this, a good compromise might be to disable it
unless a sysctl flag is explicitly set. Similar to how the sysctl
kern.geom.debugflags=16 works? Then for those that know the implications
they can still have the functionality but prevents someone stumbling
into a nasty situation without being aware of the issues.

    Regards
    Steve 


================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.




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