Em que sentido a SATA “fala” SCSI? Quanto é compartilhado entre SCSI e ATA?

Isso não é novidade para mim, pelo menos, que a SATA "converse" o SCSI, portanto, por que esses dispositivos SATA aparecem como dispositivos SCSI no Linux.

Uma pergunta relacionada já foi feita antes, por exemplo, por que meus dispositivos SATA aparecem em / proc / scsi / scsi?

No entanto, o que deixa de ser mencionado, onde vi isso discutido anteriormente, é exatamente em que sentido o SATA se relaciona com o SCSI e como eles diferem.

Suponho que é um dado adquirido que eles diferem na camada física, pois não compartilham cabos compatíveis.

No entanto, e quanto mais alto na pilha? Estou ciente de como o Linux representa discos SATA e até IDE em kernels modernos como apenas SCSI para o subsistema SCSI. Mas e o protocolo real usado no barramento?

Sei também que o ATAPI é um encapsulamento para SCSI, mas e o ATA comum? Percebi que recursos do SCSI, como NCQ, FUA, DPO, etc (se não me lembro incorretamente) foram adotados pelo SCSI. Mas não está claro quanto "quanto" do conjunto de comandos SCSI é realmente compartilhado ou semelhante.

Os dispositivos SATA modernos com suas especificações ATA implementam um subconjunto do conjunto de comandos SCSI, mas encapsulado (como no ATAPI)? Um conjunto idêntico? Um superconjunto? Ou talvez apenas os recursos selecionados sejam implementados como variantes que não são diretamente idênticas?

Onde posso encontrar informações claras sobre isso, e especialmente como isso se relaciona com o kernel do Linux? Algum tipo de tutorial para o desenvolvimento de drivers seria bom, mas apenas uma visão geral que não pule completamente todos os detalhes seria suficiente. Estou ciente de que posso apenas ler a especificação real, mas isso é muito detalhado demais, difícil de encontrar o que você realmente está procurando e simplesmente não é realista para mim e provavelmente para a maioria dos outros usuários no sentido temporal.

SCSI e ATA são padrões totalmente diferentes. Atualmente, ambos são desenvolvidos sob a égide da organização de padrões INCITS , mas por grupos diferentes. O SCSI está no comitê técnico T10 , enquanto o ATA está no T13 . ¹

O ATA foi projetado apenas com unidades de disco rígido. O SCSI é mais amplo e mais antigo, sendo uma maneira padrão de controlar dispositivos de armazenamento em massa, unidades de fita, unidades de mídia óptica removíveis (CD, DVD, Blu-Ray ...), scanners e muitos outros tipos de dispositivos .

Não era óbvio em meados da década de 1980 - quando o IDE foi introduzido no mundo dos PCs - que o SCSI seria empurrado para as margens do mundo da computação. O SCSI era bem estabelecido e mais capaz. Estações de trabalho Unix e computadores Macintosh fornecidos com unidades de disco rígido SCSI por décadas. Os computadores de última geração geralmente tinham uma placa SCSI para periféricos, pelo menos e também para o disco rígido do sistema. As primeiras unidades de CD-ROM e fita para computadores pessoais foram lançadas primeiro no formato SCSI.

Sendo a indústria de PCs o que é, houve um esforço para usar o padrão ATA, mais barato, em vez do SCSI. O compromisso inicial foi chamado ATAPI , uma extensão do ATA que permite que um dispositivo que entenda SCSI internamente receba esses comandos SCSI por uma interface ATA. Mais sobre isso abaixo.

Vários anos depois, o SCSI obteve o recurso de passagem de comando ATA , basicamente o inverso do ATAPI, permitindo comandos ATA através de um barramento SCSI. Um uso para esse recurso é encapsular comandos do ATA SMART por SCSI. smartmontoolsfaz isso , por exemplo.

Mais tarde ainda, o comitê INCITS T10 desenvolveu um padrão chamado SCSI / ATA Translation (SAT), que converte comandos SCSI em comandos ATA e vice-versa. ² A libatabiblioteca do kernel do Linux fornece uma implementação SAT para Linux, entre outras coisas .

Há alguma sobreposição lógica nos protocolos SCSI e ATA, pois os dois controlam as unidades de disco rígido. Obviamente, ambos precisam de uma maneira de procurar um setor específico do disco rígido, recuperar o conteúdo desse setor etc. etc. No entanto, os formatos de comando são totalmente diferentes; caso contrário, não precisaríamos desses mecanismos de tradução e passagem.

