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?
Beitrag #7146896 wurde von einem Moderator gelöscht.
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.
:
Bearbeitet durch User
(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?
Dann müsste ich mal die alte 80MB SCSI Festplatte meines CPM System anwerfen ob die noch zu lesen ist.
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.
:
Bearbeitet durch Moderator
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.
Rüdiger B. schrieb: > https://de.wikipedia.org/wiki/Langzeitarchivierung#Haltbarkeit_der_Tr.C3.A4germedien https://www.daserste.de/information/wissen-kultur/w-wie-wissen/videos/archiv-menschheit-video-100.html#
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?
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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 |
2 | Aug 3 00:25:28 kiste kernel: sa0: <IBM ULT3580-HH5 F991> Removable Sequential Access SPC-4 SCSI device |
3 | Aug 3 00:25:28 kiste kernel: sa0: 600.000MB/s transfers |
4 | Aug 3 00:25:28 kiste kernel: ch0 at mps0 bus 0 scbus8 target 3 lun 1 |
5 | Aug 3 00:25:28 kiste kernel: ch0: <IBM 3573-TL D.00> Removable Changer SPC-3 SCSI device |
6 | Aug 3 00:25:28 kiste kernel: ch0: 600.000MB/s transfers |
7 | Aug 3 00:25:28 kiste kernel: ch0: Command Queueing enabled |
8 | Aug 3 00:25:28 kiste kernel: ch0: 22 slots, 2 drives, 1 picker, 1 portal |
;-) (Anbindung ist hier natürlich SAS.)
(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.
Du konntest auch ein Powerbook mit einem Macintosh koppeln und als externe Festplatte nutzen. Das Notebook war dann Device und nicht Host.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.