Mal eine Frage an die Mechatroniker oder Elektronik Ingenieure oder eben
die, die dafür zuständig sind.
Nehmen mal an, wir haben eine 1000^4 = 1 TByte große Festplatte und
jeder Sektor ist 512 Byte groß, dann hat die Festplatte in LBA
Schreibweise 1953125000 Sektoren.
Weiter nehmen wir mal an, dass die Festplatte physikalisch real aus 3
Platten mit 6 realen Lese/Schreib-Köpfen besteht und beide Seiten der 3
Platten beschrieben werden können.
Die Sektoren liegen auf Kreisringen (Cylinder/Tracks/Spur) und die
Spuren weiter außen können mehr Sektoren speichern, als die Spuren
weiter innen.
Und jetzt soll der Lesekopf, der für die Scheibenseite verantwortlich
ist, auf dem LBA Sektor 3000000 liegt, so angefahren werden, dass dieser
Sektor gelesen werden kann.
Wie genau findet die Festplatte bzw. der Controller diesen Sektor nun?
Der muss ja wissen, wie weit er den Kopf nach innen oder außen bewegen
muss
um mit dem Lesekopf über der richtigen Spur zu sein und wie weit sich
die Platte einmal drehen muss, damit der Kopf sich direkt über dem
Sektor befindet, der ausgelesen soll.
Ich nehme mal an, dass auf dem Datenträger Low Level Hilfsdaten kodiert
nach irgendeinem Verfahren gespeichert sind, um diesen Sektor zu
erkennen und es eine Startposition gibt, die immer ganz leicht gefunden
werden kann und mit dem dann immer klar ist, wo eine Spur anfängt.
Aber wie genau wird der Sektor im Detail gefunden?
Nano schrieb:> Ich nehme mal an, dass auf dem Datenträger Low Level Hilfsdaten kodiert> nach irgendeinem Verfahren gespeichert sind
Wer noch Floppies in den Fingern gehabt hat, kennt diese "Hilfsdaten":
sie nennen sich ID-Feld und stehen am Anfang eines jeden Blocks.
Natürlich weiß der Controller auch irgendwoher, welche Zylinder mit
welcher Anzahl von Sektoren beschrieben werden. Damit hat er auch schon
eine Idee, wohin der Kopf bewegt werden muss, um einen bestimmten Block
zu finden. Mit dem ID-Feld wird nur nochmal verifiziert, dass man auch
genau den Block gelesen hat, den man haben wollte.
Jörg W. schrieb:> Nano schrieb:>> Ich nehme mal an, dass auf dem Datenträger Low Level Hilfsdaten kodiert>> nach irgendeinem Verfahren gespeichert sind>> Wer noch Floppies in den Fingern gehabt hat, kennt diese "Hilfsdaten":> sie nennen sich ID-Feld und stehen am Anfang eines jeden Blocks.> Natürlich weiß der Controller auch irgendwoher, welche Zylinder mit> welcher Anzahl von Sektoren beschrieben werden. Damit hat er auch schon> eine Idee, wohin der Kopf bewegt werden muss, um einen bestimmten Block> zu finden. Mit dem ID-Feld wird nur nochmal verifiziert, dass man auch> genau den Block gelesen hat, den man haben wollte.
Ok, die Erklärung macht Sinn.
Das Schreiben dieser "Header" ist übrigens genau das, was eine
Festplatte bei einem "Low Level Format" macht. Bei modernen Platten
kommt man meistens aber nicht mehr an diese Funktion ran.
Heute ist auch Servoinformation in den Spuren, damit der Kopf die Spur
exakt verfolgen kann. Das war vor Urzeiten eine eigene Oberfläche, was
schon aufgrund der Spurdichte und unterschiedlicher Wärmeausdehnung
längst nicht mehr möglich ist.
(prx) A. K. schrieb:> Heute ist auch Servoinformation in den Spuren, damit der Kopf die Spur> exakt verfolgen kann.
So ist es. Deswegen müssen beim (echten) low-level-Format die Köpfe
extern positioniert werden. Den Istwert für den Regelkreis liefert dann
ein Laser-Interferometer. Viele Platten haben seitlich einen mit einem
Aufkleber verschlossenen Schlitz. Da guckt das Ding rein.
Die SCSI- und ATA/SATA-Spezifikationen enthalten ein Kommando für
low-level-Format ("FORMAT UNIT"). Das macht bei modernen Platten aber
nur eine Oberflächenprüfung und löscht die Datenfelder, Header werden
nicht aufgefrischt.
Soul E. schrieb:> Header werden> nicht aufgefrischt.
Das bedeutet dann aber auch, dass die Stärke der Magnetisierung mit der
Zeit nachlassen dürfte. Ist das so korrekt?
Und falls ja, gibt es da Zeitangaben, wie lange das erhalten bleibt?
Nano schrieb:> Das bedeutet dann aber auch, dass die Stärke der Magnetisierung mit der> Zeit nachlassen dürfte. Ist das so korrekt?> Und falls ja, gibt es da Zeitangaben, wie lange das erhalten bleibt?
Korrekt. Bei modernen Platten (ab 1990) scheint das kein Problem zu
sein. Die alten Eisenschweine aus den '70ern und '80ern leiden in der
Tat unter nicht mehr lesbaren Headern.
Beim Apple betrifft das die ProFile (Seagate ST-506 Mechanik, mit
Schrittmotor) und das Widget (Eigenentwicklung, Voicecoil mit optischer
Grob- und magnetischer Feinpositionierung). Für die beiden haben wir
mittlerweile Lösungen zum low-level-Formatieren entwickelt. Die
"modernen" SCSI-Platten in den Macs scheinen unproblematisch zu sein. Da
kleben nur die Lager (Quantum ProDrive 40, 80, LPS120).
Beim PC hast Du die ST-412 (im IBM AT) und die ST-225 (in diversen
Kompatiblen). Die lassen sich beide über das BIOS des Controllers
formatieren ("debug", "C800:0008G" oder so ähnlich).
Soul E. schrieb:> Bei modernen Platten (ab 1990) scheint das kein Problem zu sein.
Wobei es zumindest bis vor so ca. 10 Jahren durchaus noch Platten gab,
die man "richtig" low-level formatieren konnte. Die konnte man dann auch
auf andere Blockgrößen umformatieren. Kann mich dran erinnern, dass
bspw. IBMs AIX zumindest eine zeitlang Platten mit 528 Bytes pro Block
formatieren wollte, um eigene ECC-Daten unterzubringen.
Jörg W. schrieb:> Wobei es zumindest bis vor so ca. 10 Jahren durchaus noch Platten gab,> die man "richtig" low-level formatieren konnte. Die konnte man dann auch> auf andere Blockgrößen umformatieren. Kann mich dran erinnern, dass> bspw. IBMs AIX zumindest eine zeitlang Platten mit 528 Bytes pro Block> formatieren wollte, um eigene ECC-Daten unterzubringen.
Wurden da wirklich die Tracks komplett neu angelegt? Dann müsste die
Platte zur Kopfpositionierung zumindest eine eigene Servoscheibe haben.
Schrittmotoren dürften ja 1990 schon ausgestorben sein.
Der Mac hatte 532 bytes pro Sektor. Die SCSI-Version der ST-225 aus der
HD20SC konnte man auch auf (weitgehend) beliebige Sektorgrößen
formatieren.
Rüdiger B. schrieb:> Dann müsste ich mal die alte 80MB SCSI Festplatte meines CPM System> anwerfen ob die noch zu lesen ist.
Bei diesen alten Platten konntest du noch vollwertige Low Level
Formatierungen durchführen.
Soul E. schrieb:> Wurden da wirklich die Tracks komplett neu angelegt?
Wie willst du sonst wahlfreie Blockgrößen implementieren? Das war ja
nicht nur 512 vs. 528, sondern meiner Erinnerung nach hätte man da auch
schon viel größere Blöcke schreiben können. Das wollte damals nur
keiner.
Ging aber wirklich nicht mit jeder Platte, und selbst das Schema, was
man dafür benutzt, war zwischen den Herstellern nicht einheitlich. Ich
erinnere mich nur noch vage, irgendwas war mit block description header
vs. irgendeiner mode page.
Zumindest habe ich irgendwann mal selbst eine Platte auf diese Weise
umformatiert. Ich weiß aber nicht mehr den Grund und in welche der
beiden Richtungen.
> Dann müsste die> Platte zur Kopfpositionierung zumindest eine eigene Servoscheibe haben.
Oder sie haben das anderweitig realisiert, indem sie bspw. den Zylinder
anhand der existierenden (eingebetteten) Servodaten angefahren haben und
dann die Position stabil halten und so alles neu schreiben. Man kann ja
die Servodaten auch in mehr als eine Spur einbetten, da jede Spur
einzeln geschrieben wird, zerstört man nicht alle Servodaten auf einmal.
Wie sie es genau machen, können dir wohl nur die Hersteller selbst
verraten.
Jörg W. schrieb:> Zumindest habe ich irgendwann mal selbst eine Platte auf diese Weise> umformatiert.
Bei Enterprise-Speichersystemen ist eine ungewöhnliche Sektorgrösse
ziemlich verbreitet. Ich hatte vor längerer Zeit einen Schwung Disks
eines ausgemusterten Systems mit einem Adaptec Controller auf 512 Bytes
umformatiert, um sie in Servern zu nutzen.
Soul E. schrieb:> Platte zur Kopfpositionierung zumindest eine eigene Servoscheibe haben.
Ich kann mir kaum vorstellen, dass eine separate Servoscheibe (dedicated
vs embedded servo) vor 10 Jahren noch möglich war. Immerhin hat jede
Scheibe ihre eigene Temperatur und bei hoher Spurdichte läuft das
entsprechend auseinander.
Zwar könnte man eine Servoscheibe nutzen, um eine Datenscheibe mitsamt
dortiger Servoinformation neu zu formatieren - aber wozu soll das gut
sein? Man verliert die Kapazität einer Scheibe, aber was gewinnt man
dadurch?
Nano schrieb:> Rüdiger B. schrieb:>> Dann müsste ich mal die alte 80MB SCSI Festplatte meines CPM System>> anwerfen ob die noch zu lesen ist.>> Bei diesen alten Platten konntest du noch vollwertige Low Level> Formatierungen durchführen.
Quantum ProDrive hatte optische Grob- und elektrische
Feinpositionierung. Da ging das. Die haben die Köpfe an der bestehenden
Spur ausgerichtet und dann alles außer dem Servo-Burst gelöscht und neu
geschrieben.
Quantum LPS (die flachen, Größe wie man sie heute kennt) konnten das
nicht mehr.
Jörg W. schrieb:> Wobei es zumindest bis vor so ca. 10 Jahren durchaus noch Platten gab,> die man "richtig" low-level formatieren konnte.
Kommt mir seltsam vor, da seit "zone bit recording" die Sektoranzahl pro
Spur nicht mehr konstant ist.
Und das war der Zeitpunkt, wo das "echte" Lowlevel-Format gekippt wurde
-- irgendwann kurz nach 1990.
DerEgon schrieb:> Kommt mir seltsam vor, da seit "zone bit recording" die Sektoranzahl pro> Spur nicht mehr konstant ist.
Naja, es heißt ja "zone", weil es eben Zonen sind mit unterschiedlicher
Bitanzahl. Insofern kann der Controller schon wissen, welche Zylinder zu
welcher Zone gehören.
Gewiss, das weiß er. Aber das kommuniziert er nicht nach draußen, die
Firmware gaukelt ein CHS- oder LBA-Mapping vor.
Wie das mit einem "echten" LL-Format einhergehen soll, ist mir nicht so
ganz klar. Was z.B. ist mit der Defektverwaltung?
Bei welchen Plattenmodellen hast Du so eine Fähigkeit beobachtet?
Vielleicht war das ja etwas "gehobeneres" Material als das übliche
08/15-Zeug, dem unsereins so begegnet.
Bist Du da im Rahmen Deiner Arbeit mit BSD draufgestoßen?
DerEgon schrieb:> Gewiss, das weiß er. Aber das kommuniziert er nicht nach draußen, die> Firmware gaukelt ein CHS- oder LBA-Mapping vor.
CHS gibt's bei SCSI nicht. Da gibt es nur logische Blocknummern.
Nach draußen kommunizieren muss die Platte diese Details nicht. Die
meldet sich hernach einfach mit einer neuen Anzahl logischer Blöcke,
wenn du sie danach fragst. Wie sie die intern aufteilt, ist ja rein ihr
Bier.
> Wie das mit einem "echten" LL-Format einhergehen soll, ist mir nicht so> ganz klar. Was z.B. ist mit der Defektverwaltung?
Die muss natürlich irgendwo erhalten bleiben. Bei SCSI gibt's ja die
permanent und die grown defect list. (Letztere darf man auch selbst
ergänzen.) Bezeichnend ist, dass nur das Format "bfi" (bytes from index)
für die Defektliste vorgeschrieben ist und von vielen auch nur das
unterstützt wird. Das zeigt also schon, dass die Platte wissen muss,
welches Byte innerhalb der Spur zu welchem Block gehört (und welcher
Ersatzblock ggf. dafür reingeholt werden muss).
Dem Vernehmen nach ist auch oftmals die Firmware selbst auf der Platte
gespeichert.
Gut möglich, dass für all dies ein paar (äußere) Zylinder reserviert
werden, da diese als über die Lebensdauer vertrauenswürdig angesehen
werden.
> Bei welchen Plattenmodellen hast Du so eine Fähigkeit beobachtet?
Kann ich dir jetzt nicht mehr sagen, ist zu lange her.
> Vielleicht war das ja etwas "gehobeneres" Material als das übliche> 08/15-Zeug, dem unsereins so begegnet.
Ja, SCSI war ja letztlich Inbegriff von Serverplatten, die durchaus
"etwas gehobener" sind gegenüber dem ganzen billigen IDE-Kram. Auch da
gab's Billigheimer, die zum Teil berüchtigt waren für schnell(er)e
Ausfälle, Quantum Fireball ist mir noch so in Erinnerung. Werden
irgendwelche Seagate oder Hitachi Teile gewesen sein.
> Bist Du da im Rahmen Deiner Arbeit mit BSD draufgestoßen?
Nicht direkt, aber das camcontrol-Kommando von FreeBSD ist recht
mächtig, damit kann man auch solche proprietären Dinge der Hersteller
bedienen.
DerEgon schrieb:> Gewiss, das weiß er. Aber das kommuniziert er nicht nach draußen, die> Firmware gaukelt ein CHS- oder LBA-Mapping vor.>> Wie das mit einem "echten" LL-Format einhergehen soll, ist mir nicht so> ganz klar. Was z.B. ist mit der Defektverwaltung?
Deswegen war low-level-Formatieren bei SCSI schon immer ein bisschen
Ansichtssache. Der Host hat ein FORMAT UNIT-Kommando, dass der an die
Platte schicken kann. Was die dann macht ist aber ihr überlassen. Viele
Platten prüfen dann nur ihre Sektoren und pflegen die grown defect list.
Format Track gibt es m.W. bei SCSI gar nicht. Das wäre ja auch sinnlos,
da man nur über LBA kommuniziert und nicht über Kopf- und
Zylinderangaben.
(S)ATA kennt Format Track, aber man kann die Spur-Rohdaten nicht
übergeben. D.h. was in den Headern drinsteht und wie die angelegt werden
enscheidet ebenfalls die Platte. Nur bei den ganz alten
MFM/RLL-Controllern hat man controller-seitig wirklich die einzelnen
Bits der Spur im RAM aufgebaut und dann rübergeschaufelt.
Soul E. schrieb:> Format Track gibt es m.W. bei SCSI gar nicht. Das wäre ja auch sinnlos,> da man nur über LBA kommuniziert und nicht über Kopf- und> Zylinderangaben.
Korrekt. Ob der Datenträger die Blöcke in Zylindern, Ellipsoiden oder
Würfeln ablegt, ist von außen nicht erkennbar. ;-)
Jörg W. schrieb:> Ja, SCSI war ja letztlich Inbegriff von Serverplatten, die durchaus> "etwas gehobener" sind gegenüber dem ganzen billigen IDE-Kram.
Mit SCSI konnte man vor allem die ganzen BIOS bezogenen 504 MiB und
8,4-GB Grenzprobleme, die es bei IDE gab, schön elegant umgehen.
SCSI war davon nicht betroffen.
https://de.wikipedia.org/wiki/CHS-Adressierung#504-MiB-Grenze
Außerdem entlastete der SCSI Controller die CPU und erlaubte, wenn ich
mich nicht irre, bis zu 7 Geräte. Gut möglich, dass das auf 15 erweitert
wurde, so genau weiß ich das aber nicht mehr.
Bei IDE waren nur 2 pro Anschluss möglich und da es nur 2 Anschlüsse
gab, war bei 4 Platten Schluss, wobei es auch sein kann, dass das erst
ab EIDI 4 Platten waren.
Außerdem konnte man bei SCSI die erste Platte, von der gebootet werden
soll, bequem per Software einstellen, die SCSI Controller hatten dafür
so ne Art eigenes Firmware BIOS, das man beim Booten per Tastendruck
aufrufen konnte und damit war man auch vom richtigen BIOS unabhängig.
Das bot sich dann auch für alte Rechner an, deren BIOS nicht mit den
neusten Entwicklungen mitzog.
Bei IDE musste man damals noch die Jumper bezüglich Master/Slave richtig
einstellen. Ein bequemes Einstellen per BIOS kam erst später.
IDE war somit einfach Schrott und SCSI richtig geil und ja, ich hatte
deswegen SCSI. Mitte der 90er waren die Preise der Platten auch recht
ähnlich zu den IDE Platten.
Erst später zogen die IDE Platten dann mit Platten mit deutlich mehr
Kapazität im Konsumerpreisbereich den SCSI Platten davon, so dass es
sich nicht mehr rentierte bei SCSI zu bleiben. Da war dann aber
ATA/ATAPI-4 und EIDE schon Standard und die gröbsten Nachteile bei IDE
somit beseitigt.
Natürlich gab es weiterhin größere SCSI Platten, aber deren Preise waren
zu dem Zeitpunkt dann jenseits von gut und böse.
Während man bei SCSI zu dem Zeitpunkt für die gleiche Summe nur ca. 8 GB
bekam, waren es bei EIDE 40 GB und da bin ich dann auch wieder zurück zu
EIDE gewechselt.
Nano schrieb:> Außerdem entlastete der SCSI Controller die CPU und erlaubte, wenn ich> mich nicht irre, bis zu 7 Geräte. Gut möglich, dass das auf 15 erweitert> wurde, so genau weiß ich das aber nicht mehr.
Ja, mit 16 bit Busbreite gingen auch 16 Targets (von denen man natürlich
mindestens eins für den HBA brauchte).
So viel hat aber selten jemand da dran gehängt.
> Bei IDE musste man damals noch die Jumper bezüglich Master/Slave richtig> einstellen. Ein bequemes Einstellen per BIOS kam erst später.
Naja gut, bei SCSI musstest du auch für jedes Target die ID-Jumper
festlegen. War aber keine Raketenwissenschaft.
> Erst später zogen die IDE Platten dann mit Platten mit deutlich mehr> Kapazität im Konsumerpreisbereich den SCSI Platten davon,
Weil man bei diesen massiv gespart hat. U.a. wurde dann die komplette
Verarbeitung in einen Controller gequetscht, während SCSI-Platten als
Serverplatten üblicherweise einen Controller für den Bus und einen für
die Platte (DSP) haben. Die Folge ist, dass eine IDE-Platte oft genug
das Interface warten lassen muss, während sie gerade Daten von der
Scheibe verarbeitet.
Außerdem konnten SCSI-Platten schon seit Jahrzehnten "tagged command
queueing", bei dem man ihr einfach eine Reihe Transaktionen in Auftrag
gibt und sie sucht sich die Abarbeitungsreihenfolge selbst aus. Bei IDE
gab's das Pendant NCQ erst kurz vor dem Ableben von Parallel-IDE (SATA
hat es natürlich übernommen).
Daher war der effektive Durchsatz bei hoher Systemlast (random IO) bei
SCSI-Platten um Welten besser. Das wurde eigentlich erst durch SSDs
später überholt.
Nano schrieb:> Mit SCSI konnte man vor allem die ganzen BIOS bezogenen 504 MiB und> 8,4-GB Grenzprobleme, die es bei IDE gab, schön elegant umgehen.> SCSI war davon nicht betroffen.
Diese Limits gab es zwar nicht, dafür aber andere. Mit einer 32 Bit LBA
und einem 10 Byte Command Descriptor Block ist bei 2 TB Ende der
Fahnenstange (512er Blöcke). Mit grösseren CDBs geht zwar mehr, aber das
muss dann nicht nur die Disk können, sondern auch der Rest des Systems.
Daran ist beispielsweise mancher nicht mehr frische RAID Controller
gescheitert.
Nano schrieb:> Außerdem entlastete der SCSI Controller die CPU und erlaubte, wenn ich> mich nicht irre, bis zu 7 Geräte. Gut möglich, dass das auf 15 erweitert> wurde, so genau weiß ich das aber nicht mehr.
Wobei da noch LUNs innerhalb eines Targets hinzu kommen. Das wird aber
nur bei grösseren Speichersystemen genutzt, oder für den Media Changer
eines Optik- oder Bandwechslers (*). Das Protokoll lebt ja bis heute
fort, nur die physikalische Schnittstelle wechselte zu ATAPI, USB, SSA,
SAS, iSCSI, Fibre Channel, ...
*: Da kann dann beispielsweise der Media Changer als zweite LUN eines
der Laufwerke auftauchen.
Jörg W. schrieb:>> Bei IDE musste man damals noch die Jumper bezüglich Master/Slave richtig>> einstellen. Ein bequemes Einstellen per BIOS kam erst später.>> Naja gut, bei SCSI musstest du auch für jedes Target die ID-Jumper> festlegen. War aber keine Raketenwissenschaft.
Ja, das ist richtig, man musste das aber nur einmal machen.
Das Bootdevice war danach jederzeit frei per Software einstellbar.
D.h. man muss nicht extra den Rechner aufschrauben, um das wieder zu
ändern, bei frühem IDE schon.
> Weil man bei diesen massiv gespart hat.
Ja, das ist mir bekannt, dass die SCSI Platten mehr "selber denken"
konnten.
> Außerdem konnten SCSI-Platten schon seit Jahrzehnten "tagged command> queueing", bei dem man ihr einfach eine Reihe Transaktionen in Auftrag> gibt und sie sucht sich die Abarbeitungsreihenfolge selbst aus. Bei IDE> gab's das Pendant NCQ erst kurz vor dem Ableben von Parallel-IDE (SATA> hat es natürlich übernommen).
Ja.
Jörg W. schrieb:> Bei IDE gab's das Pendant NCQ erst kurz vor dem Ableben von> Parallel-IDE (SATA hat es natürlich übernommen).
Wobei das NCQ m.W. mit AHCI einherging, der Abkehr von der uralten
IDE-Registerschnittstelle.
(prx) A. K. schrieb:> Wobei da noch LUNs innerhalb eines Targets hinzu kommen. Das wird aber> nur bei grösseren Speichersystemen genutzt, oder für den Media Changer> eines Optik- oder Bandwechslers (*).
1
Aug 3 00:25:28 kiste kernel: sa0 at mps0 bus 0 scbus8 target 3 lun 0
(prx) A. K. schrieb:> Jörg W. schrieb:>> Bei IDE gab's das Pendant NCQ erst kurz vor dem Ableben von>> Parallel-IDE (SATA hat es natürlich übernommen).>> Wobei das NCQ m.W. mit AHCI einherging, der Abkehr von der uralten> IDE-Registerschnittstelle.
Irgendwas gab's meiner Erinnerung nach auch vorher schon, aber spärlich
bis gar nicht oder buggy implementiert.
Nano schrieb:> Außerdem entlastete der SCSI Controller die CPU und erlaubte, wenn ich> mich nicht irre, bis zu 7 Geräte. Gut möglich, dass das auf 15 erweitert> wurde, so genau weiß ich das aber nicht mehr.
SCSI konnte auch host disconnect. Da konnte der Scanner seine Daten
direkt zur Platte schieben, statt erst zum PC und dann vom PC auf die
Platte. Wurde aber nur selten genutzt.
> Bei IDE waren nur 2 pro Anschluss möglich und da es nur 2 Anschlüsse> gab, war bei 4 Platten Schluss, wobei es auch sein kann, dass das erst> ab EIDI 4 Platten waren.
Das ist eine Entscheidung des PC-Bios. Für die 9 belegten Adressen hätte
sich auch öfter noch Platz im I/O-Bereich gefunden. D.h. mit
selbstgeschriebenem Treiber lief auch IDE-Bus Nr 3 und 4.
> IDE war somit einfach Schrott und SCSI richtig geil und ja, ich hatte> deswegen SCSI. Mitte der 90er waren die Preise der Platten auch recht> ähnlich zu den IDE Platten.
IDE war zunächst mal MFM/RLL mit in die Platte eingebautem Controller.
Das erlaubte solche Scherze wie variable Sektorzahl, variable Bitrate
etc. Was man einem diskreten WD1005 nur schwer hätte beibringen können.
Aus Sicht des PC verhielt sich IDE 1:1 wie ein RLL-Controller.
Später kamen dann neue Kommandos hinzu, für CD-Laufwerke etc.
Soul E. schrieb:> SCSI konnte auch host disconnect. Da konnte der Scanner seine Daten> direkt zur Platte schieben, statt erst zum PC und dann vom PC auf die> Platte. Wurde aber nur selten genutzt.
Ich hatte einen SCSI Scanner, allerdings war der an einem anderen
Rechner angeschlossen, der selbst nur (E)IDE Platten hatte.
Insofern hat mir das nichts gebracht, schneller als die SCcnner mit
Parallelport war der dann aber trotzdem.
Was mit SCSI aber auch noch möglich war, war, dass man damit den PC mit
einer DBox 1 verbinden konnte, wenn man deren Firmware durch eine andere
ersetzt hat.
So hatte man dann gleich ein brauchbares DVB-C Gerät.
