Date: Mon, 26 Apr 2010 12:19:46 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: pjd@FreeBSD.org Cc: mav@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? Message-ID: <20100426.121946.506212773266921087.imp@bsdimp.com> In-Reply-To: <20100426181209.GB3012@garage.freebsd.pl> References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> <20100426181209.GB3012@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20100426181209.GB3012@garage.freebsd.pl>
Pawel Jakub Dawidek <pjd@FreeBSD.org> writes:
: On Mon, Apr 26, 2010 at 10:33:27AM -0600, M. Warner Losh wrote:
: > I've read most of this thread. I think this is cool technology.
: > However, before we move forward with this, we need to have a plan for
: > the various issues that have come up. The plan needs to be specific,
: > have owners for key items, warnings about ownerless == obsoleted, and
: > target dates.
: >
: > I think this is one of the cases where we should record the plan of
: > record on a wiki. It worked well for other times we've had big,
: > disruptive changes.
: >
: > My opinion for the path forward:
: > (1) Send a big heads up about the future of ataraid(5). It will be
: > shot in the head soon, to be replaced be a bunch of geom classes
: > for each different container format. At least that seems to be
: > the rough consensus I've seen so far. We need worker bees to do
: > many of these classes, although much can be mined from the ataraid
: > code today.
:
: This shouldn't be a bunch of GEOM classes. This should one class which
: recognize multiple formats, just like the LABEL class.
: I don't think it is feasible to reuse gmirror for that, it wasn't
: designed in something like this in mind.
OK. Maybe I got the consensus wrong... My key point is that we need
a plan moving forward, we need to identify what's actively being
worked on vs "somebody else[tm] should do tihs" and when it needs to
be done "or else".
: > (2) Send another big heads up strongly recommending people go to
: > glabel based fstabs. Maybe the right option here is to provide a
: > simple script walk people through the conversion. This will
: > render the carnage of ad -> ada (or da) a mostly non-event, and
: > also protect people from 'oops' of rebooting with that thumb drive
: > in the system.
: > (3) Create a wiki to record all the new geom classes needed. Find
: > people to own each one, or note it is unowned, and support will be
: > dropped if no owner can be found.
: > (4) sysinstall should default to creating label systems, if it doesn't
: > already.
: > (5) Issues with glabel and ataraid(5) need an owner, and need to be
: > resolved, since the device names here are likely to change.
:
: What are the issues?
ataraid doesn't remove the underlying ad* devices, so glabel often
picks those up instead of the ataraid device, and you only get 1
disk's worth of raid device... So no mirroring or only 1/2 a striped
volume.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100426.121946.506212773266921087.imp>