Is there a reliable way to ID a SSD?

Is there a reliable way to ID a SSD?

[Greg Freemyer]

All,

Per T13/1699-D Revision 4a (from May 2007) word 217 of the identify
block should be populated with a "1" to identify non-rotating media.

http://www.t13.org/Documents/UploadedDocuments/docs2007/D1699r4a-ATA8-ACS.pdf

Does anyone know if that is a reliable field?

Specifically there are two separate issues:

1) Are all devices reporting a 1 in field 217 non-rotating?
2) Are all production non-rotating devices populating that field with a 1.

Is there some other reliable mechanism for identifying a SSD?


-- 
Greg Freemyer
Head of EDD Tape Extraction and Processing team
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
CNN/TruTV Aired Forensic Imaging Demo -
   http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retrieved/

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com

Re: Is there a reliable way to ID a SSD?

[Peter M. Petrakis]

Hi,

On 12/30/2010 10:58 AM, Greg Freemyer wrote:
> All,
> 
> Per T13/1699-D Revision 4a (from May 2007) word 217 of the identify
> block should be populated with a "1" to identify non-rotating media.
> 
> http://www.t13.org/Documents/UploadedDocuments/docs2007/D1699r4a-ATA8-ACS.pdf
> 
> Does anyone know if that is a reliable field?
> 
> Specifically there are two separate issues:
> 
> 1) Are all devices reporting a 1 in field 217 non-rotating?
> 2) Are all production non-rotating devices populating that field with a 1.
> 
> Is there some other reliable mechanism for identifying a SSD?
> 

Not really, the manufacturer needs to adhere to the spec they're claiming
to honor and we should politely notify them when we find that it's inconsistent.
It's technically a firmware bug if it's ATA-8 and that bit isn't set right.

If you're having trouble identifying SSDs pre ATA-8, you can use this simple
patch I introduced a while back.

http://www.spinics.net/lists/linux-ide/msg38944.html

and blacklist the offending drive into reporting itself as SSD when interrogated
via SCSI.

If you search around, you'll find an earlier thread about quirking SSDs by using
heuristics like search for the word "flash" in the device name and other hints but
the patch set never went anywhere. It's a ugly problem, there's so many devices
out there ahead of the spec that are SSD, with no sure fire way to determine that
they really are. Supporting a full blacklist of them would turn libata-core.c into
a dumping ground for potentially 100s of pre ATA-8 storage devices. I don't think
anyone wants to maintain that.

Peter

Re: Is there a reliable way to ID a SSD?

[Greg Freemyer]

On Mon, Jan 3, 2011 at 2:30 PM, Peter M. Petrakis
<peter.petrakis@canonical.com> wrote:
> Hi,
>
> On 12/30/2010 10:58 AM, Greg Freemyer wrote:
>> All,
>>
>> Per T13/1699-D Revision 4a (from May 2007) word 217 of the identify
>> block should be populated with a "1" to identify non-rotating media.
>>
>> http://www.t13.org/Documents/UploadedDocuments/docs2007/D1699r4a-ATA8-ACS.pdf
>>
>> Does anyone know if that is a reliable field?
>>
>> Specifically there are two separate issues:
>>
>> 1) Are all devices reporting a 1 in field 217 non-rotating?
>> 2) Are all production non-rotating devices populating that field with a 1.
>>
>> Is there some other reliable mechanism for identifying a SSD?
>>
>
> Not really, the manufacturer needs to adhere to the spec they're claiming
> to honor and we should politely notify them when we find that it's inconsistent.
> It's technically a firmware bug if it's ATA-8 and that bit isn't set right.
>
> If you're having trouble identifying SSDs pre ATA-8, you can use this simple
> patch I introduced a while back.
>
> http://www.spinics.net/lists/linux-ide/msg38944.html
>
> and blacklist the offending drive into reporting itself as SSD when interrogated
> via SCSI.
>
> If you search around, you'll find an earlier thread about quirking SSDs by using
> heuristics like search for the word "flash" in the device name and other hints but
> the patch set never went anywhere. It's a ugly problem, there's so many devices
> out there ahead of the spec that are SSD, with no sure fire way to determine that
> they really are. Supporting a full blacklist of them would turn libata-core.c into
> a dumping ground for potentially 100s of pre ATA-8 storage devices. I don't think
> anyone wants to maintain that.
>
> Peter

Peter,

Thanks.  I have a client that needs to recognize SSDs from userspace
and I missed the ABI.

I was looking for the userspace ABI to be in /sys/block like the
topology stuff is, so I missed the userspace ABI and was confused.

Now that I've found in, I'm confused by ata_id_rotation_rate()
trusting the rotation_rate of 1 being valid for all ATA 7 and ATA 8
devices.

