----- Original Message ----- From: "Søren Schmidt" <sos_at_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_at_multiplay.co.uk.Received on Sun Jun 29 2008 - 15:08:04 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:32 UTC