Re: SATA Drive Information (vs hdparm -i)?

Re: SATA Drive Information (vs hdparm -i)?

[Douglas Gilbert]

Richard Bollinger wrote:
> Is there a program for SATA drives which reveals the depth of
> information that "hdparm -i" does for IDE drives?  sdparm reveals
> almost nothing in comparison:
> 
> # sdparm -i /dev/sda
>     /dev/sda: ATA       WDC WD3200JD-00K  08.0
> Device identification VPD page:
>   Addressed logical unit:
>     id_type: vendor specific [0x0],  code_set: ASCII
>  00     4c 69 6e 75 78 20 41 54  41 2d 53 43 53 49 20 73    Linux ATA-SCSI s
>  10     69 6d 75 6c 61 74 6f 72                             imulator

Richard,
libata needs to improve the information it provides for
the Device Identification VPD page [0x83]. For example
as defined in section 10.3.4.2 in the just released sat-r06 .
Something approaching a world wide unique identifier is
needed.

> # hdparm -i /dev/hda
> 
> /dev/hda:
> 
>  Model=WDC WD800BB-00JHC0, FwRev=05.01C05, SerialNo=WD-MAM96054404
>  Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs mtGapReq }
>  RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=66
>  BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=off
>  CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=156301488
>  IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
>  PIO modes: pio0 pio3 pio4
>  DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
>  AdvancedPM=no
>  Drive Supports : Reserved : ATA-1 ATA-2 ATA-3 ATA-4 ATA-5 ATA-6

However an improved "sdparm -i" is not what you seem to be
asking for. Most of the above information is derived from
the response to the IDENTIFY [PACKET] DEVICE ATA command.
There seems to be two options for providing this:
  1) libata to implement ioctls like HDIO_GET_IDENTITY
  2) libata to implement SCSI ATA Translation [SAT]
     facilities such as:
       a) the ATA Information VPD page
       b) SCSI ATA pass through commands
       c) MODE SELECT SCSI command

Option 1) is the simplest but it requires that the SAT layer
is on the host computer [as it is in the case of libata].
Hopefully external USB and Firewire storage enclosures will
be enhanced to support the [draft] SAT standard and in
that case the SAT layer will be in the enclosure. SATA
disks [and S-ATAPI devices] in a SAS fabric may either
tunnel through the SAS fabric [via SAS Tunnelling Protocol
[STP]] or have a SAT layer in the fabric [typically in the
enclosure holding the disks]. Only the STP route allows for
option 1) .

I have published some patches for 2 a) and 2 c) and someone
else has published some patches for 2 b). I am unaware
if any have been accepted into libata yet.

Option 2) still needs an application client to output
information like "hdparm -i". "sdparm --page=ai" will
do this at a lower level if 2) a is implemented in
libata. Another approach is to make the hdparm application
libata aware and issue [shock horror] SCSI commands :-)

hdparm has a "-Istdin" command line option which accepts
the raw (binary) IDENTIFY x DEVICE response. So
implementing option 2 a), using sg_inq, dd and finally
hdparm could do it. That is a bit convoluted.

Doug Gilbert

Re: SATA Drive Information (vs hdparm -i)?

[Randy.Dunlap]

On Fri, 23 Sep 2005, Douglas Gilbert wrote:

