6x500GB RAID5 nach defekter HDD bei Rebuild eine weitere Platte defekt gegangen

Danke für den Tipp, laut Seagate sind meine 3 nicht betroffen.

SNo Serial number Result Action
1 9VS10N3V Drive is not affected. No action required.
2 9VS02V73 Drive is not affected. No action required.
3 9VS1J499 Drive is not affected. No action required.


Ich habe die Seatool für Windows runtergeladen und installiert, den Raid im Bios auf IDE umgestellt und neu gebootet. Kannst Du mir sagen wie man das anstellt mit dem HPA?

In den Tools kann ich nur Test's machen und Info's anzeigen lassen.
Selbst wenn ich die erweiterten Test's angezeigt bekomme, dann gibt es da Firmwareupdate und Format Basic.

Hast Du vielleicht einen direkten Link zu so einer Aktion?
Ergänzung ()

Ich hab grad mal mit dem HD Tune mir den Health status anzeigen lassen, wie kann es angehen, das die ersten beiden Platten schon 13h auf dem Buckel haben und die Platte von heute nur 1h. Das ist ja schon fast eine Frechheit.:)
 
Sorry, ich hab den Seitenwechsel verschlafen, weil ich gerade in der Formel zur Berechnung des Paritystripe-Volumes vertieft war

Die dürfte einer schon retourniert haben, wenn 13h (nachdem sie ihm runtergefallen sind)
Ein ordentlicher Shop macht da ein factory reset, damit keiner was merkt:D

Muss mal bei den Seatools nachsehen, wie das geht. irgendwas mit max native size - Augenblick noch
Ergänzung ()

Das geht nur mit den Seatools for DOS
Um die DOS-CD zu booten, ist IDE mode erforderlich für den Controller, an dem die HDD hängt
unter "Advanced features"/"set capacity manually" muss dort (angezeigter Wert der max native size - 2) eingegeben werden.
 
Habe bei allen 3 Platten die Maxsize um 2 gekürzt.

Dann kann ich jetzt das Raid 5 konfigurieren?
Ergänzung ()

Sicher das das Richtig war? Im Matrix Rom Manager werden die Platten nun nur noch als 1024.0 GB angezeigt nicht mehr 13.... Es scheint als hätte ich jetzt nur noch 1TB Platten.

Ich habe ganz bestimmt von der letzten Zahl 2 abgezogen. Max Size ......67 und ich habe .....65 eingegeben.

Was habe ich falsch gemacht?
 
eigentlich nichts. Die Kerle sind zu dumm zum Programmieren.


was wird unter Windows im HxD als MaxLBA angezeigt? wahrscheinlich 2147483648
welcher Wert wird denn in den Seatools
als current size angezeigt? 2930277166?
als max native size angezeigt? 2930277168?

versuch mal "set capacity to max" - damit sollte das hoffentlich wieder aufgehoben werden
 
Zuletzt bearbeitet:
ich habe es auf max zurück gesetzt.

angezeigt wird Max Native Adress 2930277167

wenn ich 2 abziehe und den Wert Eingebe zeigt er mir an unter
Device is 48Bit Adressed - Number of LBAs 2147483647 (1099,512 GB)

auch wenn ich dann die falsch eingestellte Platte von Hand auf den Max Native Adress 2930277167 stelle kommt auch wieder 1099,512 GB raus, das muß echt ein Softwarefehler sein.:D
Ergänzung ()

Windows boote ich noch schnell, kommt sofort. :-)
Ergänzung ()

also HxD zeigt den Wert 2930277168 an, die Seatools -1 (2930277167)
Ergänzung ()

bei der geänderten Platte zeigt HxD 2147483648 an (1099.512 GB)

so ich hoffe dich mit den Zahlen jetzt nicht verwirrt zu haben.
 
Zuletzt bearbeitet:
Die haben nicht gelernt, wie man mit mehr als 31 Bit arithmetische Operationen durchführt.
Müssen wohl denselben Assembler-Instruktor wie die BIOS-Coder von Gigabyte gehabt haben.

Man könnte es stattdessen mit MHDD durchführen. Die Russen haben das sicher schon vor Jahrzehnten bei den Amis ausspioniert, und wissen daher, wie man das richtig codiert.

Willst Du es damit probieren oder vergessen wir das?
 
