Switchover to CAM ATA?

[Boris Kochergin]

Andriy Gapon wrote:
> on 18/05/2010 18:09 Boris Kochergin said the following:
>   
>> 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.
>>     
>
> Just keep in mind the case when an HDD was used with a controller from one
> vendor and then moved to a different system with a different controller.
> So, pseudo-RAID label on disk may be different from actual pseudo-RAID hardware.
>   
Yeah, that might make life tricky. Alexander Motin told me off-list that 
he could make PCI information available to GEOM for me, and I cheerfully 
accepted. In the meantime, in my GEOM module's .init function, I am 
taking down the chip IDs of all PCI devices in the PCIC_STORAGE class 
and PCIS_STORAGE_RAID subclass, along with their children (disks), so 
that the .taste function has access to PCI information when tasting a 
disk. This may stink of layer pollution, but I am structuring my code in 
such a way that makes it easy to switch to getting PCI information from 
GEOM when the functionality becomes available.

-Boris