Date: Thu, 13 Sep 2012 12:51:57 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Eugene Grosbein <egrosbein@rdtc.ru> Cc: stable@freebsd.org, re@freebsd.org Subject: Re: GEOM_RAID in GENERIC is harmful Message-ID: <5051ACBD.1090207@FreeBSD.org> In-Reply-To: <50516F96.1020905@rdtc.ru> References: <50516F96.1020905@rdtc.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13.09.2012 08:31, Eugene Grosbein wrote: > 9-STABLE has got options GEOM_RAID in GENERIC. > In real world, this change is pretty harmful and there are lots of cases > when 9.0-RELEASE systems upgraded to 9-STABLE fail to mount root UFS filesystem > or attach ZFS. > > It seems, there are lots of HDDs supplied with pseudo-RAID labels at the end: > pre-installed Windows machined having motherboards with pseudo-RAID > like Intel RapidStore and alike. One can not even be aware of these labels. > > 9.0-RELEASE can be installed on such HDDs and use them with GMIRROR or ZFS > without a problem. Upgraded to 9-STABLE, such system fails to build due > to GRAID jumping out of box and grabbing HDDs for itself, > so GMIRROR or ZFS got broken. > > That's makes users very angry when production server fails to boot > with GENERIC kernel after correctly performed upgrade. > > GEOM_RAID compiled in GENERIC should be deactivated and require activation > with some loader knob. Also, we need distinct RELEASE NOTES warning about the issue. Problem of on-disk metadata garbage is not limited to GEOM_RAID. For example, I had case where remainders of old UFS file system were found by GEOM_LABEL and ZFS incorrectly attached to it instead of proper GPT partition, making other partitions inaccessible. Does it mean we should remove GEOM_LABEL also? I don't think so. All what GEOM_RAID is guilty in is that it was not in place for 9.0 release. If we remove it now, it will just postpone the problem for later time or will never be able to add it again because of the same reasons. Unlike GEOM_LABEL, metadata of GEOM_RAID is quite easy to delete without complete disk erase: `graid status -ag`, `graid delete ...`. Yes, it can be a problem if system can't boot, but now we at least have live mode on installation images, that should allow to do it. Adding some loader tunables indeed could simplify recovery in case of boot problem. I will probably add such ones now. It won't hurt. But I disagree they should be disabled by default, limiting users who really want to use BIOS RAID. Disabling them will also make metadata removal without full wipe more difficult because different RAIDs have different on-disk metadata layout, and you should know where exactly to apply dd. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5051ACBD.1090207>