In che senso SATA “parla” di SCSI? Quanto viene condiviso tra SCSI e ATA?

Almeno non è una novità per me che SATA in realtà "parli" SCSI, quindi perché questi dispositivi SATA si presentano come dispositivi SCSI in Linux.

In precedenza è stata posta una domanda correlata, ad es. Perché i miei dispositivi SATA vengono visualizzati in / proc / scsi / scsi?

Tuttavia, ciò che non viene menzionato nel punto in cui ne ho già discusso prima è esattamente in che senso SATA si riferisce a SCSI e in che modo differiscono.

Presumo che si dia per scontato che differiscono sul livello fisico, in quanto non condividono cavi compatibili.

Tuttavia, che ne dici di salire in cima allo stack? Sono consapevole di come Linux rappresenti i dischi SATA e IDE sui kernel moderni come solo SCSI al sottosistema SCSI. Ma per quanto riguarda l'attuale protocollo utilizzato sul bus?

So anche che ATAPI è un incapsulamento per SCSI, ma che dire del normale ATA? Ho notato che le funzioni di SCSI come NCQ, FUA, DPO, ecc. (Se non ricordo male) sono state adottate da SCSI. Ma non è chiaro quanto "molto" del set di comandi SCSI sia effettivamente condiviso o simile.

I moderni dispositivi SATA con le loro specifiche ATA implementano un sottoinsieme del set di comandi SCSI, ma incapsulati (come in ATAPI)? Un set identico? Un superset? O forse solo le funzionalità selezionate sono implementate come varianti che non sono direttamente identiche?

Dove posso trovare alcune informazioni chiare su questo, e in particolare su come si collega al kernel Linux? Un qualche tipo di tutorial per lo sviluppo dei driver sarebbe carino, ma sarebbe sufficiente anche solo una panoramica che non salti completamente tutti i dettagli. Sono consapevole di poter semplicemente leggere le specifiche effettive, ma questo è di nuovo troppo dettagliato, difficile da trovare quello che stai davvero cercando, e semplicemente non realistico per me e probabilmente la maggior parte degli altri utenti in senso temporale.

SCSI e ATA sono standard completamente diversi. Attualmente sono entrambi sviluppati sotto l'egida dell'organizzazione degli standard INCITS ma da gruppi diversi. SCSI è sotto il comitato tecnico T10 , mentre ATA è sotto T13 . ¹

ATA è stato progettato pensando solo alle unità disco fisso. SCSI è sia più ampio che meno, essendo un modo standard per controllare dispositivi di archiviazione di massa, unità nastro, unità ottiche rimovibili (CD, DVD, Blu-Ray ...), scanner e molti altri tipi di dispositivi .

A metà degli anni '80, quando IDE fu introdotto nel mondo dei PC, non era ovvio che SCSI sarebbe stato spinto ai margini del mondo dell'informatica. SCSI era affermato e più capace. Workstation Unix e computer Macintosh forniti con unità disco fisso SCSI per decenni. I PC di fascia alta spesso avevano almeno una scheda SCSI per le periferiche e spesso anche per l'HDD del sistema. I primi CD-ROM e unità nastro per personal computer sono usciti prima in formato SCSI.

Essendo il settore dei PC quello che è, tuttavia, si è spinto a utilizzare lo standard ATA meno costoso anziché SCSI. Il compromesso iniziale era chiamato ATAPI , un'estensione di ATA che consente a un dispositivo che comprende SCSI internamente di ricevere quei comandi SCSI su un'interfaccia ATA. Maggiori informazioni su questo sotto.

Diversi anni dopo, SCSI ha ottenuto la funzione pass-through del comando ATA , sostanzialmente l'inverso di ATAPI, consentendo comandi ATA su un bus SCSI. Un uso per questa funzione è il tunneling dei comandi SMART ATA su SCSI. smartmontoolsfa questo , per esempio.

Successivamente, il comitato INCITS T10 ha sviluppato uno standard chiamato traduzione SCSI / ATA (SAT), che traduce i comandi SCSI in comandi ATA e viceversa. ² La libatalibreria del kernel Linux fornisce un'implementazione SAT per Linux, tra le altre cose .

Vi è una certa sovrapposizione logica nei protocolli SCSI e ATA, poiché entrambi controllano i dischi rigidi. Entrambi ovviamente hanno bisogno di un modo per cercare un particolare settore del disco rigido, recuperare i contenuti di quel settore, ecc. Tuttavia, i formati dei comandi sono completamente diversi; altrimenti, non avremmo bisogno di questi meccanismi di traduzione e pass-through.

