Re: Weird CAM-ATA behaviour (8.0-RC1): disk cloning

On Oct 31, 2009, at 1:39 AM, Alexander Motin wrote:

> Alexander Motin wrote:
>> Kamigishi Rei wrote:
>>> I just noticed something weird in my device list (actually, I  
>>> noticed it
>>> in "glabel status" output, but then confirmed via camcontrol  
>>> devlist): I
>>> got a 7th HDD, ada6, which is, surprisingly, ada0.
>>>
>>> This is how it appeared (I've checked the logs):
>>>
>>> Oct 27 01:26:38 ameagari sudo: fujibayashi : TTY=pts/3 ;
>>> PWD=/usr/home/fujibayashi ; USER=root ; COMMAND=/sbin/camcontrol  
>>> rescan
>>> 0:0:1
>>> Oct 27 01:26:38 ameagari kernel: (aprobe0:ahcich0:0:0:1):  
>>> SIGNATURE: 0000
>>> Oct 27 01:26:38 ameagari kernel: ada6 at ahcich0 bus 0 target 0  
>>> lun 1
>>> Oct 27 01:26:38 ameagari kernel: ada6: <ST3500320AS SD15> ATA/ 
>>> ATAPI-8
>>> SATA 2.x device
>>> Oct 27 01:26:38 ameagari kernel: ada6: 300.000MB/s transfers
>>> Oct 27 01:26:38 ameagari kernel: ada6: 476940MB (976773168 512 byte
>>> sectors: 16H 63S/T 16383C)
>>> Oct 27 01:26:38 ameagari kernel: ada6: Native Command Queueing  
>>> enabled
>>> Oct 27 01:26:38 ameagari kernel: GEOM_MIRROR: Cannot add disk ada6  
>>> to
>>> gm0 (error=17).
>>>
>>> While I know I made a mistake there (specifying 0:0:1 instead of  
>>> 1:0:0),
>>> is this behaviour really correct? I don't see why we should add a
>>> 'cloned' disk device on a rescan of LUNs that do not really exist  
>>> in the
>>> first place.
>>>
>>> This is repeatable and I can create as many clones as I want (by  
>>> doing
>>> "camcontrol rescan X:Y:Z" where Y and Z can vary and X is the AHCI  
>>> bus
>>> number):
>>
>> Interesting effect.
>
> By the way it is not an ATA-specific problem. Here is ahc SCSI:
>
> %camcontrol devlist
> <HP HP35470A T503>                at scbus0 target 1 lun 0 (sa0,pass0)
> <HP HP35470A T503>                at scbus0 target 1 lun 256  
> (pass3,sa2)
> <HP HP35470A T503>                at scbus0 target 17 lun 0  
> (pass2,sa1)
>

It's not finding these on it's own is, it?  Rather, you're forcing it  
to scan a particular bus:target:lun, yes?  The problem here isn't that  
it's seeing phantom devices, it's that you're overflowing the ranges  
for the fields and getting wrap-around.  I don't know if the SIM or  
the XPT should be doing the range checking, and I don't know if  
checking was done in the past but is now broken.  I can't say that  
this problem is the same ATA.

Scott