Date: Thu, 13 Sep 2012 16:13:51 +0600 From: "Eugene M. Zheganin" <emz@norma.perm.ru> To: freebsd-stable@freebsd.org Subject: Re: GEOM_RAID in GENERIC is harmful Message-ID: <5051B1DF.9030300@norma.perm.ru> In-Reply-To: <5051ACBD.1090207@FreeBSD.org> References: <50516F96.1020905@rdtc.ru> <5051ACBD.1090207@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi. On 13.09.2012 15:51, Alexander Motin wrote: > > 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. > From my point of view, the policy of new features should be like that: new features introduced to the system should by default try to mimic the old behavior. Right now we will have a situation when most of the users will just upgrade to the new kernel, and will get a non-bootable system or a system with one 100% busy disk (for example degraded raid0 gives this). On a system that manages to boot up 'graid delete -f' could lead to a livelock (got it today, on a degraded raid1). Furthermore, the situation when the engineer forgot about a disk with a glabel/gmirror data is less probable than a situation when you have a 'new' disk from another department which was extracted from some windows server or workstation. Should I test all of the disks against graid labels ? Yeah, may be. But for X last years I didn't do that, just because it worked for me and it didn't lead to a crash. The softraid labels were harmless all the way. I could use a zpool or a gmirror without even knowing that I have them. Now I suddenly need to care about the labels. Is GEOM_RAID great, as a feature ? Yep, it is. Is the way it is introduced into the system that great ? Not at all. From my point of view GEOM_RAID in GENERIC kernel is a bomb, and we will lose lots of FreeBSD beginners due to this. Eugene.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5051B1DF.9030300>