SATA in realtà "parla" di SCSI

Questo è vero quanto l'affermazione che "Le auto sono rosa". Alcune macchine sono rosa.

ATAPI, ATA pass-through e SAT sono solo una parte della storia. Continuare a leggere.

Presumo che si dia per scontato che differiscono sul livello fisico, in quanto non condividono cavi compatibili.

Questo era vero nel vecchio mondo SCSI parallelo , ma proprio come SATA ha sostituito PATA, SAS ha sostituito SCSI parallelo.

SAS e SATA condividono gli stessi connettori di unità e sono elettricamente compatibili. Un controller SAS può comunicare con dispositivi SAS e SATA, ma un'unità SAS non può funzionare con un controller solo SATA. La differenza sta nella negoziazione e nei comandi che puoi usare dopo che i dispositivi su ciascuna estremità del cavo hanno capito con cosa stanno parlando.

In effetti, molti controller "SATA RAID" sono in realtà controller RAID SAS. Tali controller hanno spesso uno o più connettori di accoppiamento SFF-8087 SAS sulla scheda, ma è possibile collegare unità SATA ad essi con un cavo breakout SFF-8087 a 4 × SATA. Quindi, una scheda RAID SAS / SATA con due connettori di accoppiamento SFF-8087 controlla fino a 8 unità. ³

Un'altra situazione comune è un contenitore di unità hot-swap o un case di computer con un backplane SAS . Il backplane di solito ha un connettore SFF-8087, che consente l'uso di un semplice cavo da 8087 a 8087 dal backplane al controller del disco. Se le unità nei vassoi hot-swap sono SATA, non importa. Il controller SAS può parlare con loro tramite il cablaggio SAS, mentre siedono in slitte che collegano le unità al backplane SAS. Le unità sono ancora unità SATA, tuttavia, parlando del protocollo ATA, non di SCSI.

So anche che ATAPI è un incapsulamento per SCSI

Vero, ma ATAPI viene utilizzato solo per dispositivi diversi dalle unità disco fisso. Il motivo principale per cui esiste questo standard è consentire a un'interfaccia ATA di trasportare comandi SCSI come i comandi di streaming dati per un'unità nastro, il comando "espulsione supporti" per un'unità disco ottico o il comando "play track" per un disco audio CD .

Questo fatto sta diventando meno rilevante poiché i dispositivi non HDD che erano soliti parlare SCSI su ATAPI scompaiono o passano ad altre interfacce. Le unità nastro di fascia bassa non esistono più, quindi le unità nastro sono tutte SAS ora. ⁴ Scanner sono praticamente solo USB al giorno d'oggi. Le unità multimediali ottiche si stanno spostando all'esterno del case del computer per essere collegate tramite USB o scomparire del tutto, lasciando solo le sempre più rare unità ottiche interne che parlano ATAPI.

Indipendentemente da ciò, un dispositivo SATA che comprende SCSI su ATAPI è un "dispositivo SCSI" solo in modo limitato. Tali dispositivi non beneficeranno della maggior parte dei vantaggi di SAS su SCSI . Queste funzionalità rendono SAS nettamente prezioso rispetto a SATA, nonostante ATAPI.

Se vuoi un'altra analogia con l'auto, il fatto che io possa guidare la mia auto su una pista ovale non la rende un'auto da corsa.

Ho notato che le funzioni di SCSI come NCQ, FUA, DPO, ecc. (Se non ricordo male) sono state adottate da SCSI. Ma non è chiaro quanto "molto" del set di comandi SCSI sia effettivamente condiviso o simile.

Principalmente questo equivale a un mimetismo di fascia bassa. NCQ non è la stessa cosa di TCQ , per esempio. Otterrai un disco rigido con TCQ solo se si tratta di un dispositivo SAS. Collega un'unità SATA che supporta NCQ a un controller SAS e non ottiene improvvisamente la capacità TCQ.

Detto questo, un moderno dispositivo SATA potrebbe essere molto più capace di un dispositivo SCSI di un decennio fa. Sicuramente sarà in grado di livelli di I / O molto più alti.

Tutto ciò è confuso e sovrapposto perché questa è la natura del mondo dell'hardware per PC. Non ci sono linee chiare perché i produttori di unità ottiche - solo per scegliere un sottosettore - in realtà non vogliono costruire due unità completamente diverse, una che parla SAS alla sua massima espressione e l'altra che parla SATA. Quindi scendono a compromessi. Fanno pressioni nei comitati che definiscono tali standard per creare un unico standard che consenta loro di rilasciare la propria unità SATA su un bus SAS e tutti sono per lo più felici.