SATA realmente "fala" SCSI

Isso é tão verdadeiro quanto a afirmação de que "os carros são cor de rosa". Alguns carros são cor de rosa.

ATAPI, passagem ATA e SAT são apenas parte da história. Leia.

Suponho que é um dado adquirido que eles diferem na camada física, pois não compartilham cabos compatíveis.

Isso era verdade no antigo mundo paralelo do SCSI , mas assim como a SATA substituiu o PATA, o SAS substituiu o SCSI paralelo.

SAS e SATA compartilham os mesmos conectores de unidade e são eletricamente compatíveis. Um controlador SAS pode conversar com dispositivos SAS e SATA, mas uma unidade SAS não pode funcionar com um controlador somente SATA. A diferença está na negociação e nos comandos que você pode usar após os dispositivos em cada extremidade do cabo descobrirem com o que estão falando.

De fato, muitos controladores "SATA RAID" são realmente controladores SAS RAID. Esses controladores geralmente têm um ou mais conectores SAS SFF-8087 na placa, mas você pode conectar unidades SATA a eles com um cabo breakout SFF-8087 a 4 × SATA. Portanto, uma placa RAID SAS / SATA com dois conectores correspondentes SFF-8087 controla até 8 unidades. ³

Outra situação comum é um gabinete de unidade hot swap ou gabinete do computador com um backplane SAS . O backplane geralmente possui um conector SFF-8087, permitindo o uso de um cabo simples de 8087 a 8087 do backplane ao controlador de disco. Se as unidades nas bandejas hot swap forem SATA, isso não importa. O controlador SAS pode conversar com eles pelo cabeamento do SAS, enquanto eles se sentam nos trenós das unidades que conectam as unidades ao backplane SAS. Porém, as unidades ainda são SATA, falando o protocolo ATA, não SCSI.

Eu também sei que ATAPI é um encapsulamento para SCSI

Verdadeiro, mas o ATAPI é usado apenas para dispositivos que não sejam unidades de disco rígido. A principal razão pela qual esse padrão existe é permitir que uma interface ATA transporte comandos SCSI, como os comandos de streaming de dados para uma unidade de fita, o comando "ejetar mídia" para uma unidade de disco óptico ou o comando "play track" para um CD de áudio .

Esse fato está se tornando menos relevante à medida que os dispositivos que não são HDD que costumavam falar SCSI sobre ATAPI desaparecem ou passam para outras interfaces. As unidades de fita low-end não existem mais, então as unidades de fita agora são SAS. ^{4 Os} scanners são praticamente apenas USB atualmente. As unidades de mídia óptica estão saindo do gabinete do computador para serem conectadas via USB ou desaparecendo completamente, deixando apenas as unidades ópticas internas cada vez mais raras falando com ATAPI.

Independentemente disso, um dispositivo SATA que entende SCSI sobre ATAPI é um "dispositivo SCSI" apenas de maneira limitada. Esses dispositivos não se beneficiarão da maioria das vantagens do SAS sobre SCSI . Esses recursos tornam o SAS distintamente valioso em comparação com o SATA, apesar do ATAPI.

Se você quiser outra analogia de carro, o fato de eu poder dirigir meu carro em uma pista oval não o torna um carro de corrida.

Percebi que recursos do SCSI, como NCQ, FUA, DPO, etc (se não me lembro incorretamente) foram adotados pelo SCSI. Mas não está claro quanto "quanto" do conjunto de comandos SCSI é realmente compartilhado ou semelhante.

Principalmente isso equivale a mimetismo low-end. NCQ não é a mesma coisa que TCQ , por exemplo. Você só obterá um disco rígido com o TCQ se for um dispositivo SAS. Conecte uma unidade SATA compatível com NCQ a um controlador SAS, e de repente ela não ganha a capacidade de TCQ.

Dito isto, um dispositivo SATA moderno pode muito bem ser muito mais capaz do que um dispositivo SCSI de uma década atrás. Certamente será capaz de níveis muito mais altos de E / S.