=== cut & paste from ata.h
static inline int ata_id_rotation_rate(const u16 *id)
{
        u16 val = id[217];
        if (ata_id_major_version(id) < 7 || val == 0 || val == 0xffff)
                return 0;

        if (val > 1 && val < 0x401)
                return 0;

        return val;
}
===

I thought rotational_rate set to 1 to indicate a SSD was only valid
for ATA8 devices?

I'll have to go back and read the older thread you talked about, but
is there a plan for ATA7 devices?  Is it in general to trust word 217,
or what.

If I find a SSD device that is not setting word 217 correctly, and I
want to get the kernel to address it correctly, should I just add to
your list and cause ATA_HORKAGE_NONROT to be set?

Or is the concern it will get unwieldy too fast if everyone used that list?

Thanks
Greg

Re: Is there a reliable way to ID a SSD?

[Peter M. Petrakis]

On 01/03/2011 04:24 PM, Greg Freemyer wrote:
> On Mon, Jan 3, 2011 at 2:30 PM, Peter M. Petrakis
> <peter.petrakis@canonical.com> wrote:
>> Hi,
>>
>> On 12/30/2010 10:58 AM, Greg Freemyer wrote:
>>> All,
>>>
>>> Per T13/1699-D Revision 4a (from May 2007) word 217 of the identify
>>> block should be populated with a "1" to identify non-rotating media.
>>>
>>> http://www.t13.org/Documents/UploadedDocuments/docs2007/D1699r4a-ATA8-ACS.pdf
>>>
>>> Does anyone know if that is a reliable field?
>>>
>>> Specifically there are two separate issues:
>>>
>>> 1) Are all devices reporting a 1 in field 217 non-rotating?
>>> 2) Are all production non-rotating devices populating that field with a 1.
>>>
>>> Is there some other reliable mechanism for identifying a SSD?
>>>
>>
>> Not really, the manufacturer needs to adhere to the spec they're claiming
>> to honor and we should politely notify them when we find that it's inconsistent.
>> It's technically a firmware bug if it's ATA-8 and that bit isn't set right.
>>
>> If you're having trouble identifying SSDs pre ATA-8, you can use this simple
>> patch I introduced a while back.
>>
>> http://www.spinics.net/lists/linux-ide/msg38944.html
>>
>> and blacklist the offending drive into reporting itself as SSD when interrogated
>> via SCSI.
>>
>> If you search around, you'll find an earlier thread about quirking SSDs by using
>> heuristics like search for the word "flash" in the device name and other hints but
>> the patch set never went anywhere. It's a ugly problem, there's so many devices
>> out there ahead of the spec that are SSD, with no sure fire way to determine that
>> they really are. Supporting a full blacklist of them would turn libata-core.c into
>> a dumping ground for potentially 100s of pre ATA-8 storage devices. I don't think
>> anyone wants to maintain that.
>>
>> Peter
> 
> Peter,
> 
> Thanks.  I have a client that needs to recognize SSDs from userspace
> and I missed the ABI.
> 
> I was looking for the userspace ABI to be in /sys/block like the
> topology stuff is, so I missed the userspace ABI and was confused.

Ah you mean /sys/block/sda/queue/rotational.

> Now that I've found in, I'm confused by ata_id_rotation_rate()
> trusting the rotation_rate of 1 being valid for all ATA 7 and ATA 8
> devices.
> 
> === cut & paste from ata.h
> static inline int ata_id_rotation_rate(const u16 *id)
> {
>         u16 val = id[217];
>         if (ata_id_major_version(id) < 7 || val == 0 || val == 0xffff)
>                 return 0;
> 
>         if (val > 1 && val < 0x401)
>                 return 0;
> 
>         return val;
> }
> ===

Hmm, that may be but that value still needs to be valid, meaning, it's
either 1, or it's an RPM value. What does your raw IDENTIFY DEVICE output
say? This code accomidates ATA-7 vendors who had current draft specs to
"do the right thing" with the reserved block.

> I thought rotational_rate set to 1 to indicate a SSD was only valid
> for ATA8 devices?

Strictly speaking yes.

> I'll have to go back and read the older thread you talked about, but
> is there a plan for ATA7 devices?  Is it in general to trust word 217,
> or what.

Good thing I keep notes:
http://marc.info/?l=linux-ide&m=126677421807814&w=2

As you can see, my trivial patch is loosely based off of it.

> If I find a SSD device that is not setting word 217 correctly, and I
> want to get the kernel to address it correctly, should I just add to
> your list and cause ATA_HORKAGE_NONROT to be set?

Yup, just add the device name as reported by IDENTIFY DEVICE to the list.
Then the rotational bit in sysfs should be set.

> Or is the concern it will get unwieldy too fast if everyone used that list?

