O uso do interposer fornece uma experiência SAS nativa à unidade, mas a desvantagem é o mecanismo de tratamento e recuperação de erros, que também é delegado a esses dispositivos intermediários. Embora haja o documento escrito T10 para SCSI para tradução ATA (SAT), mas os detalhes mais sutis são deixados para o implementador. Um caso em questão é o seguinte - o SATA não possui uma noção de comando de interrupção que é usado no domínio SAS para recuperar um comando. Assim, quando o interposer SAS tem um comando que precisa ser abortado pelo host, ele converterá o aborto em um SATA equivalente a uma reinicialização por software de um efeito inadvertido da força, despejando todos os comandos ativos com o disco SATA e causando latência e outras falhas sutis (Eu posso preencher os detalhes, se necessário). Você poderia dizer que devemos evitar a anulação do host e esse problema não ocorreria. Com certeza, mas no caso inverso, caso a unidade encontre um erro que leve a uma execução acima / abaixo, o interposer não terá outra coisa a não ser fazer com que uma reinicialização do dispositivo limpe essa condição levando essencialmente ao mesmo efeito que abortar. No exemplo posterior, o host não tem controle e é a natureza do sistema.
Em algumas situações, talvez seja melhor não usar o interposer e usar o conjunto de comandos SATA nativo. A maioria dos controladores SAS suportam a conexão SAS e SATA e também permitem um mix. Mas se o requisito for acesso de porta dupla para unidades SATA, você estará bloqueado para obter um interposer. Alternativamente, há uma classe de drives que estão surgindo, chamados de drives FAT SAS (o fat implica a capacidade e não o formato físico), que são uma alternativa viável, embora a confiabilidade do drive seja definitivamente menor que a do $$ sas drives. / p>