¿En qué sentido SATA "habla" SCSI? ¿Cuánto se comparte entre SCSI y ATA?

Esto no es nada nuevo para mí, al less, que SATA en realidad "habla" SCSI, de ahí que estos dispositivos SATA aparezcan como dispositivos SCSI en Linux.

Se ha hecho una pregunta relacionada anteriormente, por ejemplo, ¿Por qué mis dispositivos SATA aparecen en / proc / scsi / scsi?

Sin embargo, lo que no se menciona cuando he visto esto discutido anteriormente es exactamente en qué sentido SATA se relaciona con SCSI, y cómo difieren.

Supongo que se da por sentado que difieren en la capa física, ya que no comparten cables compatibles.

Sin embargo, ¿qué hay más arriba en la stack? Soy consciente de cómo Linux representa SATA e incluso los discos IDE en núcleos modernos como SCSI para el subsistema SCSI. Pero, ¿qué pasa con el protocolo real que se usa en el autobús?

También sé que ATAPI es una encapsulación para SCSI, pero ¿qué pasa con ATA regular? Me he dado count de que las funciones de SCSI como NCQ, FUA, DPO, etc. (si no recuerdo mal) han sido adoptadas desde SCSI. Pero no está claro cómo "mucho" del set de commands SCSI es realmente compartido o similar.

¿Los dispositivos SATA modernos con su especificación ATA implementan un subset del set de commands SCSI, pero encapsulados (como en ATAPI)? Un set idéntico? ¿Un superset? ¿O quizás solo las características seleccionadas se implementan como variantes que no son directamente idénticas?

¿Dónde puedo encontrar información clara sobre esto, y especialmente cómo se relaciona con el kernel de Linux? Algún tipo de tutorial para el desarrollo del controller sería bueno, pero incluso una visión general que no omita por completo todos los detalles sería suficiente. Soy consciente de que puedo leer la especificación real, pero eso es demasiado detallado, es difícil encontrar lo que realmente está buscando, y no es realist para mí y probablemente para la mayoría de los demás usuarios en el sentido temporal.

SCSI y ATA son estándares completamente diferentes. En la actualidad ambos se desarrollan bajo los auspicios de la organización de estándares INCITS pero por diferentes grupos. SCSI está bajo el comité técnico T10 , mientras que ATA está bajo T13 . 1

ATA fue diseñado solo con discos duros. SCSI es un estándar más amplio, capaz de controlar dispositivos de almacenamiento masivo, unidades de cinta, unidades de medios ópticos extraíbles (CD, DVD, Blu-Ray …), escáneres y muchos otros types de dispositivos .

No era obvio a mediados de la década de 1980, cuando IDE se introdujo en el mundo de las PC, que SCSI se vería empujado a los márgenes del mundo de la informática. SCSI estaba bien establecido y era más capaz. Las estaciones de trabajo Unix y las computadoras Macintosh se enviaron con unidades de disco duro SCSI durante décadas. Las PC de alta gama a menudo tenían una tarjeta SCSI para periféricos al less, y con frecuencia también para el disco duro del sistema. Las primeras unidades de CD-ROM y de cinta para computadoras personales aparecieron primero en formatting SCSI.

Aunque la industria de las PC es lo que es, hubo un impulso para usar el estándar ATA less costoso en lugar de SCSI. El compromiso inicial se llamó ATAPI , una extensión de ATA que permite que un dispositivo que entiende SCSI internamente reciba esos commands SCSI a través de una interfaz ATA. Más sobre esto a continuación.

Varios años más tarde, SCSI obtuvo la function de transferencia de commands ATA , básicamente la inversa de ATAPI, que permite commands ATA a través de un bus SCSI. Un uso para esta installation es tunelizar commands ATA SMART sobre SCSI. smartmontools hace esto , por ejemplo.

Más tarde, el comité INCITS T10 desarrolló un estándar llamado SCSI / ATA Translation (SAT), que traduce los commands SCSI a los commands ATA y viceversa. 2 La biblioteca libata del kernel de libata proporciona una implementación SAT para Linux, entre otras cosas .

Existe una superposition lógica en los protocolos SCSI y ATA, ya que ambos controlan las unidades de disco duro. Ambos obviamente necesitan una forma de search un sector de disco duro particular, recuperar los contenidos de ese sector, etc. Sin embargo, los formattings de command son completamente diferentes; de lo contrario, no necesitaríamos estos mecanismos de traducción y transferencia.

