[OpenIndiana-discuss] sd.conf trouble and illumos bug #3220

Bryan N Iotti ironsides.medvet at runbox.com
Fri Jan 3 22:01:15 UTC 2014


Hi all,

I recently acquired a consumer 128 GB SanDisk SATA SSD to replace my root pool disks.

I anticipated having to enter the VID and PID into sd.conf as with other 4K or higher drives.

Unfortunately, no matter what I enter there, the drive retains the 512 byte block size and ashift remains at 9.

Using the command provided to find VID and PID (echo "::walk sd_state | ::grep '.!=0' | ::print struct sd_lun un_sd | ::print struct scsi_device sd_inq | ::print struct scsi_inquiry inq_vid inq_pid" | mdb -k) I get the following output for the disk:

inq_vid = [ "ATA     " ]
inq_pid = [ "SanDisk SDSSDHP1" ]

I enter it as a single string ("ATA     SanDisk SDSSDHP1"), update_drv -vf sd and shutdown and power on again.

Nothing. ashift remains at 9.

Doing prtconf -v and examining the output I get the following (truncated, full available on request):
 name='inquiry-product-id' type=string items=1
                            value='SDSSDHP128G'
                        name='inquiry-vendor-id' type=string items=1
                            value='SanDisk'

Is this a result of illumos bug #3220, where noncompliant devices break sd-config-list?
Bug report here: https://www.illumos.org/issues/3220
In other words, the VID + PID ends up being longer than the "allowed number of characters" (and that would explain the truncated PID I get from the kernel) and sd-config-list fails to match them.
I also tried wildcarding as described in Illumos feature #2665, where Albert Lee indicated using partial matches with *.

My latest attempt used this string (there's an entry also for the Dell-flashed Seagate SAS drives I have):
sd-config-list="SEAGATE ST2000NM0001","power-condition:false","*SDSSDHP*","physical-block-size:4096";

I'm surprised that the SAS drives didn't revert back to powering off immediately.

On the illumos list of example sd-config-list entries almost all SSDs have an 8k blocksize. This disk seems optimized for 8k read/write cycles. Should I try 8192 as a block size?

Now, to sum it up:
- Am I running into the above bug?
- What else can I try?

Thank you all for any info/hints.
   Bryan
-- 
Bryan N Iotti

+39 366 3708436
ironsides.medvet at runbox.com



More information about the OpenIndiana-discuss mailing list