Date: Sat, 31 Oct 2009 09:01:27 -0600 From: Scott Long <scottl@samsco.org> To: Alexander Motin <mav@freebsd.org> Cc: Scott Long <scottl@freebsd.org>, FreeBSD-Current <freebsd-current@freebsd.org> Subject: Re: Weird CAM-ATA behaviour (8.0-RC1): disk cloning Message-ID: <A4FB65CB-88C2-440B-8275-902DDC22690A@samsco.org> In-Reply-To: <4AEBE9B6.6050007@FreeBSD.org> References: <mailpost.1256930478.6849797.1624.mailing.freebsd.current@FreeBSD.cs.nctu.edu.tw> <4AEBDDF8.8060609@FreeBSD.org> <4AEBE9B6.6050007@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A4FB65CB-88C2-440B-8275-902DDC22690A>