On Apr 27, 2010, at 5:33 AM, Gavin Atkinson wrote: > On Mon, 2010-04-26 at 10:33 -0600, M. Warner Losh wrote: >> 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. > > Losing ataraid would be bad. I suspect there are a lot of installs > using it - especially as there is no way to create any other mirror from > sysinstall. However, I'm not actually sure that the functionality it > provides is easy to push down into GEOM. > > ataraid depends on knowing a lot about the underlying hardware, in order > to know which format of metadata to use. i.e. it needs to know that the > disks are attached to (say) a Highpoint controller.
This is unfortunately true, especially on older controllers. I think that there are reasonable ways to address this though, by having CAM SIMs provide a bit more information in their PATH_INQ response. Scott _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
