smartctl / mpt on 9.0-RC1

[Jeremy Chadwick]

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 |