SATA hangi anlamda SCSI ile konuşmaktadır? SCSI ve ATA arasında ne kadar paylaşılır?


27

Bu benim için en azından yeni bir şey değil, SATA aslında SCSI ile "konuşuyor", bu yüzden bu SATA aygıtları Linux'ta SCSI aygıtları olarak gösteriliyor.

Daha önce ilgili bir soru soruldu, örneğin SATA cihazlarım neden / proc / scsi / scsi altında görünüyor?

Bununla birlikte, daha önce tartışıldığını gördüğümde bahsetmediğimiz şey, SATA'nın SCSI ile tam olarak ne anlama geldiğiyle ve nasıl farklılık gösterdikleridir.

Uyumlu kabloları paylaşmadıkları için fiziksel katman üzerinde farklı oldukları kabul edildiğine inanıyorum.

Ancak yığında daha yüksek ne olur? Linux'un SATA'yı ve hatta IDE disklerini modern çekirdeklerde SCSI alt sistemine SCSI olarak nasıl temsil ettiğini biliyorum. Peki ya otobüste kullanılan asıl protokol?

Ayrıca ATAPI'nin SCSI için bir kapsülleme olduğunu da biliyorum, peki ya normal ATA? NCQ, FUA, DPO vb. Gibi SCSI özelliklerinin (yanlış hatırlamıyorsam) SCSI'dan kabul edildiğini fark ettim. Ancak SCSI komut setinin ne kadarının "ne kadar" gerçekten paylaşıldığı ya da benzer olduğu açık değildir.

ATA özelliklerine sahip modern SATA aygıtları, SCSI komut kümesinin bir alt kümesini uygular, ancak kapsüllenir (ATAPI'deki gibi) mi? Aynı bir set mi? Süper market mi? Ya da belki de yalnızca seçilen özellikler doğrudan özdeş olmayan değişkenler olarak uygulanır?

Bununla ilgili bazı net bilgileri nerede bulabilirim ve özellikle bunun Linux çekirdeği ile ilgisi nedir? Sürücü gelişimi için bir tür öğretici hoş olurdu, ancak sadece tüm ayrıntıları tamamen geçmeyen bir genel bakış bile yeterli olacaktır. Ben sadece asıl özellikleri okuyabildiğimin farkındayım, ancak bu gerçekten çok araştıran, gerçekte aradığınızı bulmak zor ve sadece ve muhtemelen zamansal anlamda çoğu kullanıcı için gerçekçi değil.

Yanıtlar:


42

SCSI ve ATA tamamen farklı standartlar. Şu anda her ikisi de INCITS standartlar organizasyonu himayesinde fakat farklı gruplar tarafından geliştiriliyor. SCSI T10 teknik komitesinde , ATA ise T13 altında . 1

ATA, sadece sabit disk sürücüleri düşünülerek tasarlandı. SCSI, daha geniş ve daha eski olup, yığın depolama aygıtlarını, manyetik bant sürücülerini, çıkarılabilir optik ortam sürücülerini (CD, DVD, Blu-Ray ...), tarayıcıları ve diğer birçok aygıt türünü kontrol etmenin standart bir yoludur .

1980'lerin ortalarında - IDE PC dünyasına tanıtıldığında - SCSI'nin bilgisayar dünyasının sınırlarına zorlanacağı açık değildi. SCSI köklü ve daha yetenekliydi. Unix iş istasyonları ve Macintosh bilgisayarlar, yıllardır SCSI sabit disk sürücüleri ile gönderilir. High-end PC'lerde en azından çevre birimleri ve en azından sistem HDD'si için bir SCSI kartı bulunur. İlk önce CD-ROM ve kişisel bilgisayarlar için teyp sürücüleri ilk SCSI biçiminde çıktı.

PC endüstrisi, olduğu gibi, SCSI yerine daha az pahalı olan ATA standardını kullanmak için bir baskı vardı. İlk uzlaşmaya, ATSI'nin , SCSI'yi dahili olarak anlayan bir aygıtın, bir ATA arayüzü üzerinden bu SCSI komutlarını almasını sağlayan ATA'nın bir uzantısı olarak adlandırıldı . Bu konuda daha fazlası.

Birkaç yıl sonra, SCSI, ATA'nın bir SCSI veri yolu üzerinden ATA komutlarına izin vermesini sağlayan, temel olarak ATAPI'nin tersi olan ATA komut geçiş özelliğini aldı. Bu tesis için bir kullanım ATA SMART komutlarını SCSI üzerinden tünellemektir . örneğin smartmontoolsbunu yapar .

Daha sonra, INCITS T10 komitesi SCSI komutlarını ATA komutlarına çeviren ve bunun tersi olan SCSI / ATA Translation (SAT) adlı bir standart geliştirdi. 2 Linux çekirdeği libatakütüphanesi , diğer şeylerin yanı sıra Linux için SAT uygulaması sağlar .

Her ikisi de sabit disk sürücülerini kontrol ettiği için SCSI ve ATA protokollerinde bazı mantıksal örtüşmeler var. Her ikisi de belli bir sabit disk sektörünü aramak, o sektörün içeriğini vb. Almak için bir yola ihtiyaç duyuyor. Yine de komut biçimleri tamamen farklı; Aksi takdirde, bu çeviri ve geçiş mekanizmalarına ihtiyacımız olmaz.

SATA aslında SCSI'yi "konuşuyor"

Bu, "Arabalar pembedir" iddiası kadar doğrudur. Bazı arabalar pembe.

ATAPI, ATA geçişi ve SAT hikayenin sadece bir kısmı. Okumaya devam etmek.

Uyumlu kabloları paylaşmadıkları için fiziksel katman üzerinde farklı oldukları kabul edildiğine inanıyorum.

Eski paralel SCSI dünyasında bu doğruydu , ancak SATA PATA'nın yerine SAS de SCSI'nin yerini aldı.

SAS ve SATA aynı sürücü konektörlerini paylaşır ve elektrikle uyumludur. Bir SAS denetleyicisi SAS ve SATA aygıtlarıyla konuşabilir, ancak bir SAS sürücüsü yalnızca SATA denetleyicisiyle çalışamaz. Aradaki fark müzakere ve kablonun her iki ucundaki aygıtlardan sonra ne konuştuklarını öğrendikten sonra kullanabileceğiniz komutlarda.

Aslında, birçok "SATA RAID" denetleyicisi gerçekten SAS RAID denetleyicileridir. Bu tür kontrol cihazlarında genellikle kartta bir veya daha fazla SFF-8087 SAS eşleşme konektörü bulunur, ancak SATA sürücülerini bir SFF-8087 ila 4 × SATA koparma kablosu ile bağlayabilirsiniz. Böylece, iki SFF-8087 çiftleşme konektörüne sahip bir SAS / SATA RAID kartı 8 sürücüye kadar kontrol eder. 3

Diğer bir yaygın durum, çalışırken değiştirilebilir bir sürücü kasası ya da SAS arka paneline sahip bir bilgisayar kasasıdır . Arka panel üzerinde genellikle bir SFF-8087 konektörü bulunur ve arka panelden disk denetleyicisine 8087'den 8087'ye kadar basit bir kablo kullanılmasına izin verir. Çalışırken değiştirilebilir tepsilerdeki sürücüler SATA ise, sorun değil. SAS denetleyici, sürücüleri SAS arka paneline bağlayan sürücü kızaklarına oturdukları için onlarla SAS kablosu üzerinden konuşabilir. Sürücüler, yine de, SCSI değil, ATA protokolünü konuşan SATA sürücüleridir.

Ayrıca ATAPI'nin SCSI için bir kapsülleme olduğunu da biliyorum.

Doğru, ama ATAPI cihazlar için kullanılan diğer sabit disk sürücülere göre. Bu standardın var olmasının ana nedeni, ATA arabiriminin bir teyp sürücüsü için akış verileri komutları, SCSI komutlarını bir optik disk sürücüsü için "ortam çıkarma" komutu veya bir CD ses diski için "oynatma parçası" komutu gibi aktarmasını sağlamaktır. .

ATAPI üzerinden SCSI konuşan eski HDD olmayan cihazlar kaybolduğu veya diğer arayüzlere geçtiği için bu gerçek daha az önem kazanıyor. Düşük kaliteli teyp sürücüleri artık mevcut değil, bu nedenle teyp sürücülerinin hepsi artık SAS. 4 Tarayıcılar bugünlerde sadece USB içindir. Optik medya sürücüleri , ATAPI konuşan sadece nadiren görülen dahili optik sürücüleri bırakarak, USB üzerinden bağlanacak bilgisayar kasasının dışına doğru hareket ediyor veya tamamen yok oluyor.

Her şeye rağmen, ATAPI üzerinden SCSI'yi anlayan bir SATA cihazı, yalnızca sınırlı bir şekilde bir "SCSI cihazı" dır. Bu tür aygıtlar , SAS'ın SCSI üzerindeki avantajlarının çoğundan yararlanamayacaktır . Bu yetenekler SAS'ı, buna rağmen SATA, ATAPI ile karşılaştırıldığında belirgin bir şekilde değerli kılar.

Başka bir araba benzetmesi istiyorsanız, arabamı oval bir yarış pistinde çalıştırabilmem onu ​​yarış arabası yapmaz.

NCQ, FUA, DPO vb. Gibi SCSI özelliklerinin (yanlış hatırlamıyorsam) SCSI'dan kabul edildiğini fark ettim. Ancak SCSI komut setinin ne kadarının "ne kadar" gerçekten paylaşıldığı ya da benzer olduğu açık değildir.

Çoğunlukla bu düşük seviye taklit anlamına gelir. NCQ, örneğin TCQ ile aynı şey değildir . Sadece bir SAS aygıtı ise TCQ ile sabit disk elde edersiniz. NCQ özellikli bir SATA sürücüyü SAS denetleyicisine takın ve aniden TCQ yeteneği kazanmaz.

Bununla birlikte, modern bir SATA cihazı on yıl öncesine kadar bir SCSI cihazından çok daha yetenekli olabilir. Kesinlikle çok daha yüksek seviyelerde G / Ç yapabilecektir.

Tüm bunlar kafa karıştırıcı ve örtüşüyor çünkü PC donanım dünyasının doğası bu. Net çizgiler yok çünkü optik sürücü üreticileri - yalnızca bir alt endüstriyi seçmek için - biri tamamen farklı iki sürücü oluşturmak istemiyor, biri en yüksek ifadesine SAS konuşan, diğeri de konuşan SATA. Böylece ödün veriyorlar. SATA sürücülerini SAS veriyoluna bırakmalarını sağlayan tek bir standart oluşturmak için bu standartları belirleyen komitelerde lobi yapıyorlar ve herkes çoğunlukla mutlu oluyor.

Bununla ilgili bazı net bilgileri nerede bulabilirim ve özellikle bunun Linux çekirdeği ile ilgisi nedir?

Sonuçta, Linux kaynaklarını okumak istersiniz . libATAGeliştirici Kılavuzu de yararlı olmalıdır.

Tüm bunların nasıl çalıştığının kolay bir özetinin farkında değilim. Kolay olacak şekilde tasarlanmadı. Otuz yıllık donanım evrimi, rekabet eden standartlar ve farklı hedeflere uyum sağlamak için tasarlanmıştır. Ayrıca, büyülü öngörü seviyeleri olmadan tasarlanmıştır. Kısacası, bu bir karmaşa. İşin nasıl yürüdüğünü gerçekten bilmek zorunda olan insanlar, işletim sistemi çekirdeği kuranlar, donanımı tasarlayanlar ve daha az ölçüde işletim sistemi çekirdeği için sürücü yazan kişilerdir. Çok yetenekli insanlardan oluşan küçük bir kadro için, standartlar ve çalışma kodu yeterlidir.

Bugün, Linux çoğu yeniden yazılabilir yığın depolama cihazını çağırıyor /dev/sd?. "SD", bir zamanlar "SCSI disk" için duruyordu ve yalnızca /dev/hd?genel olarak "Sabit Disk" anlamına gelen, ancak çoğu zaman PATA anlamına gelmek için ayrılıyordu. Bu ayrım günümüzde başka bir pratik sorunludur. Şimdi SSD'lerimiz, USB flaş sürücülerimiz, sanal sabit sürücülerimiz , iSCSI cihazlarımız ve daha fazlasımız var /dev/sd?. Aygıtın SATA, Ethernet üzerinden ATA , USB üzerinden SCSI, ATAPI üzerinden SCSI, SAS üzerinden SCSI, IP üzerinden SCSI (iSCSI) hakkında endişelenmek yerine, "SD" yi kısaca "depolama aygıtı" olarak düşünmeye başlamanızı öneririm. ) ya da neyin var.

Temel problem, adlandırma şemalarının, genellikle programın arkasındaki nedeni aşmasıdır. Bunu içeride görüyorsunuz /dev/scd0. Bu /devdüğüme bağlı cihazın , bugünlerde bir Kompakt Disk sürücüsünden daha fazla DVD veya Blu-Ray sürücüsü olması daha muhtemeldir.

Alternatif - her bir /devdüğümü kendisine bağlı olan tam cihaz tipinden sonra adlandırdığınız yerin - kendi sorunları vardır. /devKullandığımız düşük seviyeli protokolden sonra düğümü isimlendirsek daha iyi olur mu? /dev/atapi0, /dev/sas0vb? Ya da belki tercih edersin /dev/atapibluray0? Peki ya çoklu ortam sürücüleri? /dev/atapicd0Bir CD'yi Blu-Ray sürücüsüne kaydırmanız durumunda aynı sürücünün de gösterilmesi gerekiyor mu? Bu sadece bir kafa karışma düzenini diğeriyle değiştirir.

Linux'un /dev/sd?soyutlama mükemmel değil, ama yararlıdır. Örneğin /dev/sda, önyükleme sürücüsünün büyük olasılıkla hangi kablolama, arabirim protokolü ve ortamın bu adın arkasında olduğu konusunda endişelenmenize gerek kalmadan gerçeğini öğrenebilirsiniz . Sana söylersem verilen bir Linux kutu tek sistem sürücü, optik sürücü vardır ve bazen takılı bir USB sürücüyü sahip olduğunu, artık rahatça dedikleri olduğunu tahmin edebilirsiniz /dev/sda, /dev/sdbve /dev/sdcsırasıyla.


Dipnotlar :

  1. SCSI ve ATA, bir ana standartlar organizasyonunu paylaşmaya başlamadı. Her ikisi de tescilli sabit disk denetleyicileri olarak başladı. SCSI evrimleştiği Shugart Associates ' AABE'nin ve ATA / IDE çıkmış bir daha geç tasarım işbirliği Western Digital, Compaq ve CDC arasında.

    ANSI daha sonra her ikisi de standartlaştı, yaklaşık 8 yıl sonra SCSI-1'in ardından ATA-1.

    INCITS, ANSI’nin bir tür kardeş kuruluşudur . INCITS, ABD’de ANSI ve dünya çapında ISO / IEC JTC 1 aracılığıyla nihai standartları yayınlar .

  2. Mevcut standart, Mayıs 2015'te yayınlanan SAT-3'tür ve SAT-4 ve SAT-5 , Temmuz 2018 ortasında yazdığım sırada devam ediyor . İkinci bağlantı, devam eden sürümlerin taslaklarına götürür.

  3. SATA bağlantı noktası çarpanlarını , SAS genişleticilerini vb. Görmezden geliyorum .

  4. Eski paralel SCSI sistemlerine uyumluluk için yapılan modeller hariç.


Bazı özelliklerin / komut kümelerinin ATA ve SCSI'de aynı olup olmadığı ve eğer varsa bu birliğin ne kadar büyük olduğu hala net değil. Linux kaynak kodunu okumanın bazı cevaplar vereceği konusunda hemfikirim, ancak muhtemelen ATA spesifikasyonunun kendisini okumakla aynı seviyede. Linux kaynağı muhtemelen, ne kadar paylaşıldığı ve ATA ile SCSI arasında nasıl paylaşıldığı konusunda net bir görüş vermeyecektir. Kullanılan adlandırma kuralları, Linux kaynağının okunmasıyla muhtemelen daha aydınlanacaktır.
AttributedTensorField

@AttributedTensorField: En son düzenlemeleri görün.
Warren Young,

1
Vay, harika cevap. Sadece bir şey; / dev / atapi0, / dev / sas0 vb .; BSD’lerin (en azından FreeBSD’nin) yaptığı şey bu değil mi? Solaris IIRC'nin yanı sıra. Ve Linux'ta genellikle benzer şekilde / dev / disk / by-path var.
CVn

@ MichaelKjörling: Tabii. Yorumun amacı, bu şeylere bakmanın diğer yollarının yanlış olması değil, altta olanları daha iyi eşleştirmek için adlandırma düzenini değiştirmenin altta yatan sorunun ortadan kalkmasına neden olmamasıdır. Birincisi, Linux'un /dev/sd?soyutlamasını takdir ediyorum .
Warren Young,

1
Bugünlerde çoğu dağıtımın, optik sürücüleri / dev'in / N'nin sayı olduğu / dev / srN olarak gösterdiğini unutmayın.
Perkins,
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.