If you look at my post, you'll note that no one ever commented on it, and I
got too busy to follow up. So I really don't know where the maintainers stand.
The speculation of unwieldy quirk table management is my own opinion, though
I'm sure it's on everyone's mind. I know I wouldn't want to be in that position.
Just look at the quirk tables the sound codec drivers have to put up with to
get an idea of the volume of devices libata would deal with if it officially
supported this quirk.

> Thanks
> Greg

Peter


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

Re: Is there a reliable way to ID a SSD?

[Greg Freemyer]

On Mon, Jan 3, 2011 at 5:03 PM, Peter M. Petrakis
<peter.petrakis@canonical.com> wrote:
<snip>
>> Thanks.  I have a client that needs to recognize SSDs from userspace
>> and I missed the ABI.
>>
>> I was looking for the userspace ABI to be in /sys/block like the
>> topology stuff is, so I missed the userspace ABI and was confused.
>
> Ah you mean /sys/block/sda/queue/rotational.

I missed that one.  Never thought to look in queue. :(

(I don't know what SSD has to do with queue, but okay.  Please don't
answer, I've read some of the discussion before and promptly forgot
it.)

In the mean time I've found the hdparm also looks at word 217 and
reports SSD devices.  It has apparently been doing that since v9.12 or
so.  (spring 2009).

My current concern is that the logic is slowly diverging between the
kernel 2.6.36 implementation and the hdparm v9.36 implementation.

Mark (added to cc),

Would it be better if hdparm looked at /sys/block/sda/queue/rotational
instead of just using word 217 of the identify block?

The current divergence is:

1) The kernel routine  ata_id_rotation_rate() (in ata.h) is only
trusting  word 217 if its ATA7 or higher.

http://lxr.linux.no/#linux+v2.6.36/include/linux/ata.h#L799

2) There have been a couple proposed kernel patches to libata-scsi.c
to quirk in a HORKAGE flag to set the rotation_rate to 1 (meaning SSD)
for some known devices.  I don't see those being ACKed yet, but if one
ever gets in, hdparm will diverge from the kernels info since its
going straight to the identify block for its info.

Or is queue_flag_set_unlocked(QUEUE_FLAG_NONROT, q) somehow setting
word 217 for future identify block usage by hdparm?  (I have no idea
what that call does.  It was in Bart's ATANG patch, but not Peter's.)

Bart's atang PATCH: http://marc.info/?l=linux-ide&m=126677421807814&w=2

Peter's patch: http://www.spinics.net/lists/linux-ide/msg38944.html

I hope one of the approaches goes in.  As I said I have a userspace
app that really needs to know if its talking to a  traditional
rotating device or a SSD, so I suspect we'll be sending in quirk
patches as we start lab testing devices.

Thanks
Greg

Re: Is there a reliable way to ID a SSD?

[Mark Lord]

On 11-01-03 05:50 PM, Greg Freemyer wrote:
>
> Would it be better if hdparm looked at /sys/block/sda/queue/rotational
> instead of just using word 217 of the identify block?
>
> The current divergence is:
>
> 1) The kernel routine  ata_id_rotation_rate() (in ata.h) is only
> trusting  word 217 if its ATA7 or higher.
>
> http://lxr.linux.no/#linux+v2.6.36/include/linux/ata.h#L799
>
> 2) There have been a couple proposed kernel patches to libata-scsi.c
> to quirk in a HORKAGE flag to set the rotation_rate to 1 (meaning SSD)
> for some known devices.  I don't see those being ACKed yet, but if one
> ever gets in, hdparm will diverge from the kernels info since its
> going straight to the identify block for its info.

That's what hdparm is for.  It reads only from the identify block
for most of the -I output, so that we (kernel developers) can see
exactly what the drive itself is reporting.

This reporting is what makes it useful, rather than simply parroting
whatever is already reported (or not) in /sys/

Cheers

Re: Is there a reliable way to ID a SSD?

[Greg Freemyer]

On Tue, Jan 4, 2011 at 10:47 AM, Mark Lord <kernel@teksavvy.com> wrote:
> On 11-01-03 05:50 PM, Greg Freemyer wrote:
>>
>> Would it be better if hdparm looked at /sys/block/sda/queue/rotational
>> instead of just using word 217 of the identify block?
>>
>> The current divergence is:
>>
>> 1) The kernel routine  ata_id_rotation_rate() (in ata.h) is only
>> trusting  word 217 if its ATA7 or higher.
>>
>> http://lxr.linux.no/#linux+v2.6.36/include/linux/ata.h#L799
>>
>> 2) There have been a couple proposed kernel patches to libata-scsi.c
>> to quirk in a HORKAGE flag to set the rotation_rate to 1 (meaning SSD)
>> for some known devices.  I don't see those being ACKed yet, but if one
>> ever gets in, hdparm will diverge from the kernels info since its
>> going straight to the identify block for its info.
>
> That's what hdparm is for.  It reads only from the identify block
> for most of the -I output, so that we (kernel developers) can see
> exactly what the drive itself is reporting.
>
> This reporting is what makes it useful, rather than simply parroting
> whatever is already reported (or not) in /sys/
>
> Cheers