> Richard Bollinger wrote:
> > Is there a program for SATA drives which reveals the depth of
> > information that "hdparm -i" does for IDE drives?  sdparm reveals
> > almost nothing in comparison:
> >
> > # sdparm -i /dev/sda
> >     /dev/sda: ATA       WDC WD3200JD-00K  08.0
> > Device identification VPD page:
> >   Addressed logical unit:
> >     id_type: vendor specific [0x0],  code_set: ASCII
> >  00     4c 69 6e 75 78 20 41 54  41 2d 53 43 53 49 20 73    Linux ATA-SCSI s
> >  10     69 6d 75 6c 61 74 6f 72                             imulator
>
> Richard,
> libata needs to improve the information it provides for
> the Device Identification VPD page [0x83]. For example
> as defined in section 10.3.4.2 in the just released sat-r06 .
> Something approaching a world wide unique identifier is
> needed.
>
> > # hdparm -i /dev/hda
> >
> > /dev/hda:
> >
> >  Model=WDC WD800BB-00JHC0, FwRev=05.01C05, SerialNo=WD-MAM96054404
> >  Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs mtGapReq }
> >  RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=66
> >  BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=off
> >  CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=156301488
> >  IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
> >  PIO modes: pio0 pio3 pio4
> >  DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
> >  AdvancedPM=no
> >  Drive Supports : Reserved : ATA-1 ATA-2 ATA-3 ATA-4 ATA-5 ATA-6
>
> However an improved "sdparm -i" is not what you seem to be
> asking for. Most of the above information is derived from
> the response to the IDENTIFY [PACKET] DEVICE ATA command.
> There seems to be two options for providing this:
>   1) libata to implement ioctls like HDIO_GET_IDENTITY
>   2) libata to implement SCSI ATA Translation [SAT]
>      facilities such as:
>        a) the ATA Information VPD page
>        b) SCSI ATA pass through commands
>        c) MODE SELECT SCSI command
>
> Option 1) is the simplest but it requires that the SAT layer
> is on the host computer [as it is in the case of libata].
> Hopefully external USB and Firewire storage enclosures will
> be enhanced to support the [draft] SAT standard and in
> that case the SAT layer will be in the enclosure. SATA
> disks [and S-ATAPI devices] in a SAS fabric may either
> tunnel through the SAS fabric [via SAS Tunnelling Protocol
> [STP]] or have a SAT layer in the fabric [typically in the
> enclosure holding the disks]. Only the STP route allows for
> option 1) .
>
> I have published some patches for 2 a) and 2 c) and someone
> else has published some patches for 2 b). I am unaware
> if any have been accepted into libata yet.
>
> Option 2) still needs an application client to output
> information like "hdparm -i". "sdparm --page=ai" will
> do this at a lower level if 2) a is implemented in
> libata. Another approach is to make the hdparm application
> libata aware and issue [shock horror] SCSI commands :-)
>
> hdparm has a "-Istdin" command line option which accepts
> the raw (binary) IDENTIFY x DEVICE response. So
> implementing option 2 a), using sg_inq, dd and finally
> hdparm could do it. That is a bit convoluted.

Jeff also has 'blktool' that may be useful.
Latest available afaik is at sf.net/projects/gkernel .

sample output on my SATA /dev/sda:

# ./blktool /dev/sda id
scsi-version: 5
vendor-id: ATA
product-id: ST3160023AS
product-rev: 3.00
device-type: direct-access
sectors: 312581808
sector-size: 512
#
-- 
~Randy

Re: SATA Drive Information (vs hdparm -i)?

[Richard Bollinger]

I'm specifically looking for something that will reveal the serial
number of each SATA drive.

Re: SATA Drive Information (vs hdparm -i)?

[Douglas Gilbert]

