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

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.

CAM ATA implementation doesn't use LUNs, in fact it ignores them. Also
you may scan PMP port's target IDs when not PMP present with alike
effect, as without PMP present nobody handles FIS port field. Probably
we need some per-bus local storage (at SIM or may be XPT) to keep
device's current status, reported by PMP driver.

Thank you.

-- 
Alexander Motin