smartctl / mpt on 9.0-RC1

[Alex Samorukov]

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).