Randy.Dunlap wrote:
> On Fri, 23 Sep 2005, Douglas Gilbert wrote:
> 
> 
>>Richard Bollinger wrote:
>>
>>>Is there a program for SATA drives which reveals the depth of
>>>information that "hdparm -i" does for IDE drives?  sdparm reveals
>>>almost nothing in comparison:
>>>
>>># sdparm -i /dev/sda
>>>    /dev/sda: ATA       WDC WD3200JD-00K  08.0
>>>Device identification VPD page:
>>>  Addressed logical unit:
>>>    id_type: vendor specific [0x0],  code_set: ASCII
>>> 00     4c 69 6e 75 78 20 41 54  41 2d 53 43 53 49 20 73    Linux ATA-SCSI s
>>> 10     69 6d 75 6c 61 74 6f 72                             imulator
>>
>>Richard,
>>libata needs to improve the information it provides for
>>the Device Identification VPD page [0x83]. For example
>>as defined in section 10.3.4.2 in the just released sat-r06 .
>>Something approaching a world wide unique identifier is
>>needed.
>>
>>
>>># hdparm -i /dev/hda
>>>
>>>/dev/hda:
>>>
>>> Model=WDC WD800BB-00JHC0, FwRev=05.01C05, SerialNo=WD-MAM96054404
>>> Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs mtGapReq }
>>> RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=66
>>> BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=off
>>> CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=156301488
>>> IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
>>> PIO modes: pio0 pio3 pio4
>>> DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
>>> AdvancedPM=no
>>> Drive Supports : Reserved : ATA-1 ATA-2 ATA-3 ATA-4 ATA-5 ATA-6
>>
>>However an improved "sdparm -i" is not what you seem to be
>>asking for. Most of the above information is derived from
>>the response to the IDENTIFY [PACKET] DEVICE ATA command.
>>There seems to be two options for providing this:
>>  1) libata to implement ioctls like HDIO_GET_IDENTITY
>>  2) libata to implement SCSI ATA Translation [SAT]
>>     facilities such as:
>>       a) the ATA Information VPD page
>>       b) SCSI ATA pass through commands
>>       c) MODE SELECT SCSI command
>>
>>Option 1) is the simplest but it requires that the SAT layer
>>is on the host computer [as it is in the case of libata].
>>Hopefully external USB and Firewire storage enclosures will
>>be enhanced to support the [draft] SAT standard and in
>>that case the SAT layer will be in the enclosure. SATA
>>disks [and S-ATAPI devices] in a SAS fabric may either
>>tunnel through the SAS fabric [via SAS Tunnelling Protocol
>>[STP]] or have a SAT layer in the fabric [typically in the
>>enclosure holding the disks]. Only the STP route allows for
>>option 1) .
>>
>>I have published some patches for 2 a) and 2 c) and someone
>>else has published some patches for 2 b). I am unaware
>>if any have been accepted into libata yet.
>>
>>Option 2) still needs an application client to output
>>information like "hdparm -i". "sdparm --page=ai" will
>>do this at a lower level if 2) a is implemented in
>>libata. Another approach is to make the hdparm application
>>libata aware and issue [shock horror] SCSI commands :-)
>>
>>hdparm has a "-Istdin" command line option which accepts
>>the raw (binary) IDENTIFY x DEVICE response. So
>>implementing option 2 a), using sg_inq, dd and finally
>>hdparm could do it. That is a bit convoluted.
> 
> 
> Jeff also has 'blktool' that may be useful.
> Latest available afaik is at sf.net/projects/gkernel .
> 
> sample output on my SATA /dev/sda:
> 
> # ./blktool /dev/sda id
> scsi-version: 5
> vendor-id: ATA
> product-id: ST3160023AS
> product-rev: 3.00
> device-type: direct-access
> sectors: 312581808
> sector-size: 512
> #

Randy,
Thanks for reminding me about blktool.

blktool's information is derived from a SCSI INQUIRY
command (and a READ CAPACITY command). sg3_utils's
"sg_inq /dev/sda" will give something similar.
For SATA disks this is a subset of the information
provided by the IDENTIFY DEVICE ATA command.

A "standard" SCSI INQUIRY responds with 36 bytes of
information (although the associated VPD pages,
when implemented, provide a lot more information) while
the IDENTIFY DEVICE ATA command responds with 512 bytes
of information.

My guess is that Richard is interested in the transport
specific information shown in "hdparm -i".

Doug Gilbert

Re: SATA Drive Information (vs hdparm -i)?

[Douglas Gilbert]

Richard Bollinger wrote:
> I'm specifically looking for something that will reveal the serial
> number of each SATA drive.

