From owner-freebsd-current@FreeBSD.ORG Tue Jul 13 13:28:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5787016A4CE for ; Tue, 13 Jul 2004 13:28:31 +0000 (GMT) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id E683643D39 for ; Tue, 13 Jul 2004 13:28:30 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from hawkwind.Chelsea-Ct.Org (pool-151-199-91-61.roa.east.verizon.net [151.199.91.61]) by gromit.dlib.vt.edu (8.12.11/8.12.11) with ESMTP id i6DDSPdX013073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Jul 2004 09:28:27 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from [192.168.1.25] (zappa [192.168.1.25])i6DDSIqs019762; Tue, 13 Jul 2004 09:28:19 -0400 (EDT) From: Paul Mather To: freebsd-current@freebsd.org In-Reply-To: <20040713120051.00A3E16A4CF@hub.freebsd.org> References: <20040713120051.00A3E16A4CF@hub.freebsd.org> Content-Type: text/plain Message-Id: <1089725297.92521.55.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 13 Jul 2004 09:28:18 -0400 Content-Transfer-Encoding: 7bit cc: Gabriel Ambuehl cc: Harald Schmalzbauer Subject: Re[2]: Whay is broken ATARAID that ignored? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2004 13:28:31 -0000 On Mon, 12 Jul 2004 19:22:23 +0200, Gabriel Ambuehl wrote: > I know. But rather this than FreeBSD going on to write to a RAID1 array > that's actually out of sync. Nobody in their sane mind will yank out > drives, modify just one and then expect it to still work. Nobody in their sane mind would expect this *not* to work! It's one of the basic tenets of RAID 1 that if one drive fails (is unavailable to the array) that the array will still continue to be usable (i.e., you can read from it and write to it using the remaining drives) until the failed drive is eventually replaced and the whole array brought back into sync by reconstructing onto the new (replacement) drive. Being able to write to a degraded array means it *will* be out of sync with whatever replacement drive is eventually used. It shouldn't matter whether the drive failure is actual or "simulated" (by removal and later replacement of the same drive). It should correctly recognise an array inconsistency and reconstruct properly. I use RAIDframe under NetBSD/alpha and it even has an option to raidctl to "soft fail" a RAID component, as well as allowing reconstruction onto specific replacement drives. It is very likely (and entirely sensible) that people will undergo various simulated failure testing, and physical removal of a drive is the easiest way to do this. (Actually, I guess the "detach/attach" approach as suggested in the handbook is even easier.) I know that's what I did, and I couldn't get "atacontrol rebuild" to work at all so I gave up on ATA RAID. It's better to know beforehand that you won't be able to reconstruct a RAID array when it fails that to discover that fact after an actual real failure when you have important data on it. (I did the same failure and reconstruction testing under RAIDframe before deciding to adopt it on my NetBSD/alpha system. The man page even strongly encourages doing this, so you know and have practised the steps before an actual failure happens, thereby minimising the chances of first-time operator error.) > As to documenting it, that wouldn't hurt. It would actually help *a lot*. It's better to document things properly to allow people to make an informed choice beforehand than to have them commit to something and then regret it later when they find it doesn't actually work. I would rather have known up-front that ATA RAID is "not ready for prime time" than to have wasted all the time I did finding that out for myself. This is especially true of a system that is somewhat geared towards improving reliability. I don't mind if something doesn't work, but I'd rather know that up front where possible. > >> Well I do agree the rebuild procedure should be described better. Here is the "rebuild" documentation (from atacontrol(1)): rebuild Rebuild a RAID1 array on a RAID capable ATA controller. There is also Section 13.4.3 of the handbook, but that is prefaced with an assumption that you are using hot-swap drives. It does not say what to do if your system does not have hot-swap drives. So, there are a lot of common cases not covered by anything other than the one-liner in atacontrol(1). I've asked before, so I guess I should ask again, for official clarification of the one-line "rebuild" description: will it work for a FreeBSD native RAID array, i.e., one created and hosted on a non-RAID controller. The "create" entry in atacontrol(1) states the following: create Create a type ATA RAID. The type can be RAID0 (stripe), RAID1 (mirror), RAID0+1 or SPAN (JBOD). In case the RAID has a RAID0 component, the interleave must be specified in number of sec- tors. The RAID will be created of the individual disks named disk0 ... diskN. Although the ATA driver allows for creating an ATA RAID on disks with any controller, there are restrictions. It is only possi- ble to boot on an array if it is either located on a ``real'' ATA RAID controller like the Promise or Highpoint controllers, or if the RAID declared is of RAID1 or SPAN type; in case of a SPAN, the partition to boot must reside on the first disk in the SPAN. (Note the first sentence of the second paragraph, particularly the "any controller" part.) In the restrictions, nothing is mentioned about rebuilding (only booting). Yet, the "rebuild" entry explicitly mentions "RAID capable." Is it possible to rebuild an ATA RAID array on a non-RAID capable controller (i.e., a standard ATA controller)? Because you can create and use ATA RAID arrays on such non-RAID capable controllers, it would seem worthy to mention the important caveat that you can't rebuild arrays using them if that is the case. (That would beg the question, why allow ATA RAID arrays to be created on them, then? Are you supposed to move the drives to a RAID capable controller machine after array creation for actual use? Or are you supposed to move them just to effect reconstruction??) One way or the other, it would be nice to know ahead of time. I wonder how geom_mirror is coming along... Cheers, Paul. -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa