From owner-freebsd-stable@FreeBSD.ORG Thu Sep 13 10:43:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18A031065672 for ; Thu, 13 Sep 2012 10:43:17 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [128.127.144.4]) by mx1.freebsd.org (Postfix) with ESMTP id B1D7D8FC12 for ; Thu, 13 Sep 2012 10:43:15 +0000 (UTC) Received: from bsdrookie.norma.com. ([IPv6:fd00::7f0]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id q8DADp0L041637 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 13 Sep 2012 16:13:51 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <5051B1DF.9030300@norma.perm.ru> Date: Thu, 13 Sep 2012 16:13:51 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120806 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <50516F96.1020905@rdtc.ru> <5051ACBD.1090207@FreeBSD.org> In-Reply-To: <5051ACBD.1090207@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Thu, 13 Sep 2012 16:13:51 +0600 (YEKT) X-Spam-Status: No hits=-97.8 bayes=0.5 testhits RDNS_NONE=1.274, SPF_SOFTFAIL=0.972, TO_NO_BRKTS_PCNT=0.001, USER_IN_WHITELIST=-100 autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Subject: Re: GEOM_RAID in GENERIC is harmful X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 10:43:17 -0000 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.