Date: Tue, 18 May 2010 11:09:11 -0400 From: Boris Kochergin <spawk@acm.poly.edu> To: freebsd-geom@freebsd.org Subject: Re: Switchover to CAM ATA? Message-ID: <4BF2AD97.4010100@acm.poly.edu> In-Reply-To: <31A502A0-DB53-4677-BF92-6DD826ED449C@samsco.org> References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> <1272367989.97887.47.camel@buffy.york.ac.uk> <31A502A0-DB53-4677-BF92-6DD826ED449C@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long wrote: > 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 > I am thinking about trying to reimplement some ataraid stuff using GEOM as a summer programming exercise. Browsing the ataraid code, I notice that it tends to check both the PCI ID of the controller a disk is connected to, and a magic string identifying vendor-specific metadata belonging to the vendor of the controller. This leads me to believe that a lot of the pseudo-RAID formats can be used in GEOM without any knowledge of the controller type. Sure, some CPU time would be wasted tasting all the supported formats in this manner, but it seems negligible given the frequency at which it would occur. I suppose there is also the unlikely chance that non-metadata information happens to live at the same location the metadata would, and the PCI ID check in the ataraid code is used to reduce that possibility, but it seems like additional sanity checking of RAID parameters following the magic string would alleviate this. Thoughts? Also, has there been any progress in making PCI ID information available to GEOM cleanly? -Boris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BF2AD97.4010100>