From owner-freebsd-stable@FreeBSD.ORG Mon Nov 7 13:17:40 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 6272C106566C for ; Mon, 7 Nov 2011 13:17:40 +0000 (UTC) (envelope-from ml@os2.kiev.ua) Received: from s1.sdv.com.ua (s1.sdv.com.ua [77.120.97.61]) by mx1.freebsd.org (Postfix) with ESMTP id 0AEA38FC0A for ; Mon, 7 Nov 2011 13:17:39 +0000 (UTC) Received: from 80-105-243-80.cust.centrio.cz ([80.243.105.80] helo=[192.168.101.100]) by s1.sdv.com.ua with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RNP4s-000FrL-EQ; Mon, 07 Nov 2011 15:17:36 +0200 Message-ID: <4EB7DA61.2030403@os2.kiev.ua> Date: Mon, 07 Nov 2011 14:17:21 +0100 From: Alex Samorukov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jeremy Chadwick References: <4EB307CC.8000705@os2.kiev.ua> <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> In-Reply-To: <20111107130612.GA2298@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Score: -1.0 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 13:17:40 -0000 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. > 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).