[OmniOS-discuss] SLC SSD connected via SAS expander

Richard Elling richard.elling at richardelling.com
Fri Jun 14 16:47:03 EDT 2013


On Jun 14, 2013, at 12:08 AM, Hafiz Rafibeyli <rafibeyli at gmail.com> wrote:

> Hello ,i'm running omnios(d3950d8) as a NAS  base with napp-it,
> 
> hardware is Supermicro SC846E26-R1200B+LSI SAS 9211-8i HBA(IT mode enabled with last firmware)
> 
> everything working great,but i'm getting errors with my Intel SLC SSD 32GB(zil log).
> 
> SLC SSD connected to system backplane  via supermicro 2,5 to 3,5 converter.
> 
> I read somewhere Intel's SLC SSD not supported when  connected via SAS expander,anyway to solve this problem?

It is not an SLC SSD issue. More likely, it is a SATA issue. Since we don't know the 
model of SSD, it can be hard to say for sure.

> 
> messages from /var/adm/messages

These are the result of the disk being reset. The timeout happens, the disk is reset and
any in-flight operations are aborted (can decode this from the ioc_status). Ultimately,
you will need to replace the SSD, though it may be possible to upgrade the SSD firmware
as some older Intel SATA SSDs had some firmware fixes available.

> 
> Jun 14 10:03:45 canomnios scsi: [ID 107833 kern.warning] WARNING: /pci at 0,0/pci8086,340e at 7/pci1000,3020 at 0 (mpt_sas0):
> Jun 14 10:03:45 canomnios 	Disconnected command timeout for Target 16

command timed out, reset sent...

> Jun 14 10:03:45 canomnios scsi: [ID 365881 kern.info] /pci at 0,0/pci8086,340e at 7/pci1000,3020 at 0 (mpt_sas0):
> Jun 14 10:03:45 canomnios 	Log info 0x31140000 received for target 16.
> Jun 14 10:03:45 canomnios 	scsi_status=0x0, ioc_status=0x8048, scsi_state=0xc
> Jun 14 10:03:45 canomnios scsi: [ID 365881 kern.info] /pci at 0,0/pci8086,340e at 7/pci1000,3020 at 0 (mpt_sas0):
> Jun 14 10:03:45 canomnios 	Log info 0x31140000 received for target 16.
> Jun 14 10:03:45 canomnios 	scsi_status=0x0, ioc_status=0x8048, scsi_state=0xc

... two I/Os were aborted by the disk.

> Jun 14 10:06:15 canomnios scsi: [ID 107833 kern.warning] WARNING: /pci at 0,0/pci8086,340e at 7/pci1000,3020 at 0 (mpt_sas0):
> Jun 14 10:06:15 canomnios 	Disconnected command timeout for Target 16

rinse, repeat

> Jun 14 10:06:15 canomnios scsi: [ID 365881 kern.info] /pci at 0,0/pci8086,340e at 7/pci1000,3020 at 0 (mpt_sas0):
> Jun 14 10:06:15 canomnios 	Log info 0x31140000 received for target 16.
> Jun 14 10:06:15 canomnios 	scsi_status=0x0, ioc_status=0x8048, scsi_state=0xc
> Jun 14 10:06:15 canomnios scsi: [ID 365881 kern.info] /pci at 0,0/pci8086,340e at 7/pci1000,3020 at 0 (mpt_sas0):
> Jun 14 10:06:15 canomnios 	Log info 0x31140000 received for target 16.
> Jun 14 10:06:15 canomnios 	scsi_status=0x0, ioc_status=0x8048, scsi_state=0xc

The reason people suggest using a SATA/SAS interposer instead of STP for these cases
is because we have experienced cases where the reset/recovery can take out everything
on the expander. There is a lot of proprietary firmware in the mix: HBAs, expanders, and 
disks. Mixing native SAS with STP just adds to the complexity and unintended consequences
can result. By using a SATA/SAS interposer, you can eliminate STP from the mix and keep
the protocol translation confined to one SAS target.
 -- richard

--

Richard.Elling at RichardElling.com
+1-760-896-4422



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20130614/7b9d3e20/attachment.html>


More information about the OmniOS-discuss mailing list