SATA realmente "habla" SCSI

Eso es tan cierto como la afirmación de que "Los automobilees son rosados". Algunos autos son rosas.

ATAPI, ATA pass-through y SAT son solo parte de la historia. Sigue leyendo.

Supongo que se da por sentado que difieren en la capa física, ya que no comparten cables compatibles.

Eso era cierto en el viejo mundo SCSI paralelo , pero justo cuando SATA reemplazó a PATA, SAS reemplazó a SCSI paralelo.

SAS y SATA comparten los mismos conectores de unidad, y son eléctricamente compatibles. Un controller SAS puede comunicarse con dispositivos SAS y SATA, pero un disco SAS no puede funcionar con un controller SATA solamente. La diferencia está en la negociación y en los commands que puede usar después de que los dispositivos en cada extremo del cable descubran con qué están hablando.

De hecho, muchos controlleres "SATA RAID" son realmente controlleres SAS RAID. Dichos controlleres a menudo tienen uno o más conectores de acoplamiento SFF-8087 SAS en la tarjeta, pero puede conectarlos a unidades SATA con un cable SFF-8087 a 4 × SATA breakout. Por lo tanto, una tarjeta RAID SAS / SATA con dos conectores de acoplamiento SFF-8087 controla hasta 8 unidades. 3

Otra situación común es un gabinete de unidad de intercambio en caliente o caja de computadora con un plano posterior SAS. El panel posterior generalmente tiene un conector SFF-8087, lo que permite el uso de un simple cable 8087-a-8087 desde el plano posterior al controller de disco. Si las unidades en las bandejas de intercambio activo son SATA, eso no tiene importancia. El controller SAS puede hablar con ellos a través del cableado SAS, ya que se sientan en los slideres de la unidad que conectan las unidades al plano posterior SAS. Sin embargo, las unidades siguen siendo unidades SATA, hablando el protocolo ATA, no SCSI.

También sé que ATAPI es una encapsulación para SCSI

Es cierto, pero ATAPI solo se usa para dispositivos que no sean unidades de disco duro. La razón principal de este estándar es permitir que una interfaz ATA transporte commands SCSI como los commands de transmisión de datos para una unidad de cinta, el command "expulsar multimedia" para una unidad de disco óptico o el command "pista de reproducción" para un disco de audio CD .

Este hecho se está volviendo less relevante a medida que los dispositivos que no son HDD que solían hablar SCSI sobre ATAPI desaparecen o pasan a otras interfaces. Las unidades de cinta de gama baja ya no existen, por lo que las unidades de cinta ahora son SAS. 4 Los escáneres son prácticamente solo USB en estos días. Las unidades de medios ópticos se mueven fuera de la carcasa de la computadora para conectarse a través de USB, o desaparecen por completo, dejando solo las unidades ópticas internas cada vez más raras que hablan ATAPI.

De todos modos, un dispositivo SATA que comprende SCSI sobre ATAPI es un "dispositivo SCSI" solo de forma limitada. Dichos dispositivos no se beneficiarán de la mayoría de las ventajas de SAS sobre SCSI . Estas capacidades hacen que SAS sea valiosa en comparación con SATA, a pesar de ATAPI.

Si quiere otra analogía con el automobile, el hecho de que pueda conducir mi automobile en una pista ovalada no lo convierte en un auto de carreras.

Me he dado count de que las funciones de SCSI como NCQ, FUA, DPO, etc. (si no recuerdo mal) han sido adoptadas desde SCSI. Pero no está claro cómo "mucho" del set de commands SCSI es realmente compartido o similar.

En su mayoría esto equivale a mimetismo de gama baja. NCQ no es lo mismo que TCQ , por ejemplo. Solo obtendrá un disco duro con TCQ si es un dispositivo SAS. Enchufe una unidad SATA compatible con NCQ en un controller SAS y de repente no obtenga la capacidad TCQ.

Dicho esto, un dispositivo SATA moderno puede ser mucho más capaz que un dispositivo SCSI de hace una década. Ciertamente será capaz de niveles mucho más altos de E / S.

Todo esto es confuso y superpuesto porque esa es la naturaleza del mundo del hardware para PC. No hay líneas claras porque los fabricantes de unidades ópticas -sólo para elegir una subindustria- realmente no quieren build dos unidades completamente diferentes, una hablando SAS a su máxima expresión, y la otra hablando SATA. Entonces, se comprometen. Hacen lobby en los comités que definen dichos estándares para crear un estándar único que les permita dejar caer su unidad SATA en un bus SAS, y todos están contentos.

