Skip site navigation (1)Skip section navigation (2)
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>