Interesting to know.  Maybe the man page could be even more explicit about that.

ie. it currently says:

===
-I     Request identification info directly from the drive, which is
displayed in a new expanded format with considerably more detail than
with the older -i flag.

===

Maybe an additional sentence or two like::

---
This explicitly avoids all kernel quirk logic, thus -I is reporting
exactly what the drive reports and may not agree with other kernel
ABI's which are typically impacted by various kernel quirk logic.  In
some cases when decoding the Identify Block, it will decode and report
information regardless of the ATA  standard supported.
---

I gather that last sentence from the fact hdparm is decoding word 217
for all drives, even though it is not defined until ATA8, but glancing
at the source, in other situations it appears to take the ATA standard
for the drive into account during the identify block decoding.

Thanks
Greg

Re: Is there a reliable way to ID a SSD?

[Martin K. Petersen]

>>>>> "Greg" == Greg Freemyer <greg.freemyer@gmail.com> writes:

Greg> In the mean time I've found the hdparm also looks at word 217 and
Greg> reports SSD devices.  It has apparently been doing that since
Greg> v9.12 or so.  (spring 2009).

Yes. And the Linux kernel has had the sysfs parameter since 2.6.29 which
came out around the same time.


Greg> My current concern is that the logic is slowly diverging between
Greg> the kernel 2.6.36 implementation and the hdparm v9.36
Greg> implementation.

As Mark said: The whole point of hdparm is to talk directly to the
device. There never was convergence, nor should there be.


Greg> 1) The kernel routine ata_id_rotation_rate() (in ata.h) is only
Greg> trusting word 217 if its ATA7 or higher.

