Por que o subsistema Linux SCSI controla o hardware que não está obviamente relacionado ao SCSI?

Sem conhecimento, normalmente esperaria que SATA, SCSI e USB Mass Storage fossem controlados por drivers diferentes. No entanto, no Linux, o subsistema SCSI controla todos eles.

Bem, o armazenamento em massa USB é literalmente SCSI nos bastidores; ele usa o conjunto de comandos SCSI real, apenas em outro transporte. (Ainda mais se o seu disco suportar UAS, que significa "USB-Attached SCSI", mas também se aplica aos dispositivos básicos de armazenamento BOT.) O que significa que sim, seus gabinetes de disco USB-SATA externos estão traduzindo os comandos entre ATA e SCSI (com um comando especial 'ATA passthrough' para coisas como acesso SMART).

(E se você já teve um desses HDDs ou iPods FireWire naquela época, esses eram dispositivos SBP-2, que novamente são SCSI. É um conjunto de comandos bastante versátil.)

O suporte SATA passa por SCSI porque na época em que o SATA foi introduzido, o subsistema Linux PATA existente (que datava dos primeiros dias do Linux) era uma espécie de lixo em comparação com o robusto subsistema SCSI, e o SATA já estava um pouco mais próximo do SCSI em termos de recursos – enfileiramento, comandos marcados, etc. – portanto, tratar o AHCI como um tipo estranho de controlador SCSI provavelmente ofereceu um desempenho muito melhor do que tratá-lo como um tipo estranho de controlador PATA.

(Na verdade, até mesmo muitos sistemas Windows da época tinham drivers SATA de fornecedores que apresentavam o controlador SATA AHCI como se fosse um controlador SCSI, antes do Windows ganhar suporte nativo AHCI – por exemplo, o Windows XP conhecia SCSI, mas não AHCI.)

Este suporte usa o documento oficial de tradução de SCSI para ATA produzido pelo grupo de trabalho T10 responsável por SCSI e, aparentemente, a maioria, se não todas as coisas, tem uma tradução 1:1, então acho que não é tão hackeado quanto parece. . Ainda assim, parece que na época esta foi pensada como uma solução temporária , com planos de fazer um novo subsistema Linux para dispositivos SATA, mas isso nunca aconteceu; Acho que 'libata' (a camada de tradução) funcionou melhor do que o esperado.

(E como última observação, todas as unidades de CD/DVD ATA usam o protocolo "ATAPI" – que é apenas SCSI dentro de pacotes ATA. Novamente, mesmo no Windows, você verá quase todos os softwares de gravação de CD/DVD listando CD/DVD unidades como se fossem dispositivos SCSI, porque de certa forma são.)

Por que o suporte NVMe e PATA não fazem parte do subsistema SCSI?

O suporte PATA faz parte disso. Há muitos anos, até mesmo os discos PATA têm aparecido como /dev/sd*dispositivos através da tradução SCSI-ATA 'libata', em vez de /dev/hd*dispositivos PATA reais. Os drivers PATA “legados” foram completamente removidos do Linux nos últimos meses, mas não são usados ​​há muito tempo.

Quanto ao NVMe, presumo que seja o mesmo que foi mencionado na mensagem da lista de discussão T10 sobre SATA, onde um subsistema separado era o objetivo final em primeiro lugar... e dado que o NVMe foi projetado como um sucessor de ambos ATA e SCSI várias décadas depois, pode ter havido muitas diferenças para que fosse prático, por exemplo, as filas extremamente profundas que o NVMe permite em comparação com a finalidade para a qual o SCSI foi projetado.

Ou seja, libata funcionou bem porque PATA/SATA era um subconjunto de capacidades SCSI, enquanto NVMe é mais um superconjunto.

(O subsistema NVMe originalmente tinha um tipo semelhante de tradução SCSI , mas que acabou sendo removido; a mensagem de commit afirma que isso se devia em parte a diferenças significativas entre os dois.)

Isso é explicado no Guia de Interfaces SCSI :

Embora o antigo barramento SCSI paralelo (rápido/amplo/ultra) tenha caído em desuso, o conjunto de comandos SCSI é mais amplamente usado do que nunca para se comunicar com dispositivos em vários barramentos diferentes.

Os comandos SCSI podem ser transportados por praticamente qualquer tipo de barramento e são o protocolo padrão para dispositivos de armazenamento conectados a dispositivos USB, SATA, SAS, Fibre Channel, FireWire e ATAPI. Pacotes SCSI também são comumente trocados por Infiniband, I20, TCP/IP (iSCSI) e até mesmo portas paralelas.

A explicação é que o subsistema SCSI é usado para dominar o versátil protocolo SCSI em todos os tipos de barramentos, portanto não principalmente para controlar dispositivos SCSI.

Mais detalhes sobre a interface SCSI podem ser encontrados no artigo acima. A estrutura geral do sistema é descrita como:

O subsistema SCSI usa um design de três camadas, com camadas superior, média e baixa. Cada operação que envolve o subsistema SCSI (como ler um setor de um disco) usa um driver em cada um dos três níveis: um driver de camada superior, um driver de camada inferior e a camada intermediária SCSI.

A camada superior SCSI fornece a interface entre o espaço do usuário e o kernel, na forma de nós de dispositivos de bloco e char para E/S e ioctl(). A camada inferior SCSI contém drivers para dispositivos de hardware específicos.

No meio está a camada intermediária SCSI, análoga a uma camada de roteamento de rede, como a pilha IPv4. A camada intermediária SCSI roteia um protocolo de dados baseado em pacotes entre os nós /dev da camada superior e os dispositivos correspondentes na camada inferior. Ele gerencia filas de comandos, fornece funções de tratamento de erros e gerenciamento de energia e responde a solicitações ioctl().

São os drivers da camada inferior que possibilitam ao subsistema SCSI interagir com tantos tipos de barramentos e dispositivos.

PATA agora está desatualizado e SATA é o padrão para a maioria dos dispositivos de armazenamento de consumo. NVMe é usado para desempenho, principalmente para SSDs. SCSI ainda é usado para ambientes corporativos especializados para compatibilidade e seus recursos avançados.