¿Dónde puedo encontrar información clara sobre esto, y especialmente cómo se relaciona con el kernel de Linux?

En última instancia, desea leer las fonts de Linux . La libATA Developer's Guide también debería ser útil.

No conozco ningún resumen fácil de cómo funciona todo esto. No fue diseñado para ser fácil. Fue diseñado para acomodar tres décadas de evolución de hardware, estándares competitivos y metas dispares. Además, fue diseñado sin niveles mágicos de previsión. En resumen, es un desastre. Las únicas personas que realmente tienen que saber cómo funciona el desorder son aquellos que construyen los núcleos del sistema operativo, aquellos que diseñan el hardware y, en menor medida, aquellos que escriben los controlleres para los núcleos del sistema operativo. Para un cuadro tan pequeño de personas altamente capaces, las normas y el código de trabajo son suficientes.

Hoy, Linux llama a la mayoría de los dispositivos de almacenamiento masivo reescribibles /dev/sd? . "SD" alguna vez significaba "disco SCSI" y existía simplemente para diferenciarlo de /dev/hd? genéricamente significa "disco duro", pero implica PATA en la mayoría de los casos. Esta distinción es otra irrelevancia práctica hoy. Ahora tenemos SSD, memorys USB, discos duros virtuales , dispositivos iSCSI y más todos llamados /dev/sd? . Sugiero que empiece a pensar en "SD" como la abreviatura de "dispositivo de almacenamiento", en lugar de preocuparse por si el dispositivo habla ATA sobre SATA, ATA sobre Ethernet , SCSI sobre USB , SCSI sobre ATAPI, SCSI sobre SAS, SCSI sobre IP (iSCSI ), o qué tienes tú.

El problema principal es que los esquemas de nombres a menudo duran más que la razón detrás del esquema. Usted ve esto en /dev/scd0 . Es más probable que el dispositivo conectado a ese nodo /dev sea ​​una unidad de DVD o Blu-Ray que una unidad de disco compacto actualmente.

La alternativa, donde nombra cada nodo /dev después del tipo de dispositivo exacto que está conectado a ella, tiene sus propios problemas. ¿Sería realmente mejor si /dev nodo /dev después del protocolo de bajo nivel que usó? /dev/atapi0 , /dev/sas0 , etc.? ¿O tal vez prefiera /dev/atapibluray0 y tal? ¿Qué hay de las unidades multimedia? ¿El mismo controller también necesita exponer /dev/atapicd0 en caso de que deslice un disco compacto en la unidad de Blu-Ray? Eso simplemente reemplaza un esquema confuso con otro.

Linux /dev/sd? la abstracción no es perfecta, pero es útil. Por ejemplo, puede conocer el hecho de que /dev/sda es probablemente la unidad de inicio sin preocuparse por qué cableado, protocolo de interfaz y medios están detrás de ese nombre. Si le digo que una caja Linux determinada tiene una unidad de sistema única, una unidad óptica y, a veces, tiene una unidad USB miniatura conectada, puede adivinar con security que se llaman /dev/sda , /dev/sdb y /dev/sdc , respectivamente.


Notas al pie :

  1. SCSI y ATA no comenzaron a compartir una organización de estándares para padres. Ambos comenzaron como controlleres de disco duro patentados. SCSI evolucionó a partir de SASI de Shugart Associates , y ATA / IDE surgió de una queueboración de layout mucho más tardía entre Western Digital, Compaq y CDC.

    Posteriormente, ANSI estandarizó ambos, con ATA-1 siguiendo a SCSI-1 unos 8 años después.

    INCITS es una especie de organización hermana de ANSI . INCITS publica estándares finales a través de ANSI en los EE. UU. Y ISO / IEC JTC 1 en todo el mundo.

  2. El estándar actual es SAT-2 , cuando escribo esto a mediados de julio de 2014, pero se espera que sea reemplazado por SAT-3 más adelante en 2014.

    Un borrador del SAT-3 está disponible aquí para quienes hayan completado el formulario de notificación de huéspedes T10.

  3. Estoy ignorando los multiplicadores de puertos SATA , los expansores SAS , etc.

  4. Exceptuando los models hechos para la compatibilidad con los viejos sistemas SCSI paralelos.