Tudo isso é confuso e sobreposto, porque essa é a natureza do mundo do hardware de PC. Não há linhas claras porque os fabricantes de unidades ópticas - apenas para escolher um sub-setor - realmente não querem construir duas unidades totalmente diferentes, uma que fala SAS com sua expressão mais alta e a outra que fala SATA. Então, eles se comprometem. Eles fazem lobby nos comitês que definem esses padrões para criar um único padrão que permite que eles deixem sua unidade SATA em um barramento SAS, e todos ficam felizes em sua maioria.

Onde posso encontrar informações claras sobre isso, e especialmente como isso se relaciona com o kernel do Linux?

Por fim, você deseja ler as fontes do Linux . O libATAGuia do desenvolvedor também deve ser útil.

Não conheço nenhum resumo fácil de como tudo isso funciona. Não foi projetado para ser fácil. Ele foi projetado para acomodar três décadas de evolução de hardware, padrões concorrentes e objetivos díspares. Além disso, foi projetado sem níveis mágicos de previsão. Em suma, é uma bagunça. As únicas pessoas que realmente precisam saber como a bagunça funciona são aquelas que constroem os kernels do SO, as que projetam o hardware e, em menor grau, as que escrevem os drivers para os kernels do SO. Para um quadro tão pequeno de pessoas altamente capazes, padrões e código de trabalho são suficientes.

Hoje, o Linux chama a maioria dos dispositivos de armazenamento em massa regraváveis /dev/sd?. "SD" significava "disco SCSI" e existia apenas para diferenciar do /dev/hd?significado genérico de "Disco Rígido", mas implicando PATA na maioria dos casos. Essa distinção é outra irrelevância prática hoje. Agora, temos SSDs, pen drives USB, discos rígidos virtuais , dispositivos iSCSI e muito mais /dev/sd?. Eu sugiro que você comece a pensar em "SD" como abreviação de "dispositivo de armazenamento", em vez de se preocupar se o dispositivo fala ATA sobre SATA, ATA sobre Ethernet , SCSI sobre USB , SCSI sobre USB , SCSI sobre ATAPI, SCSI sobre SAS, SCSI sobre IP (iSCSI ) ou o que você tem.

O principal problema é que os esquemas de nomeação geralmente superam a razão por trás do esquema. Você vê isso em /dev/scd0. O dispositivo conectado a esse /devnó tem mais chances de ser uma unidade de DVD ou Blu-Ray do que uma unidade de CD hoje em dia.

A alternativa - onde você nomeia cada /devnó após o tipo exato de dispositivo conectado a ele - tem seus próprios problemas. Seria realmente melhor nomearmos o /devnó de acordo com o protocolo de baixo nível usado? /dev/atapi0, /dev/sas0etc? Ou talvez você prefira /dev/atapibluray0e tal? E as unidades multimídia? O mesmo driver também precisa ser exposto /dev/atapicd0, caso você deslize um CD na unidade Blu-Ray? Isso apenas substitui um esquema confuso por outro.

A /dev/sd?abstração do Linux não é perfeita, mas é útil. Por exemplo, você pode aprender o fato de que /dev/sdaprovavelmente é a unidade de inicialização sem se preocupar em saber quais cabos, protocolo de interface e mídia estão por trás desse nome. Se eu te disser que uma determinada caixa de Linux tem uma única unidade do sistema, uma unidade óptica, e às vezes tem um pen drive USB conectado a ela, você pode confiantemente acho que eles são chamados /dev/sda, /dev/sdbe /dev/sdc, respectivamente.

Notas de rodapé :

1. O SCSI e o ATA não começaram a compartilhar uma organização de padrões pai. Ambos começaram como controladores de disco rígido proprietários. O SCSI evoluiu a partir do SASI da Shugart Associates , e o ATA / IDE surgiu de uma colaboração de design muito mais recente entre a Western Digital, Compaq e CDC.

   O ANSI posteriormente padronizou os dois, com o ATA-1 após o SCSI-1, cerca de 8 anos depois.

   INCITS é um tipo de organização irmã da ANSI . A INCITS publica normas finais através da ANSI nos EUA e ISO / IEC JTC 1 em todo o mundo.

2. O padrão atual é o SAT-3 , publicado em maio de 2015, com o SAT-4 e o SAT-5 em andamento enquanto escrevo isso em meados de julho de 2018. O último link leva você aos rascunhos das versões em andamento.

3. Estou ignorando multiplicadores de portas SATA , expansores SAS , etc.

4. Exceto os modelos criados para compatibilidade com sistemas SCSI paralelos antigos.