How does:
 sdparm --page=sn /dev/sda
look?

Doug Gilbert

Re: SATA Drive Information (vs hdparm -i)?

[Ric Wheeler]

Richard Bollinger wrote:

>I'm specifically looking for something that will reveal the serial
>number of each SATA drive.
>-
>To unsubscribe from this list: send the line "unsubscribe linux-ide" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>  
>
hdparm (modified to run against libata SCSI drives) does show the serial 
number:

[root@c001n01 root]# hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
        Model Number:       Maxtor 6B300S0
        Serial Number:      B60J1DTH
        Firmware Revision:  BANC1B70

Re: SATA Drive Information (vs hdparm -i)?

[Richard Bollinger]

Bingo:
# sdparm --page=sn /dev/sda
    /dev/sda: ATA       WDC WD3200JD-00K  08.0
Unit serial number VPD page:
       WD-WMAMR1316505

I'll have to look at the drives in the morning to be sure, but it
looks good to me.

Thanks!

On 9/22/05, Douglas Gilbert <dougg@torque.net> wrote:
> Richard Bollinger wrote:
> > I'm specifically looking for something that will reveal the serial
> > number of each SATA drive.
>
> How does:
>  sdparm --page=sn /dev/sda
> look?
>
> Doug Gilbert
>

Re: SATA Drive Information (vs hdparm -i)?

[Randy.Dunlap]

On Thu, 22 Sep 2005, Ric Wheeler wrote:

> Richard Bollinger wrote:
>
> >I'm specifically looking for something that will reveal the serial
> >number of each SATA drive.
> >-
> >
> hdparm (modified to run against libata SCSI drives) does show the serial
> number:
>
> [root@c001n01 root]# hdparm -I /dev/sda
>
> /dev/sda:
>
> ATA device, with non-removable media
>         Model Number:       Maxtor 6B300S0
>         Serial Number:      B60J1DTH
>         Firmware Revision:  BANC1B70

and where is that patch?...

-- 
~Randy

Re: SATA Drive Information (vs hdparm -i)?

[Ric Wheeler]

Randy.Dunlap wrote:

>On Thu, 22 Sep 2005, Ric Wheeler wrote:
>
>  
>
>>Richard Bollinger wrote:
>>
>>    
>>
>>>I'm specifically looking for something that will reveal the serial
>>>number of each SATA drive.
>>>-
>>>
>>>      
>>>
>>hdparm (modified to run against libata SCSI drives) does show the serial
>>number:
>>
>>[root@c001n01 root]# hdparm -I /dev/sda
>>
>>/dev/sda:
>>
>>ATA device, with non-removable media
>>        Model Number:       Maxtor 6B300S0
>>        Serial Number:      B60J1DTH
>>        Firmware Revision:  BANC1B70
>>    
>>
>
>and where is that patch?...
>
>  
>
If you look at the hdparm homepage 
(http://freshmeat.net/projects/hdparm/)  you will see a thread on this - 
you need a kernel that supports libata passthru,

ric

Re: SATA Drive Information (vs hdparm -i)?

[Mark Lord]

The current hdparm release does "-i" and "-I" out of the box,
along with many other "-[A-Z]" options,
assuming your kernel has the widely used libata "passthru" patch applied.

Since libata is in-theory to be decoupled from the SCSI layer at some point,
it might be unwise to rely on emulated SCSI commands for detailed SATA info.

Cheers

Re: SATA Drive Information (vs hdparm -i)?

[Luben Tuikov]

On 09/22/05 20:23, Douglas Gilbert wrote:
> However an improved "sdparm -i" is not what you seem to be
> asking for. Most of the above information is derived from
> the response to the IDENTIFY [PACKET] DEVICE ATA command.
> There seems to be two options for providing this:
>   1) libata to implement ioctls like HDIO_GET_IDENTITY
>   2) libata to implement SCSI ATA Translation [SAT]
>      facilities such as:
>        a) the ATA Information VPD page
>        b) SCSI ATA pass through commands
>        c) MODE SELECT SCSI command
> 
> Option 1) is the simplest but it requires that the SAT layer
> is on the host computer [as it is in the case of libata].
> Hopefully external USB and Firewire storage enclosures will
> be enhanced to support the [draft] SAT standard and in
> that case the SAT layer will be in the enclosure. SATA
> disks [and S-ATAPI devices] in a SAS fabric may either
> tunnel through the SAS fabric [via SAS Tunnelling Protocol
> [STP]] or have a SAT layer in the fabric [typically in the
> enclosure holding the disks].