ich denke wir vergessen das. Udo macht jetzt immer brav eine Datensicherung. :D
Und das Bios werde ich bei dem alten Board eh nicht mehr updaten.
Ergänzung ()

Aber beruhigend ist das die wenigstens das set capacity to max native hin bekommen haben.

Das mit den Russen ist gut:D
Ergänzung ()

Windows XP pro SP3 kann ja gar nicht mit solch großen Datenträgern um.
Wird in der Datenträgerverwaltung noch nicht einmal angezeigt. Im Gerätemanager schon.
Ist ja witzig. Man gut ich hab noch W7-RC 7100 zum spielen installiert.
 
Zuletzt bearbeitet:
Mir liegt noch immer die letzte Fehlermeldung an Seagate im Magen,
deshalb werd ich es wohl lassen, diesen Fehler zu melden.

Manchmal haben fabrikneue Platten, die noch nie zuvor in anderen Kundenhänden waren, nicht auf allen Sektoren lauter Nullen. Weil sie zu Kontrollzwecken z.B. jede tausendste HDD mit einem Testpattern beschreiben und wenn fehlerfrei, daraus ableiten, dass diese Charge in Ordnung ist. So eine hab ich ausgefasst und nicht schlecht gestaunt, als trotz geringem Füllungsgrad ein komprimiertes Image fast so groß wie die Plattenkapazität war.

Daraufhin hab ich mit dem Seatools for DOS ein "write all zeroes" gemacht und anschließend mit HxD geguckt, ob jetzt alles sauber ist. Mitnichten. Jeder 256te Sektor war mit irgendeinem Inhalt aus dem Speicher verseucht, weil sie die I/O Area um einen Sektor zu kurz gelöscht haben und mit einem I/O immer 256 Sektoren geschrieben.

Nach 5 Mails hin und her hab ich aufgegeben, weil die Kerle im Support dumm wie Stroh waren und das Problem nicht begriffen haben.

Aber vielleicht willst Du dich ja mit denen amüsieren?

Ich muss noch über der Berechnungsformel, wo das Paritystripe liegt, grübeln - die ist bei 6 Memberplatten fehlerhaft, bei 3 und 4 funktioniert sie.
Ich würde vorschlagen, wir machen morgen Vormttag weiter...

Ja, GPT Datenträger, zur Initialisierung von mehr als 2,099TB großen Volumes kann nur Vista und Win7 und die WinServer. Da haben sie wohl im XP ein Update vergessen - oder Absicht?
 
Zuletzt bearbeitet:
Das mit Seagate ist je der Hammer. Alle zu hochnäsig was?

Mach das in Ruhe, ich hab Zeit meine 6 Platten laufen nicht weg, ich habe vollstes Vertrauen das Du das hin bekommst.

Ich denke das ist Absicht, damit das zuverlässige XP endlich abgelöst werden muß.
Denn für den W2K3 SRV hieß es auch erst das es nur mit der 64Bit Version gehen soll. Aber mein 32Bit R2 kann damit um. Ganz klare Absicht.

Ernst, dann machen wir Morgen Vormittag weiter. Ich wünsche eine Gute Nacht.
Ach ja schläfst Du überhaupt irgendwann mal?:D
 
Weiter in aller Frische...
Am Sonntag sieht die Welt ganz anders aus - Problem gelöst!

Wie sieht der neue RAID5 aus? Alles gecheckt? keine fehlerhaften Sektoren?
Ach ja: Wie hast Du vor, die Datenmenge vom Server zum Client transferieren? per FTP?

Im Anhang nochmals die analysierten GPT-Einträge, diesmal um die nun hoffentlich richtigen physischen Positionen ergänzt. Nach ein wenig Gefummel mit HxD an den Memberplatten des Servers werden wir versuchen, diesen RAID5 wieder zum Leben zu erwecken.

Die Anordnung der Platten sollte wie folgt aussehen:

A: HDD[0] <Serial=S0MUJ1FPA91881>
B: HDD[1] <Serial=S0MUJ1DP930072> (die auch als fehlerhaft verstoßene)
C: HDD[2] <Serial=S0MUJ1KPA77223>
D: HDD[3] <Serial=S0MUJ2FPA21167>
E: HDD[4] <Serial=S0MUJ1MP505599> (die als fehlerhaft verstoßene ursprüngliche)
F: HDD[5] <Serial=S0MUJ1DP930069>

Ich habe jetzt eine Stunde verzweifelt in meinen tausenden Tools gestöbert, ob es eines gibt, womit man von einer USB HDD die physische Seriennummer auslesen kann (zur Kontrolle) und keines gefunden. Seatools for Windows kann es natürlich auch nicht.
Eine Version verendet mit einem "Fatal Error", eine andere zeigt die Seriennummer einer USB-HDD natürlich auch nicht an.:kotz:

Somit kann ich nur darauf hoffen, dass Du sorgfältigst darauf achtest, die richtige HDD über USB an den Client zu verbinden, und danach wieder an den richtigen Port des ICH9R am Server steckst. (oder in den richtigen Slot) :D

Was nun zu machen ist:
Sicherung der Sektoren 0 aller Member-Platten
Sicherung MBR+GPT info
Sicherung GPT Mirror
Sicherung NTFS Header
Sicherung NTFS Header Mirror
Sicherung RAID-Info aller Member-Platten

Zerstörung RAID-Info aller Memberplatten
danach Neudefinition RAID5
danach Wiederherstellen MBR
danach Freude oder Verzweiflung

Bereit? Noch Fragen? dann erstell ich die mal die Anweisungen, die Du hoffentlich peinlich genau einhältst:D
 

Anhänge

Zuletzt bearbeitet:
Bereit ;)

Kopieren wollte ich per 1Gbit Netzwerk per Total Commander. Das sollte dann recht zügig von statten gehen. Oder siehst Du da irgendwelche Probleme?

Dein Katalog sieht erstmal heftig aus. puh.

Ich kann die Memeber Platten immer noch an einen SATA Port vom Marvel am Client hängen. Also brauchen wir kein USB.
 
Kopieren wollte ich per 1Gbit Netzwerk per Total Commander. Das sollte dann recht zügig von statten gehen. Oder siehst Du da irgendwelche Probleme?
Nein. Falls Du den nicht hättest und dafür nicht zahlen wolltest, hätte ich gleichwertiges auf Lager gehabt.
Irgendwann mal hab ich gelernt, dass die schnellste Methode, etwas über das Netzwerk zu transferieren, über compressed FTP Server-Client Protokoll, sein soll. Wir müssen aber nicht hetzen.:)
Dein Katalog sieht erstmal heftig aus. puh.
Ist ganz einfach, wenn ich und Du keine Fehler machen:evillol:
Ich kann die Memeber Platten immer noch an einen SATA Port vom Marvel am Client hängen. Also brauchen wir kein USB.
Wenn Du sie nicht aus dem Carrier zu schrauben brauchst oder das SATA-Kabel vom Client zum Server lang genug ist - soll es mir recht sein. Dann kannst Du mit HDTune oder so die Seriennummer verifizieren, die gerade bearbeitet wird, oder am Aufkleber ablesen.

Ich muss mir nur aus irgendeinem meiner alten Threads die Gebrauchsanleitung kopieren, die Andere schon fehlerfrei verstanden haben... um Geduld wird gebeten...
 
aus den Carriern brauch ich nicht raus, Cleint habe ich mit offener Seite und ausreichend langen Strom und SATA Kabeln neben dem Server stehen.
Also kein Problem das Ganze im Server anzuschließen.

Das mit dem compressed FTP werde ich mir mal antun, aber ganz normales Filecopy geht eigentlich auch ganz zügig. OK 2Terra sind nicht in ner Stunde durch, muß auch nicht.
Hauptsache es geht überhaupt. :)

Ich habe Zeit (muß Zeit haben):D
 
Bei Musik- oder Videodaten ist es ohnehin sinnlos, aber man sollte nicht glauben, wieviele Leerstellen 0x20, 0x00 oder Zeichenwiederholungen in Programmen oder Datenbanken drinstecken, die dann mit dieser Methode die Übertragungsgeschwindigkeit der Rohdatenmenge mehr als verzehnfachen...
Ergänzung ()

Um mit deinen früheren Ordnerstrukturen zum zippen und posten nicht durcheinanderzukommen,
würde ich vorschlagen, ein komplett neues Set anzulegen.
Nenn die Ordner HDD0 bis HDD6.
Bereiche sind teilweise wie bisher im HxD format in .txt Files abzuspeichern.
Kommentarzeilen dazwischen brauchst Du nicht einzufügen, das das Programm, mit dem ich das verarbeite, damit ohnehin nichts anfangen kann, sondern sich nach den hex-Offsetwerten am Beginn der einzelnen Zeilen orientiert. Daher sollte die Offsetdarstellung in der Überschrift immer „Offset(h)“ aufweisen.
Alle derart übermittelten einzelnen Bereiche einem Memberplatte einfach in dem File, z.B. HDD0.txt, hinten anfügen

Für eventuell spätere Recovery wollen wir diesmal Auszüge der einzelnen Platten auch in einem .bin Format abspeichern. Da muss aus praktischen Gründen für jeden File ein anderer Name gewählt werden, am besten in der Form HDD0.startsector.numbersectors.bin
Also für die ersten drei Sektoren der Platte 0 z.B. HDD0.0.3.bin

Diese Files erzeugst Du folgendermaßen:
- Anschließen der entsprechenden Platte. Kontrolle der Seriennummer z.B. mit HDTune
- Aufruf HxD, die richtige physical disk öffnen. Kontrolle: Als MaxLBA muss rechts oben für die einzige 500GB HDD am Client immer „of 976773168“ stehen.
- Markieren eines Bereiches im Menü Edit/Select Block; den von mir vorgegebenen Start- und End-offset per Copy&Paste in die Felder übertragen, RadioButton auf hex, OK drücken
- mit Strg+C den Inhalt in die Zwischenablage
- im Menü File/New
- mit Strg+V in den neuen File übertragen. Warnungspopup der Längenänderung: OK
- im Menü File/Save as: den von mir vorgegeben Filenamen mit copy&paste übertragen, Save
- im Menü File/Close
- für weitere Bereiche auf dieser HDD genauso verfahren, danach HxD beenden und Platte abklemmen.

Zur Übung mal die HDD0 auf den OP-Tisch:

A: HDD[0] <Serial=S0MUJ1FPA91881> MaxLBA=976773168

Start: 0 End: 5FF in Ordner HDD0 als File HDD0.0.3.bin
Start: 74709A1000 End: 7470C05FFF in Ordner HDD0 als File HDD0.976768264.4904.bin

Den Ordner mal Zippen und in den Anhang stellen.
Ich setz dann später hier fort
Ergänzung ()

Damit ich's nicht vergess: Power-Off des jeweiligen Einschubes, bevor du das SATA-Kabel des Servers wieder dranhängst (damit die nicht durcheinanderkommen)

NACHTRAG 15:15
Das klappt ja SUPER macht ja richtig Spass...

Flugs weiter, bevor Du vergisst, wie das geht, stell es in Dein folgendes Post gleich dazu:D

B: HDD[1] <Serial=S0MUJ1DP930072> MaxLBA=976773168

Start: 0 End: 1FF in Ordner HDD1 als File HDD1.0.1.bin
Start: 74709A1000 End: 7470C05FFF in Ordner HDD1 als File HDD1.976768264.4904.bin

NACHTRAG 15:42

C: HDD[2] <Serial=S0MUJ1KPA77223> MaxLBA=976773168

Start: 0 End: 1FF in Ordner HDD2 als File HDD2.0.1.bin
Start: 74709A1000 End: 7470C05FFF in Ordner HDD2 als File HDD2.976768264.4904.bin

Danach überträgst du folgenden Wert rechts oben im HxD ins Sektorfenster
976767777
und drückst Enter. Wenn der angezeigte Sektor mit
EB 52 90 4E 54 46 53 20 (rechte Spalte: ...NTFS ) beginnt, dann scheint meine Sektorlokalisation auf RAID5 zu funktioniiiieren und hat die Feuertaufe bestanden.
Markiere den ganzen Sektor 976767777 und speichere ihn wie gestern mit Copy as/Editor View
in einen Textfile im Ordner HDD2 als HDD2.txt ab

Falls da was anderes drinennstehen sollte, sieh noch in den unmittelbar davorliegenden Sektoren nach.

alles wieder schön zippen - lass die Platte einstweilen noch dran
den .txt file muss ich erst durch die Analyse jagen
 
Zuletzt bearbeitet:
im Anhang die Analyse des NTFS Mirrors.

Die NTFS-Clustersize ist mickrige 4K.

wenn Du hier nicht viele keine Dateien, sondern größtenteils Audio/Videodateien draufhast, könnte eine Clustersize von 128K performanter sein.

von diesem Membervolume sichern wir noch
C: HDD[2] <Serial=S0MUJ1KPA77223> MaxLBA=976773168

Start: 7470964200 End: 74709643FF in Ordner HDD2 als File HDD2.976767777.1.bin

Dann weiter mit der nächsten HDD

D: HDD[3] <Serial=S0MUJ2FPA21167> MaxLBA=976773168

Start: 0 End: 1FF in Ordner HDD3 als File HDD3.0.1.bin
Start: 1994400 End: 19945FF in Ordner HDD3 als File HDD3.52386.1.bin
Start: 74709A1000 End: 7470C05FFF in Ordner HDD3 als File HDD3.976768264.4904.bin


E: HDD[4] <Serial=S0MUJ1MP505599> MaxLBA=976773168

Start: 0 End: 1FF in Ordner HDD4 als File HDD4.0.1.bin
Start: 74709A1000 End: 7470C05FFF in Ordner HDD4 als File HDD4.976768264.4904.bin


F: HDD[5] <Serial=S0MUJ1DP930069> MaxLBA=976773168

Start: 0 End: 1FF in Ordner HDD5 als File HDD5.0.1.bin
Start: 747097BE00 End: 747097FFFF in Ordner HDD5 als File HDD5.976767967.33.bin
Start: 74709A1000 End: 7470C05FFF in Ordner HDD5 als File HDD5.976768264.4904.bin
 

Anhänge

Was wir nun gesichert haben:

HDD0.0.3.bin enthält MBR/GPT des logischen Volumes
HDD5.976767967.33.bin enthält den GPT Mirror
HDD3.52386.1.bin enthält den NTFS Bootrec
HDD2.976767777.1.bin enthält den NTFS Bootrec Mirror
HDD[1-5].0.1 physischen Sektoren 0 der restlichen Memberplatten
HDD[0-5].976768264.4904.bin die RAID-Controllerinfos des kaputten Arrays

Damit ist der erste Step beendet.
Nach Überprüfung der Inhalte der Sicherungsfiles geht's um 20:00 weiter...
 
Ernst@at schrieb:
im Anhang die Analyse des NTFS Mirrors.

Die NTFS-Clustersize ist mickrige 4K.

wenn Du hier nicht viele keine Dateien, sondern größtenteils Audio/Videodateien draufhast, könnte eine Clustersize von 128K performanter sein.

Das ist dann der Windows Standard. Beim neuen Raid wollte ich Deinen Vorschlag beherzigen und nochmal neu formatieren mit 128K doch Windows läßt nur bis max.
64K Größe der Zuordnungseinheit zu.

Siehe Screenshot



und nun?
 

Anhänge

  • format.jpg
    format.jpg
    42,6 KB · Aufrufe: 470
So gehts weiter:

Nachtrag 03.06.2009
Am Lösungsweg Interressierte können die weiteren Seiten überspringen, da diese nicht zielführend waren. Der richtige Lösungsweg geht auf Seite 7, ab Post# 121 weiter:D




Nun machen wir mit einem kleinen Eingriff noch auf HDD[0] den MBR kaputt.
Manche RAID-Controller löschen den physischen Record 0, andere nicht.
Wir wollen sichergehen, dass nach Neudefinition des RAID5 nicht gleich das Filesystem von Windows da drauf herumfuhrwerkt, und löschen die Partitioninformation selbst.

Dazu hängst Du jetzt nochmals die HDD0 an den Client

A: HDD[0] <Serial=S0MUJ1FPA91881> MaxLBA=976773168

Öffnest mit HxD die richtige physical disk, diesmal das Häkchen „Open as Readonly“ wegmachen.

Im Sektor 0 dieser Platte steht am
Offset(h)
00000001B0 00 00 00 00 00 00 00 00 47 35 43 EE 00 00 00 00 ........G5Cî....
00000001C0 02 00 EE FF FF FF 01 00 00 00 FF FF FF FF 00 00 ..îÿÿÿ....ÿÿÿÿ..

Da schreibst du einfach Nullen drüber in beiden Zeilen

Wenn ein Popup-Fenster mit Warnung Längenänderung erscheint, nicht weitermachen, das wäre fatal.

Ansonsten im HxD-Menü mit File/Save die Änderung auf die Platte schreiben und HxD beenden.
HDD0 zurückhängen

Anschließend kannst Du alle 6 Platten am Server wieder unter Strom setzen .
Im Matrix-Manager dann, wenn alle Platten sichtbar sind (auch wenn er bei zweien motzt) den RAID5-Array auflösen. Sollte der in seiner Verwirrung von selbst mit einem Rebuild beginnen (glaub ich zwar nicht, aber Überraschungen sind immer gut) dann würge ihn sofort ab (notfalls mit Netz-Aus der Platten oder des Servers), dann müssen wir anders vorgehen

Danach den RAID5-Array wieder mit Stripesize 64K und der gleichen Plattenreihenfolge definieren.

In der Datenträgerverwaltung sollte dann wieder ein 2,5TB Volume auftauchen – komplett unallocated

Nun mit HxD diesen Datenträger als physical disk öffnen.
Kleiner Rundgang am logischen Volume zur Überprüfung (Du musst nicht byteweise den ganzen Sektor vergleichen, wenn es oberflächlich betrachtet das gleiche ist, reicht’s schon)

Sektor 0 : physischer Sektor 0 auf HDD[0]
Da kommt später der MBR wieder drauf

Beginn Sektor 1 :
0000000200 45 46 49 20 50 41 52 54 00 00 01 00 5C 00 00 00 EFI PART....\...

Beginn Sektor 2 :
0000000400 16 E3 C9 E3 5C 0B B8 4D 81 7D F9 2D F0 02 15 AE .ãÉã\.¸M.}ù-ð..®
0000000410 9C FC 9B 5F 5E 1D 35 4C 96 E3 F9 BB 0C 88 24 79 œü›_^.5L–ãù».ˆ$y
0000000420 22 00 00 00 00 00 00 00 21 00 04 00 00 00 00 00 ".......!.......
0000000430 00 00 00 00 00 00 00 00 4D 00 69 00 63 00 72 00 ........M.i.c.r.
0000000440 6F 00 73 00 6F 00 66 00 74 00 20 00 72 00 65 00 o.s.o.f.t. .r.e.
0000000450 73 00 65 00 72 00 76 00 65 00 64 00 20 00 70 00 s.e.r.v.e.d. .p.
0000000460 61 00 72 00 74 00 69 00 74 00 69 00 6F 00 6E 00 a.r.t.i.t.i.o.n.

Sektor 128 : (physischer Sektor 0 auf HDD[1] )
Noch gleicher Inhalt wie im File HDD1.0.1.bin ?
(kannst Du vom Explorer ins HxD-Fenster ziehen, nach Vergleich wieder schließen)

Sektor 256 : ( physischer Sektor 0 auf HDD[2] )
Noch gleicher Inhalt wie im File HDD2.0.1.bin ?

Sektor 384 : ( physischer Sektor 0 auf HDD[3] )
Noch gleicher Inhalt wie im File HDD3.0.1.bin ?

Sektor 512 : ( physischer Sektor 0 auf HDD[4] )
Noch gleicher Inhalt wie im File HDD4.0.1.bin ?

Sektor 262178 : ( physisch irgendwo auf HDD[3] )
Noch gleicher Inhalt wie im File HDD3.52386.1.bin ?

Sektor 4883839009 : ( physisch irgendwo auf HDD[2] )
Noch gleicher Inhalt wie im File HDD2.976767777.1.bin ?

Sektor 4883839967 : ( physisch irgendwo auf HDD[5] )
Steht da sowas wie in Sektor 2 (siehe oben)?

Sektor 4883839999 : ( physisch irgendwo auf HDD[5] )
Steht da sowas wie in Sektor 1 (siehe oben)?

Kopier Dir als Checkliste für Deine Antwort Ja/Nein

Sektor 1 OK?
Sektor 2 OK?
Sektor 128 OK?
Sektor 256 OK?
Sektor 384 OK?
Sektor 512 OK?
Sektor 262178 OK?
Sektor 4883839009 OK?
Sektor 4883839967 OK?
Sektor 4883839999 OK?
Ergänzung ()

doch Windows läßt nur bis max.
64K Größe der Zuordnungseinheit zu.
Pardon, ich war verwirrt. Hatte dabei die Stripesize im Kopf, die bis 128K geht...
64K reicht auch...
 
Zuletzt bearbeitet:
Zurück
Oben