Date: Tue, 13 Jul 2004 09:28:18 -0400 From: Paul Mather <paul@gromit.dlib.vt.edu> To: freebsd-current@freebsd.org Cc: Harald Schmalzbauer <h@schmalzbauer.de> Subject: Re[2]: Whay is broken ATARAID that ignored? Message-ID: <1089725297.92521.55.camel@zappa.Chelsea-Ct.Org> In-Reply-To: <20040713120051.00A3E16A4CF@hub.freebsd.org> References: <20040713120051.00A3E16A4CF@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 Jul 2004 19:22:23 +0200, Gabriel Ambuehl
<gabriel_ambuehl@buz.ch> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1089725297.92521.55.camel>