There will be no SAT layer in a SAS fabric.  STP is just
that, a _tunneling_ protocol.  Thus, either in Option 1,
or Option 2 if you want to present the device to
SCSI Core as a SCSI Device you need SAT somewhere below
SCSI Core (on the host).

In general, lower (hardware) layers want to do the
_absolute_ minimum as far as their function is concerned.

Thus, for example, you can expect an incomplete
USB/IEEE1394 SAT layer on the device.

> Only the STP route allows for option 1) .

Option 2 as well: you'll just treat the device as
SCSI and SAT will emulate as much as possible.

	Luben

Re: SATA Drive Information (vs hdparm -i)?

[Douglas Gilbert]

Luben Tuikov wrote:
> On 09/22/05 20:23, Douglas Gilbert wrote:
> 
>>However an improved "sdparm -i" is not what you seem to be
>>asking for. Most of the above information is derived from
>>the response to the IDENTIFY [PACKET] DEVICE ATA command.
>>There seems to be two options for providing this:
>>  1) libata to implement ioctls like HDIO_GET_IDENTITY
>>  2) libata to implement SCSI ATA Translation [SAT]
>>     facilities such as:
>>       a) the ATA Information VPD page
>>       b) SCSI ATA pass through commands
>>       c) MODE SELECT SCSI command
>>
>>Option 1) is the simplest but it requires that the SAT layer
>>is on the host computer [as it is in the case of libata].
>>Hopefully external USB and Firewire storage enclosures will
>>be enhanced to support the [draft] SAT standard and in
>>that case the SAT layer will be in the enclosure. SATA
>>disks [and S-ATAPI devices] in a SAS fabric may either
>>tunnel through the SAS fabric [via SAS Tunnelling Protocol
>>[STP]] or have a SAT layer in the fabric [typically in the
>>enclosure holding the disks].
> 
> 
> There will be no SAT layer in a SAS fabric.  STP is just
> that, a _tunneling_ protocol.  Thus, either in Option 1,
> or Option 2 if you want to present the device to
> SCSI Core as a SCSI Device you need SAT somewhere below
> SCSI Core (on the host).

Luben,
The folks at HP, Intel and WDC seemingly driving the
SAT draft write in the overview [in sat-r06 section 5.1]
of the SAT layer (SATL):

"Examples of SATL implemented in accordance to this
standard include:
   a) a SATL contained within a SCSI target ...
   b) An ATA/ATAPI Host Bus Adapter (HBA) directly
      connected to ATA/ATAPI devices ...
   c) A SAS STP initiator port to connect ATA/ATAPI
      devices ...
"

There are figures (diagrams) of these three later in
the draft: figure 7 (page 81), figure 5 (page 79) and
figure 6 (page 80) respectively.

For point a) they give as examples FCP, SPI and SBP-3
(but not SAS). One reason for putting a SAT layer in
a SAS target is multi-initiator and mult-port command
queuing support (sat-r05 section 6.2.4). Converting
port multipliers to luns may also be useful. [Perhaps
you could confirm this: a 1.5 GB SATA disk chews up
3 GB of SAS bandwidth when doing STP data transfers
(thanks to ALIGNs inserted every other word).] A RAID
of SATA disks in a SAS target (enclosure) would be
another candidate for a SAT layer (with luns > 0 to
access the individual disks (e.g. for SMART diagnostics)).

