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).
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
