From owner-freebsd-stable@FreeBSD.ORG Mon Nov 7 14:11:53 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B5171065672 for ; Mon, 7 Nov 2011 14:11:53 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 6D0F58FC18 for ; Mon, 7 Nov 2011 14:11:53 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta09.emeryville.ca.mail.comcast.net with comcast id uDbs1h00C1eYJf8A9EAE2U; Mon, 07 Nov 2011 14:10:14 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta19.emeryville.ca.mail.comcast.net with comcast id uDyT1h01U1t3BNj01DyUKM; Mon, 07 Nov 2011 13:58:44 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 16C56102C1D; Mon, 7 Nov 2011 06:10:04 -0800 (PST) Date: Mon, 7 Nov 2011 06:10:04 -0800 From: Jeremy Chadwick To: Alex Samorukov Message-ID: <20111107141004.GA3377@icarus.home.lan> References: <4EB6AD22.4080408@ksu.ru> <4EB6B20A.9090104@os2.kiev.ua> <4EB6B530.9000901@ksu.ru> <4EB6F004.9060501@os2.kiev.ua> <4EB6FABF.6060401@os2.kiev.ua> <4EB7BFD3.3040606@ksu.ru> <20111107114231.GA11028@icarus.home.lan> <4EB7D4D0.9080905@ksu.ru> <20111107130612.GA2298@icarus.home.lan> <4EB7DA61.2030403@os2.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EB7DA61.2030403@os2.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Marat N.Afanasyev" , FreeBSD Stable Mailing List Subject: Re: smartctl / mpt on 9.0-RC1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 14:11:53 -0000 On Mon, Nov 07, 2011 at 02:17:21PM +0100, Alex Samorukov wrote: > On 11/07/2011 02:06 PM, Jeremy Chadwick wrote: > >On Mon, Nov 07, 2011 at 04:53:36PM +0400, Marat N.Afanasyev wrote: > >>>>btw, 3dm can tell about reallocated sector count on sas somehow, > >>>>while smartctl cannot, even on supported controller :( > >>>I think this is getting into a separate discussion topic. > >>> > >>>I realise we're discussing SAS, but what's shown above looks pure and > >>>total SCSI output from smartmontools. I'm very familiar with it (we > >>>predominantly used SCSI disks at my workplace up until ~1 year ago). > >>> > >>I will be satisfied with scsi-like output of smartctl for my sas > >>drive on twa controller ;) > >Did you actually look at the output I provided? It's more or less the > >same, minus data which you want that isn't being shown (at all). That > >includes things like drive manufacturing date, etc.. > > > >The problem could be in one of the following layers: > > > >1. smartmontools itself > Hi Jeremy, > > It is "smartmontools itself" problem. On twa (3ware devices) we are > using ATA-type of packets to speak with the device. It is fine for > ATA/SATA disks, but not for SATA, which are using SCSI commands. The > code for the SCSI conversation just needs to be written (btw, the > same on Linux). Driver itself provides TWA_FW_CMD_EXECUTE_SCSI type > of the packet, so it probably (!) possible to speak with underlying > disks using it, but it needs to be tested. The problem is that i > have no such controllers or drives. I could try to add this > functionality if anyone will provide me access, but it should not be > production system with any important data. E.g. when i was working > on LSI code i had array degradations and controller hangs on > legitimate SAT commands. I see. I wasn't aware there was an ioctl(2) interface to twa(4). This makes me wonder: why does Marat use /dev/passX as his device when using smartctl? Could this have some bearing on why he doesn't see the necessary data returned from (if even submit to) the underlying disk? The syntax of his command was: "smartctl -a /dev/pass1". I would have expected the syntax to be "smartctl -a -d 3ware,1 /dev/twa". What I'm trying to get at here is whether or not smartmontools "does the right thing" in this situation. Does the output differ between the above two syntaxes? I don't see any mention in twa(4)'s man page that pass(4) is even registered/used -- though I do see it mentioned that CAM is used by twa(4). Furthermore, later comments below indicate CAM isn't involved, which further confuses me. Can someone help relieve my confusion on this matter? > >2. CAM translation layer (e.g. pass(4) or related bits) > >3. twa(4) driver > > 2. is not in use, smartmontools using ioctl api to send commands to > firmware. 3. - under the question. > > >4. 3Ware controller firmware > > 4. Yes, needs to be tested. It is common to see bugs in firmware in > this area, it is not usually well tested (LSI with SAT protocol is a > good example, i did workaround for this in recent smartmontools > update). > > >It is possible to determine if #1 and #2 are responsible by enabling > >CAMDEBUG and/or using "camcontrol debug" to watch all CDBs which are > >submit to the controller. I'm not sure which one is responsible for > >obtaining defect counts and so on -- I would need to review SAS and/or > >SCSI specifications. The information should be available per > >T10's SCSI and SAS specification documents. > > > >An alternate way to check would be to boot into a Linux LiveCD and > >install smartmontools (in RAM) and see if it provides the data. > > It would not. Just because SCSI interface for this driver is not > implemented. > > >My point: don't be so quick to assume smartmontools is responsible when > >there are 4 (maybe even 5) "layers" to how SCSI I/O makes it to the > >actual drive. This is one of the many reasons I try to avoid hardware > >RAID controllers -- too much crap between me and the device I wish to > >speak to. > > Its controversy statement. From my own point of view - device > authors should implement passX devices for the disks like it done on > mfip.ko or with Adaptec (at least on Linux). Yes, agreed. But there are also some cards which register with pass(4) but don't pass raw CDBs to the disk spoken to -- meaning, the firmware itself is actually mangling/filtering CDBs. So even though it's a matter of opinion/controversy, the fact of the matter is that with these types of cards cards (not picking on 3Ware here specifically), there are so many layers of abstraction that figuring out which piece (meaning which item of the above 4 items I provided) is responsible is very difficult. From the end-user perspective, it's as simple as "it doesn't work"; from the developer's perspective, it's time-consuming and annoying. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |