Alternative SCSI Bridges auf Narrow SCSI 50-polig ?

  • Hallo zusammen,


    das leidige Thema "Ersatz" ...

    Ich bin aktuell auf der Suche nach alternativen SCSI-Bridges für meine SPARCstation 2.

    In 2017 hatte ich mir noch eine Acard ARS-2000SUP Bridge für ca 230 EUR zugelegt. Inzwischen sind die Preise für diese Bridge nicht mehr bezahlbar (beim Anbieter san2_inc für die verfügbaren Stücke bei ~2.000 USD je Stück) =O.

    Meine Suchergebnisse

    Scheines alles Compact Flash Speicher zu sein, die für UNIX bzw. deren ältere Treiber nicht optimal sind. UNIX schreibt fast ständig auf die Platte, seien es Logeinträge, durch Paging oder halt Nutzerdaten. Und wenn der (alte) Treiber nicht dafür sorgt, dass eine Verteilung der Schreibvorgänge von Datenblöcke auf alternative Speicheradressen stattfindet, dann hält das CF/SD-Medium evtl. nur 10 Jahre. Alles nicht optimal. Ein Neuaufsetzen des OS dauert immer so lange, wenn man kein Backup fährt... 8o


    Aktuell kann ich noch auf sehr günstige , externe Sun 611 UniPack's zurückgreifen, in denen sich SCA80 Platten verbauen lassen, die ich dann über Adapterkabel von 68-polig auf 50-polig an die SS2 anstöpsel.


    Habt ihr noch Bridge-Alternativen in euren Fundus bzw. könnte ggf aus urer Erfahrung zum Einsatz in UNIX-artigen Systemen berichten?


    Gruß, Stephan

  • Das war auch nicht wirklich ernst gemeint. ;)

    Dennoch kennen die alten Treiber die neueren Speicher (i.d.R.) nicht, um diese effektiv zu nutzen.


    Ja, eine Möglichkeit wäre mit ODS/SDS/SVM ein Mirror aufzusetzen. Das halbiert das Risiko beinahe. Dann hilft nur noch das Backup vom System selbst, entweder über NFS oder per Tape.


    Die Lösung von CF2SCSI fand ich auch nicht übel, zwei CF-Karten schon direkt in der Bridge inhaltlich zu spiegeln und das OS sieht trotzdem von Anfang an nur eine virtuelle Platte. Nur gesehen habe ich das zum Kaufen noch nirgends. Muss meine Suche mal noch etwas verfeinern.

  • Irgendwo habe ich mal einen CF zu SD-Adapter gesehen (in eBay?), in den man 2 Mini-SDs reinsteckt. Der Adapter macht daraus ein Laufwerk, also ein Raid-0, das heißt die Belastung der einzelnen SD-Karte wird halbiert. Vielleicht ist das ja ein Weg?

  • Hier steht noch ein verstaubtes Sun 411 Gehaeuse, welches ich fuer wenige Taler abgeben wuerde. Es ist keine Bridge drin, aber es passt optisch besser zur ss2 und es ist kein 50/68 Adapter noetig. Alternativ auch ein Sun Multipack fuer SCA-Platten.

  • Irgendwo habe ich mal einen CF zu SD-Adapter gesehen (in eBay?), in den man 2 Mini-SDs reinsteckt. Der Adapter macht daraus ein Laufwerk, also ein Raid-0, das heißt die Belastung der einzelnen SD-Karte wird halbiert. Vielleicht ist das ja ein Weg?

    Ich habe einen solchen Adapter auch gefunden aber da steht nichts von "spiegeln" sondern "aufteilen" der Daten:



    Das CF-Adapter bildet ein Array, wenn Sie zwei microSD-Karte in den Adapter einsetzen. Was bedeutet, dass es Daten teilt gleichmäßig über zwei TF-Karte, und
    bietet keine Fehlertoleranz oder Redundanz, der Ausfall einer Karte wird die gesamte Anordnung verursachen, um dieses Ergebnis insgesamt Datenverlust ausfallen.


    pkffm Wenn du den nicht zwingend brauchst melde dich mal per PM bei mir mit deiner Preisvorstellung. So ein externes Festplattengehäuse (ohne 5,25" Einlass in der Front) könnte ich tatsächlich für die SS2 gut gebrauchen. Das spart mir den lästigen Aus-/Ein-/Umbau, wenn ich die Ersatz-SS2 mal in Betrieb nehme oder teste. ::solder::

  • An den Gehäusen hätte ich ja evtl. auch Interesse !



    Ansonsten benutze ich für den Anschluß alter IDE Platten an alte SCSI Karten diesen Adapter hier


         


    Funktioniert(e) auch mit großen Platten gut (SS10 an 750GB).


    Vermutlich lassen sich da auch CF Adapter anhängen, was ich aber nie probiert habe. Noch gibt es IDE Platten.


    Für Fixinstallationen ist aber auf lange Sicht wahrscheinlich so ein SD-Card Adapter mal sinnvoll oder gleich mehrere (wunsch,träum) oder ein Server mit NFS o.ä.; Booten sollte auch mit einer SS2 eigentlich schon darüber machbar sein. Bei den SD-Karten stelle ich mir irgendwie vor, daß man einfach Images auf Platten legt und wenn eine SD Karte kapput geht, wird einfach eine neue genommen (was natürlich auch wieder ein kleine Lagerhaltung erfordert, aber das sollte bei 1-2GB SD-Cards o.ä. zumindest platztechnisch kein Problem sein). So von der Art gefällt mir ja das SCSI2SD mit am Besten, oder das CF2SCSI (Punkt 3 und 4 aus der Liste).

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • An den Gehäusen hätte ich ja evtl. auch Interesse !

    Wie "evtl."!? :/- Ich habe noch keine Preisvorstellung von pkffm. Bin ja mal gespannt. :capone:


    Der Adapter ist auch von ACARD (AEC-7720U) und ist in der Tat noch bezahlbar (ca. 200 EUR). Alternativ sollte dann auch der AEC-7732U (SATA --> SCSI 50pol, "U" am Ende wichtig) funktionieren. Dazu muss ich mich nochmal schlau machen.


    NFS-Boot geht glücklicherweise immer bei den Systemen. Die Installation läuft bei mir immer über 'nen Jumpserver. Das wäre tatsächlich die beste Lösung für zu Hause. Für eine Retro-LAN oder dergleichen müsste man sich dann aber noch einen kleinen, mobilen NFS-Server konfigurieren und mitnehmen. Das ist jetzt nicht so meine Idealvorstellung aber man hat dann auch gleich was zum Zeigen. Auch nicht schlecht. Ich behalte das mal im Hinterkopf für die nächste CC.

  • Ich habe einen solchen Adapter auch gefunden aber da steht nichts von "spiegeln" sondern "aufteilen" der Daten:

    Ich habe auch nirgends was von Spiegeln geschrieben. RAID 0 ist ein Stripeset, abwechselnd ein Sektor hier, einer da.


    ThoralfAsmussen Der SCSI-zu-IDE-Adapter den du da hast, ist heute rar und teuer. Aber wenn man da einen IDE-zu-CF-Adapter dran hängt, kann man auch gleich einen SCSI2SD nehmen, der dann noch den Vorteil hat, dass er gleichzeitig bis zu vier SCSI-Patten mit eigener SCSI-ID auf einer SD-Karte simultiert. Damit kann man dann Größenbeschränkungen von Betriebsssystemen und SCSI-Firmwares nett umgehen.

    1ST1

  • Der SCSI-zu-IDE-Adapter den du da hast, ist heute rar und teuer. Aber wenn man da einen IDE-zu-CF-Adapter dran hängt, kann man auch gleich einen SCSI2SD nehmen, der dann noch den Vorteil hat, dass er gleichzeitig bis zu vier SCSI-Patten mit eigener SCSI-ID auf einer SD-Karte simultiert.


    Der kam auch aus einer Ecke, wo Ǵeld vermutlich nicht so die Rolle gespielt hat, wenn dafür das Gerät ordentlich funktionierte. Und vermutlich war es sogar noch wesenlich preiswerter, als eine große echte SCSI Platte zu benutzen.


    Das mit den 4 "Platten" ist natürlich eine wichtige Zusatzinfo ! Sehr praktisch.


    Wie "evtl."!? :/


    Na ja, das Angeot war ja speziell für Dich gedacht, denk ich mir.

    Wollte nur mal so ansagen, daß es evtl. auch andere Interessenten geben könnte. V.a. die Multi-Box finde ich nett. 411er habe ich da.


    Bei den 411ern muß man beim Öffnen unbedingt vorsichtig sein, sonst bricht man innen die Plastikhalter ab - und das Öffnen selbst ist auch nicht direkt einfach. Anleitung gibts hier und da.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Ich habe einen solchen Adapter auch gefunden aber da steht nichts von "spiegeln" sondern "aufteilen" der Daten:

    Ich habe auch nirgends was von Spiegeln geschrieben. RAID 0 ist ein Stripeset, abwechselnd ein Sektor hier, einer da.

    :wand: Ja, ja, lesen will ja auch gelernt sein, net!? :fp:


    Hinsichtlich Belastung wäre das in der Tat eine Möglichkeit. Das halbiert zwar den Schreibbedarf einer Karte aber es bleiben i.d.R. immer die selben Speicheradressen. Damals konnte ich mich zu einem Kauf dieses Adapters nicht entschließen, war allerdings für den SNI PCD-3M (x86) gedacht, nicht für die SS2.


    EDIT:

    Na ja, das Angeot war ja speziell für Dich gedacht, denk ich mir.

    Wollte nur mal so ansagen, daß es evtl. auch andere Interessenten geben könnte. V.a. die Multi-Box finde ich nett. 411er habe ich da.


    Bei den 411ern muß man beim Öffnen unbedingt vorsichtig sein, sonst bricht man innen die Plastikhalter ab - und das Öffnen selbst ist auch nicht direkt einfach. Anleitung gibts hier und da.

    Schon klar. Ich bin halt gern albern unterwegs. ;)

    -

    Ja, die 411'er sind bzgl. Maintenance nicht der Hit bzgl. Plastikhalterung. Bei den 611'ern auch nicht wirklich besser.

    Einmal editiert, zuletzt von escimo ()

  • Das 411er geht an escimo. Die kann man auch mit einem duennen Spachtel aufmachen, aehnlich wie bei den alten MacMinis.

    Das Multipack waere noch zu haben, das stelle ich dann mal bei Suche/Biete rein wenn der Sokoban-Stapel darueber abgebaut ist und man es einzeln zum Funktionstest herausnehmen kann :fp:

  • NFS-Boot geht glücklicherweise immer bei den Systemen. (...)

    "NFS-Boot" kann ich so nicht stehenlassen, da ungenau. Der IEEE Standard 1275 definiert die Notwendigkeiten für die OpenBoot Firmware. Die OB FW bei SPARC-Systemen enthält u.a. neben Angaben zu Gerätepfaden (/sbus@x,y/...) , dazugehörige Aliase (net) ein Programm (FORTH Wort) boot, welches Parameter-gesteuert (i.d.R. Alias "net") über eine allgemeine RARP-Anfrage (Boadcast) seine MAC-Adresse (Ethernetadresse) im Netzwerk verschickt. Sollte ein entfernter Bootserver antworten, dem die Client MAC bekannt ist, schickt dieser mit dem HG-Prozess rarpd die zugehörige Internetadresse an den Client. Nach einer weiteren allgemeinen Anfrage (bootparam) mit der nun bekannten Internetadresse vom Client aus sollte ein entfernter Bootserver, i.d.R. derselbe im selben Netzsegment befindlich, vom im HG laufendem Prozess rpc.bootparamd u.a. den Client-Hostname sowie die zugehörige Domain erhalten. Diese Daten/Infos werden verwendet, um nun das Bootprogramm inetboot (Plattform-abhängiges) vom Bootserver über TFTP in den Client-Arbeitsspeicher zu laden. Mit Hilfe dieses Binärprogramms inetboot, den Client- und Server-Infos wird eine getfile-Anfrage zum Einhängen des Root (/) - und Swap-Dateisystems geschickt, welche von dem zuständigen Server mittels NFS für Clients bereitgestellt werden. Der Kernel (Binary) ist i.d.R. unterhalb des Wurzel-/Rootverzeichnis (/ bzw /boot), in der Datei unix, abgelegt. Nach dem NFS-Mount von Root und Swap wird die Kontrolle von inetboot an den Kernel übergeben (unix), der die weitere Systeminitialisierung, u.a. das Laden des Programmes init, übernimmt. Bei x86 würde das Laden aus HW-technischen Gründen über RPL (Remote Procedure Load) erfolgen, welches die bei SPARC zum Einsatz kommenden arpd- und tftpd-Hintergrundprozesse ersetzt. Der RPL-Daemon ist für SPARC und x86 Plattform verfügbar, was bedeuted, dass man einen x86-Client auch von einem SPARC-Server über Netzwerk booten kann, und umgekehrt. Die Netzwerkanfragen (Broadcasts) werden i.d.R. von auf einer Bootdiskette oder im EPROM gespeicherten Programmen realisiert.


    Wenn ich mal Zeit habe möchte ich mir für den x86 PC mal ein passendes EPROM basteln und mit meinem Batronix programmieren. Auch das Booten des OS komplett über Netzwerk möchte ich mal in meiner, häuslichen Versichsanordnung nachstellen. Dann könnte man sich das Scheffeln von alternativen Speichern (CF, SD, Bridges, Festplatten, Installationsmedien usw) verkneifen.