Dove posso trovare alcune informazioni chiare su questo, e in particolare su come si collega al kernel Linux?

Alla fine, vuoi leggere le fonti di Linux . Anche libATAla Guida per gli sviluppatori dovrebbe essere utile.

Non sono a conoscenza di alcun semplice riassunto di come tutto ciò funzioni. Non è stato progettato per essere facile. È stato progettato per adattarsi a tre decenni di evoluzione hardware, standard concorrenti e obiettivi diversi. Inoltre, è stato progettato senza magici livelli di lungimiranza. In breve, è un casino. Le uniche persone che devono davvero sapere come funziona il disordine sono quelle che creano i kernel del sistema operativo, quelli che progettano l'hardware e, in misura minore, quelli che scrivono i driver per i kernel del sistema operativo. Per un così piccolo gruppo di persone altamente capaci, gli standard e il codice di lavoro sono sufficienti.

Oggi Linux chiama la maggior parte dei dispositivi di archiviazione di massa riscrivibili /dev/sd?. "SD" un tempo significava "disco SCSI" ed esisteva semplicemente per differenziarsi dal /dev/hd?significato generico di "disco rigido", ma implicando PATA nella maggior parte dei casi. Questa distinzione è un'altra irrilevanza pratica oggi. Ora abbiamo SSD, chiavette USB, dischi rigidi virtuali , dispositivi iSCSI e altro ancora tutti chiamati /dev/sd?. Ti suggerisco di iniziare a pensare a "SD" come abbreviazione di "dispositivo di archiviazione", piuttosto che preoccuparti se il dispositivo parla ATA su SATA, ATA su Ethernet , SCSI su USB , SCSI su ATAPI, SCSI su SAS, SCSI su IP (iSCSI ) o cosa hai.

Il problema principale è che gli schemi di denominazione spesso sopravvivono al motivo alla base dello schema. Lo vedi in /dev/scd0. Al giorno d'oggi il dispositivo collegato a quel /devnodo ha più probabilità di essere un'unità DVD o Blu-Ray rispetto a un'unità Compact Disc.

L'alternativa - in cui si assegna un nome a ciascun /devnodo in base al tipo esatto di dispositivo collegato ad esso - ha i suoi problemi. Sarebbe davvero meglio se chiamassimo il /devnodo con il protocollo di basso livello che ha usato? /dev/atapi0, /dev/sas0ecc.? O forse preferiresti /dev/atapibluray0e così? Che dire delle unità multimediali? Lo stesso driver deve anche esporre /dev/atapicd0nel caso in cui si fa scorrere un Compact Disc nell'unità Blu-Ray? Ciò sostituisce solo uno schema confuso con un altro.

L' /dev/sd?astrazione di Linux non è perfetta, ma è utile. Ad esempio, è possibile sapere che /dev/sdaè molto probabile che l'unità di avvio non si preoccupi di preoccuparsi di quali cavi, protocolli di interfaccia e supporti sono dietro quel nome. Se ti dico che una data macchina Linux ha una sola unità di sistema, un'unità ottica, e talvolta ha una chiavetta USB inserita in esso, si può tranquillamente immaginare che essi sono chiamati /dev/sda, /dev/sdbe /dev/sdc, rispettivamente.

Note a piè di pagina :

1. SCSI e ATA non hanno iniziato a condividere un'organizzazione di standard parent. Entrambi hanno iniziato come controller di disco rigido proprietari. SCSI si è evoluto da Shugart Associates ' SASI , e ATA / IDE è venuto fuori di una collaborazione di progettazione molto più tardi tra Western Digital, Compaq e CDC.

   ANSI ha successivamente standardizzato entrambi, con ATA-1 dopo SCSI-1 circa 8 anni dopo.

   INCITS è una specie di organizzazione gemella di ANSI . INCITS pubblica gli standard finali tramite ANSI negli Stati Uniti e ISO / IEC JTC 1 in tutto il mondo.

2. Lo standard attuale è SAT-3 , pubblicato a maggio 2015, con SAT-4 e SAT-5 in corso mentre scrivo questo a metà luglio 2018. Quest'ultimo link vi porta a bozze delle versioni in corso.

3. Sto ignorando i moltiplicatori di porte SATA , gli espansori SAS , ecc.

4. Tranne i modelli realizzati per la compatibilità con i vecchi sistemi SCSI paralleli.