The standards bodies are glacially slow (ACS-2 still hasn't been
ratified, although it's close. Again. Maybe). Consequently most device
vendors "backport" features from the drafts. But obviously they can't
and won't report compliance with an unfinished standard.

There are plenty of SSD drives out there which claim ATA7 compliance and
which support word 217. The reason we have a version check in the first
place is to guard against legacy devices which have inadvertently put
garbage in word 217.

We have had the rotational flag in place for a couple of years and have
had very few reports about devices misrepresenting themselves. So I'm
not entirely convinced we need quirk handling for this. Your friendly
kernel developers already made sure the rotational flag can be
overridden from user space.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Is there a reliable way to ID a SSD?

[Jan Ceuleers]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

On 03/01/11 23:03, Peter M. Petrakis wrote:
> Ah you mean /sys/block/sda/queue/rotational.

A few data points:

- Four rotational disks in my server are correctly reported as such.

- The rotational disk in my laptop is as well.

- The Intel SSD in my set-top box is reported correctly as non-rotational.

- However, the CompactFlash card in my broadband router is incorrectly 
reported as rotational. I attach lshw for this system.

Cheers, Jan

[-- Attachment #2: lshw.txt --]
[-- Type: text/plain, Size: 10214 bytes --]

skr03
    description: Computer
    width: 32 bits
  *-core
       description: Motherboard
       physical id: 0
     *-memory
          description: System memory
          physical id: 0
          size: 497MiB
     *-cpu
          product: Geode(TM) Integrated Processor by AMD PCS
          vendor: Advanced Micro Devices [AMD]
          physical id: 1
          bus info: cpu@0
          version: 5.10.2
          size: 500MHz
          width: 32 bits
          capabilities: fpu fpu_exception wp de pse tsc msr cx8 pge cmov clflush mmx mmxext 3dnowext 3dnow up
        *-cache:0
             description: L1 cache
             physical id: 0
             size: 128KiB
        *-cache:1
             description: L2 cache
             physical id: 1
             size: 128KiB
     *-pci
          description: Host bridge
          product: CS5536 [Geode companion] Host Bridge
          vendor: Advanced Micro Devices [AMD]
          physical id: 100
          bus info: pci@0000:00:01.0
          version: 33
          width: 32 bits
          clock: 66MHz
          configuration: latency=248
        *-generic
             description: Entertainment encryption device
             product: Geode LX AES Security Block
             vendor: Advanced Micro Devices [AMD]
             physical id: 1.2
             bus info: pci@0000:00:01.2
             version: 00
             width: 32 bits
             clock: 66MHz
             capabilities: bus_master
             configuration: driver=Geode LX AES latency=0
             resources: irq:10 memory:a0000000-a0003fff
        *-network:0 DISABLED
             description: Ethernet interface
             product: VT6105M [Rhine-III]
             vendor: VIA Technologies, Inc.
             physical id: 6
             bus info: pci@0000:00:06.0
             logical name: eth0
             version: 96
             serial: 00:00:24:cc:96:90
             size: 10MB/s
             capacity: 100MB/s
             width: 32 bits
             clock: 33MHz
             capabilities: pm bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd autonegotiation
             configuration: autonegotiation=on broadcast=yes driver=via-rhine driverversion=1.4.3 duplex=half latency=176 link=no maxlatency=8 mingnt=3 multicast=yes port=MII speed=10MB/s
             resources: irq:11 ioport:e100(size=256) memory:a0004000-a00040ff
        *-network:1 DISABLED
             description: Ethernet interface
             product: VT6105M [Rhine-III]
             vendor: VIA Technologies, Inc.
             physical id: 7
             bus info: pci@0000:00:07.0
             logical name: eth1
             version: 96
             serial: 00:00:24:cc:96:91
             size: 10MB/s
             capacity: 100MB/s
             width: 32 bits
             clock: 33MHz
             capabilities: pm bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd autonegotiation
             configuration: autonegotiation=on broadcast=yes driver=via-rhine driverversion=1.4.3 duplex=half latency=176 link=no maxlatency=8 mingnt=3 multicast=yes port=MII speed=10MB/s
             resources: irq:5 ioport:e200(size=256) memory:a0004100-a00041ff
        *-network:2
             description: Ethernet interface
             product: VT6105M [Rhine-III]
             vendor: VIA Technologies, Inc.
             physical id: 8
             bus info: pci@0000:00:08.0
             logical name: eth2
             version: 96
             serial: 00:00:24:cc:96:92
             size: 10MB/s
             capacity: 100MB/s
             width: 32 bits
             clock: 33MHz
             capabilities: pm bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd autonegotiation
             configuration: autonegotiation=on broadcast=yes driver=via-rhine driverversion=1.4.3 duplex=half ip=10.20.0.1 latency=176 link=no maxlatency=8 mingnt=3 multicast=yes port=MII speed=10MB/s
             resources: irq:9 ioport:e300(size=256) memory:a0004200-a00042ff
        *-network:3
             description: Ethernet interface
             product: VT6105M [Rhine-III]
             vendor: VIA Technologies, Inc.
             physical id: 9
             bus info: pci@0000:00:09.0
             logical name: eth3
             version: 96
             serial: 00:00:24:cc:96:93
             size: 100MB/s
             capacity: 100MB/s
             width: 32 bits
             clock: 33MHz
             capabilities: pm bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd autonegotiation
             configuration: autonegotiation=on broadcast=yes driver=via-rhine driverversion=1.4.3 duplex=full latency=176 link=yes maxlatency=8 mingnt=3 multicast=yes port=MII speed=100MB/s
             resources: irq:12 ioport:e400(size=256) memory:a0004300-a00043ff
        *-network:4
             description: Ethernet interface
             product: RTL-8139/8139C/8139C+
             vendor: Realtek Semiconductor Co., Ltd.
             physical id: e
             bus info: pci@0000:00:0e.0
             logical name: eth4
             version: 20
             serial: 00:0a:fa:30:00:a4
             size: 100MB/s
             capacity: 100MB/s
             width: 32 bits
             clock: 33MHz
             capabilities: pm bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd autonegotiation
             configuration: autonegotiation=on broadcast=yes driver=8139cp driverversion=1.3 duplex=full latency=176 link=yes maxlatency=64 mingnt=32 multicast=yes port=MII promiscuous=yes speed=100MB/s
             resources: irq:10 ioport:e500(size=256) memory:a0004400-a00044ff
        *-network:5
             description: Wireless interface
             product: AR922X Wireless Network Adapter
             vendor: Atheros Communications Inc.
             physical id: 11
             bus info: pci@0000:00:11.0
             logical name: wlan0
             version: 01
             serial: 00:80:48:65:d8:48
             width: 32 bits
             clock: 66MHz
             capabilities: pm bus_master cap_list ethernet physical wireless logical
             configuration: broadcast=yes driver=ath9k latency=168 multicast=yes wireless=IEEE 802.11abgn
             resources: irq:15 memory:a0010000-a001ffff
        *-isa
             description: ISA bridge
             product: CS5536 [Geode companion] ISA
             vendor: Advanced Micro Devices [AMD]
             physical id: 14
             bus info: pci@0000:00:14.0
             version: 03
             width: 32 bits
             clock: 66MHz
             capabilities: isa
             configuration: latency=64
             resources: ioport:6000(size=8192) ioport:1400(size=256) ioport:1000(size=512)
        *-ide
             description: IDE interface
             product: CS5536 [Geode companion] IDE
             vendor: Advanced Micro Devices [AMD]
             physical id: 14.2
             bus info: pci@0000:00:14.2
             logical name: scsi0
             version: 01
             width: 32 bits
             clock: 66MHz
             capabilities: ide bus_master emulated
             configuration: driver=pata_amd latency=0
             resources: irq:0 ioport:1f0(size=8) ioport:3f6 ioport:170(size=8) ioport:376 ioport:e000(size=16)
           *-disk
                description: ATA Disk
                product: SanDisk SDCFH2-0
                physical id: 0.0.0
                bus info: scsi@0:0.0.0
                logical name: /dev/sda
                version: HDX
                serial: 014205J0808G1218
                size: 3919MiB (4110MB)
                capabilities: removable
                configuration: ansiversion=5
              *-medium
                   physical id: 0
                   logical name: /dev/sda
                   size: 3919MiB (4110MB)
                   capabilities: partitioned partitioned:dos
                   configuration: signature=0009d403
                 *-volume:0
                      description: Linux filesystem partition
                      vendor: Linux
                      physical id: 1
                      logical name: /dev/sda1
                      logical name: /
                      version: 1.0
                      serial: 198bbce8-57d4-4b24-8732-c6bd1f56dc81
                      size: 3638MiB
                      capacity: 3638MiB
                      capabilities: primary bootable ext2 initialized
                      configuration: filesystem=ext2 modified=2011-01-06 17:06:24 mount.fstype=ext2 mount.options=rw,relatime,errors=remount-ro mounted=2010-12-21 19:56:30 state=mounted
                 *-volume:1
                      description: Extended partition
                      physical id: 2
                      logical name: /dev/sda2
                      size: 244MiB
                      capacity: 244MiB
                      capabilities: primary extended partitioned partitioned:extended
                    *-logicalvolume
                         description: Linux swap / Solaris partition
                         physical id: 5
                         logical name: /dev/sda5
                         capacity: 244MiB
                         capabilities: nofs
        *-usb:0
             description: USB Controller
             product: CS5536 [Geode companion] OHC
             vendor: Advanced Micro Devices [AMD]
             physical id: 15
             bus info: pci@0000:00:15.0
             version: 02
             width: 32 bits
             clock: 66MHz
             capabilities: bus_master cap_list
             configuration: driver=ohci_hcd latency=0
             resources: irq:7 memory:a0020000-a0020fff
        *-usb:1
             description: USB Controller
             product: CS5536 [Geode companion] EHC
             vendor: Advanced Micro Devices [AMD]
             physical id: 15.1
             bus info: pci@0000:00:15.1
             version: 02
             width: 32 bits
             clock: 66MHz
             capabilities: bus_master cap_list
             configuration: driver=ehci_hcd latency=0
             resources: irq:7 memory:a0021000-a0021fff

Re: Is there a reliable way to ID a SSD?

[Greg Freemyer]

(resend, sorry for the duplicate)

Jeff,

As the maintainer, can you provide direction as to how quirks should
be maintained for the rotating disk flag (as reflected in
/sys/block/sda/queue/rotational).

There is Bart's patch, Peter's patch, and Martin says it can be
overridden from userspace (I'm not sure which tool,  nor do I know if
there is already a userspace quirks table to add to.).

Bart's atang PATCH: http://marc.info/?l=linux-ide&m=126677421807814&w=2

Peter's patch: http://www.spinics.net/lists/linux-ide/msg38944.html

Greg

> On Thu, Jan 6, 2011 at 11:10 AM, Jan Ceuleers <jan.ceuleers@computer.org> wrote:
>>
>> On 03/01/11 23:03, Peter M. Petrakis wrote:
>>>
>>> Ah you mean /sys/block/sda/queue/rotational.
>>
>> A few data points:
>>
>> - Four rotational disks in my server are correctly reported as such.
>>
>> - The rotational disk in my laptop is as well.
>>
>> - The Intel SSD in my set-top box is reported correctly as non-rotational.
>>
>> - However, the CompactFlash card in my broadband router is incorrectly reported as rotational. I attach lshw for this system.
>>
>> Cheers, Jan
>
>
>
> --
> Greg Freemyer
> Head of EDD Tape Extraction and Processing team
> Litigation Triage Solutions Specialist
> http://www.linkedin.com/in/gregfreemyer
> CNN/TruTV Aired Forensic Imaging Demo -
>    http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retrieved/
>
> The Norcross Group
> The Intersection of Evidence & Technology
> http://www.norcrossgroup.com



--
Greg Freemyer
Head of EDD Tape Extraction and Processing team
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
CNN/TruTV Aired Forensic Imaging Demo -
   http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retrieved/

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com

Re: Is there a reliable way to ID a SSD?

[Jeff Garzik]

On 01/06/2011 01:40 PM, Greg Freemyer wrote:
> (resend, sorry for the duplicate)
>
> Jeff,
>
> As the maintainer, can you provide direction as to how quirks should
> be maintained for the rotating disk flag (as reflected in
> /sys/block/sda/queue/rotational).
>
> There is Bart's patch, Peter's patch, and Martin says it can be
> overridden from userspace (I'm not sure which tool,  nor do I know if
> there is already a userspace quirks table to add to.).
>
> Bart's atang PATCH: http://marc.info/?l=linux-ide&m=126677421807814&w=2
>
> Peter's patch: http://www.spinics.net/lists/linux-ide/msg38944.html

There are a long list of non-rotational devices that were produced 
before the ATA standard grew a standard method of reporting that device 
attribute.

That implies any approach individually listing products will create a 
very, very long horkage list containing all ATA flash drives that anyone 
ever produced.

Alternately, scanning for the "SSD" string does not seem very useful, 
because it will only match a tiny minority of first-run products that 
(a) call themselves "SSD" in marketing literature but (b) do not 
indicate proper rotational attributes in the IDENTIFY page.  Because 
while non-rotational products have been around for a very long time, 
"SSDs" as they are a currently known are new.

It seems like a project to retroactively identify ATA non-rotational 
products will be long and on-going, and would be better suited to a 
userspace package such as Tejun's storage-fixup: 
http://git.kernel.org/?p=linux/kernel/git/tj/storage-fixup.git

	Jeff

Re: Is there a reliable way to ID a SSD?

[Martin K. Petersen]

>>>>> "Greg" == Greg Freemyer <greg.freemyer@gmail.com> writes:

Greg> As the maintainer, can you provide direction as to how quirks
Greg> should be maintained for the rotating disk flag (as reflected in
Greg> /sys/block/sda/queue/rotational).

Greg> There is Bart's patch, Peter's patch, and Martin says it can be
Greg> overridden from userspace (I'm not sure which tool,

# echo 0 > /sys/block/sda/queue/rotational


Greg> nor do I know if there is already a userspace quirks table to add
Greg> to.).

I agree with Jeff that Tejun's tool would be the right place. And
there's always udev...

But the question is whether it's worth the hassle since there a many of
these devices out there and it is unclear whether treating them as
non-rotational is a win. If you can provide some compelling performance
improvement numbers for a particular device we can look into adding a
quirk for it.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Is there a reliable way to ID a SSD?

[Greg Freemyer]

On Thu, Jan 6, 2011 at 2:31 PM, Martin K. Petersen
<martin.petersen@oracle.com> wrote:
>>>>>> "Greg" == Greg Freemyer <greg.freemyer@gmail.com> writes:
>
> Greg> As the maintainer, can you provide direction as to how quirks
> Greg> should be maintained for the rotating disk flag (as reflected in
> Greg> /sys/block/sda/queue/rotational).
>
> Greg> There is Bart's patch, Peter's patch, and Martin says it can be
> Greg> overridden from userspace (I'm not sure which tool,
>
> # echo 0 > /sys/block/sda/queue/rotational
>
>
> Greg> nor do I know if there is already a userspace quirks table to add
> Greg> to.).
>
> I agree with Jeff that Tejun's tool would be the right place. And
> there's always udev...
>
> But the question is whether it's worth the hassle since there a many of
> these devices out there and it is unclear whether treating them as
> non-rotational is a win. If you can provide some compelling performance
> improvement numbers for a particular device we can look into adding a
> quirk for it.

My application is a little different, so it may be that my need of a
quirk table would not be accepted into a general tool, but if I have
to build it, it might as well benefit others.

But my real need is to truly know if the device is rotating or
non-rotating.  I don't need to know about performance issues per se.

My use is for disk sanitizing / wiping.  If a disk is a rotating disk,
my client currently implements a sector by sector wiping process.
They sanitize on the order of thousands of computers a month this way
via a dedicated wiping appliance.  (the original PC is booted via PXE,
so the hardware specifics and BIOSes vary greatly over the universe of
sanitized machines.)

As I'm sure you know, a SSD cannot be safely sanitized this way.

Thus, they need to identify SSDs / flash to ensure that a Security
Erase is attempted and if that fails for whatever reason (including
the command being blocked by the local bios) the technician is
notified that the wiping effort failed.

Note, I've seen several BIOSes that do not allow the Security Erase
command to be passed to the drive, so we have avoided using this
method for rotating media thus far, but for SSD there is no choice.

fyi: all of those thousands of machines are shipped to a central
location for auditing after being sanitized in the field.  At the
central location, the technicians re-perform the wiping process and
can attempt to identify SSDs that were mis-categorized and add them to
a quirks table. It is not a perfect process, but it is as good as we
have for now.

Greg

Re: Is there a reliable way to ID a SSD?

[Jeff Garzik]

On Thu, Jan 6, 2011 at 2:31 PM, Martin K. Petersen
<martin.petersen@oracle.com> wrote:
>>>>>> "Greg" == Greg Freemyer <greg.freemyer@gmail.com> writes:
> But the question is whether it's worth the hassle since there a many of
> these devices out there and it is unclear whether treating them as
> non-rotational is a win. If you can provide some compelling performance
> improvement numbers for a particular device we can look into adding a
> quirk for it.

In an ideal world where information and engineers are cost-free...

if a device is non-rotational, we should know this, whether it's
ancient compact flash, or gigabyte's DRAM-based ATA device, or modern
SSD.  It shouldn't be a question of whether or not treating a
non-rotational device as a non-rotational device is performance win --
because if you're asking that question, it might imply areas where we
are making invalid assumptions about certain classes of non-rotational
devices :)

So while the two approaches presented are not remotely optimal in
terms of identifying all the non-rotational ATA devices out in the
field, I do think there is value in accurately flagging all
non-rotational devices as such.  But it is, IMO, not important to have
this list in the kernel; if such a project is undertaken, a userspace
pkg such as storage-fixup seems more appropriate.

     Jeff

Re: Is there a reliable way to ID a SSD?

[Martin K. Petersen]

>>>>> "Jeff" == Jeff Garzik <jeff@garzik.org> writes:

Jeff> In an ideal world where information and engineers are cost-free...

Oh, yeah...


Jeff> if a device is non-rotational, we should know this, whether it's
Jeff> ancient compact flash, or gigabyte's DRAM-based ATA device, or
Jeff> modern SSD.  It shouldn't be a question of whether or not treating
Jeff> a non-rotational device as a non-rotational device is performance
Jeff> win -- because if you're asking that question, it might imply
Jeff> areas where we are making invalid assumptions about certain
Jeff> classes of non-rotational devices :)