> In general, lower (hardware) layers want to do the
> _absolute_ minimum as far as their function is concerned.

Some folks have reported beta testing disks that, via
firmware download, can change between having a SATA and
a SAS interface. So I think that what you say is
basically true, but intelligence is being distributed
as well. "Nice to have" features like SMART in disks
must consume a lot of firmware (and flash) but support
(and standard's compliance) seems to be improving.

> Thus, for example, you can expect an incomplete
> USB/IEEE1394 SAT layer on the device.

Yep. Judging from my mail, lots of these users would
be happy with START STOP UNIT (well, at least as a
start).

>>Only the STP route allows for option 1) .
> 
> 
> Option 2 as well: you'll just treat the device as
> SCSI and SAT will emulate as much as possible.

True; point c) from the SAT overview.

Doug Gilbert

Re: SATA Drive Information (vs hdparm -i)?

[Luben Tuikov]

--- Douglas Gilbert <dougg@torque.net> wrote:
> Luben,
> The folks at HP, Intel and WDC seemingly driving the
> SAT draft write in the overview [in sat-r06 section 5.1]
> of the SAT layer (SATL):
> 
> "Examples of SATL implemented in accordance to this
> standard include:
>    a) a SATL contained within a SCSI target ...
>    b) An ATA/ATAPI Host Bus Adapter (HBA) directly
>       connected to ATA/ATAPI devices ...
>    c) A SAS STP initiator port to connect ATA/ATAPI
>       devices ...
> "

Hi Doug,

c) which you quoted: "STP _initiator_ port".
a) refers to FC (very relevant).
In b) you have directly attached ATA devices (to an HBA).

> There are figures (diagrams) of these three later in
> the draft: figure 7 (page 81), figure 5 (page 79) and
> figure 6 (page 80) respectively.

Yes, and figure 6 clearly shows SATL _at_ the _initiator_
port _before_ the STP link.

Figure 7 does indeed point to SATL at the Target port
but the transport is pointed out to be _FC_.

> For point a) they give as examples FCP, SPI and SBP-3
> (but not SAS). One reason for putting a SAT layer in
> a SAS target is multi-initiator and mult-port command
> queuing support (sat-r05 section 6.2.4). Converting
> port multipliers to luns may also be useful

Yes, this is true. (In general I cannot see how we'd
disagree if we read the same document(s).)

_But_, from a _business_ point of view it would be cheaper
to just use STP, as opposed to implement SATL at the
target _and_ use SAS as a transport.(*)

In case of multi-initiator access, one can use Affiliations.
(Issued, of course, at the transaction layer (filesystem).)

(*) Well, that's not necessarily true, since you can
market a SATA+SATL device as SAS device... Not sure
about the margin profit, but there ought to
be a law against that. ;-)

> [Perhaps
> you could confirm this: a 1.5 GB SATA disk chews up
> 3 GB of SAS bandwidth when doing STP data transfers
> (thanks to ALIGNs inserted every other word).]

Over an expander to which you have a G2 connection, yes.

> A RAID
> of SATA disks in a SAS target (enclosure) would be
> another candidate for a SAT layer (with luns > 0 to
> access the individual disks (e.g. for SMART diagnostics)).

_RAID_devices_, not ATA devices.

Yes, in general RAID have so much more freedom like
wide ports, etc, so they'd be expected to do tricks
like this.  Everything behind a RAID device would be
highly vendor specific (and "magical" :-) ).

> Some folks have reported beta testing disks that, via
> firmware download, can change between having a SATA and
> a SAS interface. So I think that what you say is
> basically true, but intelligence is being distributed

Would you buy a SAS hard disk which you know that
firmware can make it SATA?  Would you buy a SATA
hard disk which you know firmware can make it SAS?
How much would you pay for the latter? :-)

    Luben