Well, there were a few attempts at getting SSD performance metrics into
ATA. They failed for political/marketing reasons. Even if we had gotten
the metrics we wanted I'm sure most vendors would have indicated that
"this one goes to eleven".

All we have is non-rotational which means "seeks are cheaper than on
rotating media". And for a lot of older/slower flash devices it's
actually a win to do merging because command latency can be quite
high. So it's not necessarily a win to go non-rotational. Which is why I
suggested looking at numbers instead of blindly whitelisting every ATA
flash device known to man.

However, now it appears that what Greg really needs is a
supports_secure_erase flag...

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Is there a reliable way to ID a SSD?

[Martin K. Petersen]

>>>>> "Jan" == Jan Ceuleers <jan.ceuleers@computer.org> writes:

Jan> - However, the CompactFlash card in my broadband router is
Jan>   incorrectly reported as rotational.

Hardly surprising for something that's designed for use in cameras...

Chances are, though, that unlike "real" SSDs your CF is slow enough that
it actually benefits from being treated like a rotational device.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Is there a reliable way to ID a SSD?

[Jan Ceuleers]

On 06/01/11 20:23, Martin K. Petersen wrote:
> Jan>  - However, the CompactFlash card in my broadband router is
> Jan>    incorrectly reported as rotational.
>
> Hardly surprising for something that's designed for use in cameras...
>
> Chances are, though, that unlike "real" SSDs your CF is slow enough that
> it actually benefits from being treated like a rotational device.

Thanks. But performance is not my primary concern or I wouldn't have 
chosen a system consisting of low-performance components ;-) (the 
CompactFlash card is only one example; others include the 500MHz Geode 
CPU, Via Rhine NICs, a tiny amount of RAM etc). I care more about low 
power consumption and the system has to be only just fast enough for my 
needs.

I was just trying to provide some data points for discussion purposes.

Cheers, Jan

Re: Is there a reliable way to ID a SSD?

[Martin K. Petersen]

>>>>> "Jan" == Jan Ceuleers <jan.ceuleers@computer.org> writes:

>> Chances are, though, that unlike "real" SSDs your CF is slow enough
>> that it actually benefits from being treated like a rotational
>> device.

Jan> Thanks. But performance is not my primary concern or I wouldn't
Jan> have chosen a system consisting of low-performance components ;-)
Jan> (the CompactFlash card is only one example; others include the
Jan> 500MHz Geode CPU, Via Rhine NICs, a tiny amount of RAM etc). I care
Jan> more about low power consumption and the system has to be only just
Jan> fast enough for my needs.

There are "real" SSDs in CompactFlash form factor and they do fare much
better than the consumer cards. Made a significant difference on my
Geode boxes, anyway. But most importantly they have much better write
endurance than the camera cards which is the reason I originally got
them.

-- 
Martin K. Petersen	Oracle Linux Engineering