[Linux] mdadm Raid-Array verloren

mixn_mojo · 4. Mai 2012

Tja, ganz großes Kino.

Ich hab (oder hatte) ein Raid6 bestehend aus 9 x 1,5 TB Platten mittels mdadm erstellt, lief auch immer bestens.

Eine der Platten wurde zuletzt durch eine massive Anzahl an defekten Sektoren auffällig. Habe sie dementsprechend aus dem Raid entfernt, lief alles problemlos und wollte die defekte Platte gleich ausbauen. Beim Ausbau ist mir dann der große Fehler passiert. Von einer weiteren Platte hatte ich vergessen den Stromanschluss wieder einzustecken, von einer anderen hatte sich wohl das Sata-Kabel etwas gelockert. Soll heißen, von original 9 Platten waren nach dem Neustart nur noch 6 verfügbar.

Das Ende vom Lied ist, auch mit beiden Platten wieder angeschlossen, ist das Raid anscheinend verloren.

Kennt hier vielleicht jemand Kniffe oder Möglichkeiten, es doch noch einmal an den Tag zubefördern?

Addendum: Augenscheinlich gibt es auf den Platten keinen "RAID superblock" mehr. Gibt es eine Möglichkeit, den wiederherzustellen?

Ein

Code:

sudo mdadm --examine /dev/sdk1

fördert folgendes zu Tage:

Code:

/dev/sdk1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 00000000:00000000:00000000:00000000
  Creation Time : Fri May  4 20:01:12 2012
     Raid Level : -unknown-
   Raid Devices : 0
  Total Devices : 7
Preferred Minor : 0

    Update Time : Fri May  4 20:02:14 2012
          State : active
 Active Devices : 0
Working Devices : 7
 Failed Devices : 0
  Spare Devices : 7
       Checksum : 9fb87681 - correct
         Events : 1


      Number   Major   Minor   RaidDevice State
this     1       8      129        1      spare   /dev/sdi1

   0     0       8      145        0      spare   /dev/sdj1
   1     1       8      129        1      spare   /dev/sdi1
   2     2       8      113        2      spare   /dev/sdh1
   3     3       8       81        3      spare   /dev/sdf1
   4     4       8       17        4      spare   /dev/sdb1
   5     5       8        1        5      spare   /dev/sda1
   6     6       8       49        6      spare   /dev/sdd1

VPN-User · 4. Mai 2012

Nee. Solange keine Daten wg. defekter Platten verloren gegangen sind, lässt sich das sicher wieder hinkriegen. Wenn für ein RAID zu wenig benötigte Platten verfügbar sind, lässt es sich garnicht erst starten und daher geht auch nicht mehr kaputt. Alle Platten werden dann aus dem RAID herausgenommen und müssen erneut zugeordnet werden.

Gibt mdadm --examine ähnliches für alle Platten aus?

Ergänzung (5. Mai 2012)

Ruf mal 'mdadm -E /dev/sdX | grep Event' für alle RAID-Partitionen auf. Interessant ist dann, welche Platten den selben Wert ausspucken. Diese sind dann 'in sync' und in Ordnung. Wenn Du damit auf 7 kommst, kannst Du Dein RAID vollständig wiederherstellen.

Ich kann Dir auch anbieten, mir das per SSH screen session mal anzusehen

Link-Tip: https://raid.wiki.kernel.org/index....ecreating_.28after_multiple_device_failure.29

mixn_mojo · 4. Mai 2012

Besten Dank schonmal, dass sich jemand an dieses heikle Thema rantraut.

Also, folgende Platten gehören zu dem Raid6, welches momentan verloren ist.

Code:

/dev/sda1 /dev/sdb1 /dev/sdd1 /dev/sde1 /dev/sdg1 /dev/sdi1 /dev/sdj1 /dev/sdk1

Zu einem anderen Raid5, welches tadellos läuft, gehören

Code:

/dev/sdc1 /dev/sdh1 /dev/sdl1 /dev/sdm1 /dev/sdn1

Und die Systemplatte ist /dev/sdf.

Im Folgenden die Ausgaben von 'mdadm -E /dev/sdx'

Code:

/dev/sda1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 00000000:00000000:00000000:00000000
  Creation Time : Fri May  4 20:01:12 2012
     Raid Level : -unknown-
   Raid Devices : 0
  Total Devices : 7
Preferred Minor : 0

    Update Time : Fri May  4 20:02:14 2012
          State : active
 Active Devices : 0
Working Devices : 7
 Failed Devices : 0
  Spare Devices : 7
       Checksum : 9fb87609 - correct
         Events : 1


      Number   Major   Minor   RaidDevice State
this     5       8        1        5      spare   /dev/sda1

   0     0       8      145        0      spare   /dev/sdj1
   1     1       8      129        1      spare   /dev/sdi1
   2     2       8      113        2      spare   /dev/sdh1
   3     3       8       81        3      spare   /dev/sdf1
   4     4       8       17        4      spare   /dev/sdb1
   5     5       8        1        5      spare   /dev/sda1
   6     6       8       49        6      spare   /dev/sdd1

Code:

/dev/sdb1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 00000000:00000000:00000000:00000000
  Creation Time : Fri May  4 20:01:12 2012
     Raid Level : -unknown-
   Raid Devices : 0
  Total Devices : 7
Preferred Minor : 0

    Update Time : Fri May  4 20:02:14 2012
          State : active
 Active Devices : 0
Working Devices : 7
 Failed Devices : 0
  Spare Devices : 7
       Checksum : 9fb87617 - correct
         Events : 1


      Number   Major   Minor   RaidDevice State
this     4       8       17        4      spare   /dev/sdb1

   0     0       8      145        0      spare   /dev/sdj1
   1     1       8      129        1      spare   /dev/sdi1
   2     2       8      113        2      spare   /dev/sdh1
   3     3       8       81        3      spare   /dev/sdf1
   4     4       8       17        4      spare   /dev/sdb1
   5     5       8        1        5      spare   /dev/sda1
   6     6       8       49        6      spare   /dev/sdd1

Code:

/dev/sdd1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 00000000:00000000:00000000:00000000
  Creation Time : Fri May  4 20:01:12 2012
     Raid Level : -unknown-
   Raid Devices : 0
  Total Devices : 7
Preferred Minor : 0

    Update Time : Fri May  4 20:02:14 2012
          State : active
 Active Devices : 0
Working Devices : 7
 Failed Devices : 0
  Spare Devices : 7
       Checksum : 9fb8763b - correct
         Events : 1


      Number   Major   Minor   RaidDevice State
this     6       8       49        6      spare   /dev/sdd1

   0     0       8      145        0      spare   /dev/sdj1
   1     1       8      129        1      spare   /dev/sdi1
   2     2       8      113        2      spare   /dev/sdh1
   3     3       8       81        3      spare   /dev/sdf1
   4     4       8       17        4      spare   /dev/sdb1
   5     5       8        1        5      spare   /dev/sda1
   6     6       8       49        6      spare   /dev/sdd1

Code:

/dev/sde1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 00000000:00000000:00000000:00000000
  Creation Time : Fri May  4 20:22:37 2012
     Raid Level : -unknown-
   Raid Devices : 0
  Total Devices : 1
Preferred Minor : 0

    Update Time : Fri May  4 20:23:58 2012
          State : active
 Active Devices : 0
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 1
       Checksum : 9fb87dfa - correct
         Events : 1


      Number   Major   Minor   RaidDevice State
this     0       8       49        0      spare   /dev/sdd1

   0     0       8       49        0      spare   /dev/sdd1

Code:

/dev/sdg1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 00000000:00000000:00000000:00000000
  Creation Time : Fri May  4 20:01:12 2012
     Raid Level : -unknown-
   Raid Devices : 0
  Total Devices : 7
Preferred Minor : 0

    Update Time : Fri May  4 20:02:14 2012
          State : active
 Active Devices : 0
Working Devices : 7
 Failed Devices : 0
  Spare Devices : 7
       Checksum : 9fb87655 - correct
         Events : 1


      Number   Major   Minor   RaidDevice State
this     3       8       81        3      spare   /dev/sdf1

   0     0       8      145        0      spare   /dev/sdj1
   1     1       8      129        1      spare   /dev/sdi1
   2     2       8      113        2      spare   /dev/sdh1
   3     3       8       81        3      spare   /dev/sdf1
   4     4       8       17        4      spare   /dev/sdb1
   5     5       8        1        5      spare   /dev/sda1
   6     6       8       49        6      spare   /dev/sdd1

Code:

/dev/sdi1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 00000000:00000000:00000000:00000000
  Creation Time : Fri May  4 20:01:12 2012
     Raid Level : -unknown-
   Raid Devices : 0
  Total Devices : 7
Preferred Minor : 0

    Update Time : Fri May  4 20:02:14 2012
          State : active
 Active Devices : 0
Working Devices : 7
 Failed Devices : 0
  Spare Devices : 7
       Checksum : 9fb87673 - correct
         Events : 1


      Number   Major   Minor   RaidDevice State
this     2       8      113        2      spare   /dev/sdh1

   0     0       8      145        0      spare   /dev/sdj1
   1     1       8      129        1      spare   /dev/sdi1
   2     2       8      113        2      spare   /dev/sdh1
   3     3       8       81        3      spare   /dev/sdf1
   4     4       8       17        4      spare   /dev/sdb1
   5     5       8        1        5      spare   /dev/sda1
   6     6       8       49        6      spare   /dev/sdd1

Code:

/dev/sdj1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 00000000:00000000:00000000:00000000
  Creation Time : Fri May  4 20:01:12 2012
     Raid Level : -unknown-
   Raid Devices : 0
  Total Devices : 7
Preferred Minor : 0

    Update Time : Fri May  4 20:02:14 2012
          State : active
 Active Devices : 0
Working Devices : 7
 Failed Devices : 0
  Spare Devices : 7
       Checksum : 9fb87681 - correct
         Events : 1


      Number   Major   Minor   RaidDevice State
this     1       8      129        1      spare   /dev/sdi1

   0     0       8      145        0      spare   /dev/sdj1
   1     1       8      129        1      spare   /dev/sdi1
   2     2       8      113        2      spare   /dev/sdh1
   3     3       8       81        3      spare   /dev/sdf1
   4     4       8       17        4      spare   /dev/sdb1
   5     5       8        1        5      spare   /dev/sda1
   6     6       8       49        6      spare   /dev/sdd1

Code:

/dev/sdk1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 00000000:00000000:00000000:00000000
  Creation Time : Fri May  4 20:01:12 2012
     Raid Level : -unknown-
   Raid Devices : 0
  Total Devices : 7
Preferred Minor : 0

    Update Time : Fri May  4 20:02:14 2012
          State : active
 Active Devices : 0
Working Devices : 7
 Failed Devices : 0
  Spare Devices : 7
       Checksum : 9fb8768f - correct
         Events : 1


      Number   Major   Minor   RaidDevice State
this     0       8      145        0      spare   /dev/sdj1

   0     0       8      145        0      spare   /dev/sdj1
   1     1       8      129        1      spare   /dev/sdi1
   2     2       8      113        2      spare   /dev/sdh1
   3     3       8       81        3      spare   /dev/sdf1
   4     4       8       17        4      spare   /dev/sdb1
   5     5       8        1        5      spare   /dev/sda1
   6     6       8       49        6      spare   /dev/sdd1

VPN-User · 6. Mai 2012

Hmm ok das sieht ja ganz schön durcheinander gewürfelt aus. Folgendes verwirrt mich:

- /dev/sde1 ist offensichtlich out of sync. Was ist mit dem Laufwerk genau passiert?
- /dev/sdg1 gehört laut der RAID superblocks nicht zum RAID. Ein spare?
- /dev/sdk1 gehört laut der RAID superblocks nicht zum RAID. Ein spare?
- /dev/sdf1 & h1 gehören laut der RAID superblocks zum RAID, laut Deiner Aussage aber nicht? Sollten das evtl. /dev/sdg1 & /dev/sdk1 sein?

Bitte stelle sicher, dass in der device-namensgebung nichts durcheinandergekommen ist. Was hast Du genau am System verändert und in welcher Reihenfolge? Eine Disk fehlt nun offenbar ganz, da Du nur noch 8 statt 9 auflistest?

Zum weiteren Vorgehen: Bitte gehe absolut sicher, dass alle funktionierenden Platten korrekt angeschlossen sind und im System auftauchen. Dann etwas zum Lesen: https://raid.wiki.kernel.org/index.php/RAID_Recovery. Dort wird eigentlich beschrieben, was in Deinem Fall zu tun wäre (Temporärer Ausfall von mehr Disks als vom RAID abgedeckt).

mixn_mojo · 11. Mai 2012

Hallo,

nach Tagen des Bangens, läuft jetzt alles wieder.

Ein

Code:

mdadm -C /dev/md0 -v --assume-clean -n9 -l6 -e0 -c256 /dev/sdb1 missing /dev/sd{c,j,e,f,k,l,h}1

hat geholfen.

Das Problem in dem Fall war dann, die richtige Chunk Size zu finden sowie die die richtige Plattenreihenfolge zu rekonstruieren.

Besten Dank nochmal für die Mühen.

Ernst@at · 11. Mai 2012

Danke für die Rückmeldung.
Für mich an der Zeit, auch mal in den Exkrementen des Tux zu stochern.

gurdel · 15. Juli 2012

Hallo alle zusammen,

ich erdreiste mich mal, mich an diesen Thread anzuhängen, weil ich ein sehr ähnliches Problem habe. Ich habe vor einiger Zeit unter Squeeze ein Software Raid 5 über 4 Platten angelegt

Code:

mdadm --create /dev/md0 --level=5 --chunk=128 --raid-devices=4 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1

, darauf dann ein luks-Device welches als physical volume für LVM diente. Klappte alles bestens. Nach Umzug mit dem Array in einen neuen Rechner habe ich ein wenig mit hdparm "experimentiert" um die 4 drives in den standby bzw. sleep zu schicken. Das klappte soweit auch (bilde ich mir zumindest ein, jedenfalls hatte ich nach einigen sleep / wakeup-Zyklen immernoch Zugriff auf die Daten, habe aber den Status von /dev/md0 nie überprüft). Dann aber kam die Katastrophe über mich: 2 der 4 Disks wachten nicht mehr auf. Logs zu dieser Zeit:

Code:

Jul 15 11:21:12 EBENE kernel: [30046.863193] sd 2:0:0:0: [sdc] Unhandled error code
Jul 15 11:21:12 EBENE kernel: [30046.863197] sd 2:0:0:0: [sdc]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Jul 15 11:21:12 EBENE kernel: [30046.863201] sd 2:0:0:0: [sdc] CDB: Read(10): 28 00 2f 91 75 00 00 00 a0 00
Jul 15 11:21:12 EBENE kernel: [30046.863374] sd 0:0:0:0: [sda] Unhandled error code
Jul 15 11:21:12 EBENE kernel: [30046.863376] sd 0:0:0:0: [sda]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Jul 15 11:21:12 EBENE kernel: [30046.863378] sd 0:0:0:0: [sda] CDB: Read(10): 28 00 2f 91 75 00 00 00 a0 00
Jul 15 11:21:12 EBENE kernel: [30046.864442] sd 0:0:0:0: [sda] Unhandled error code
Jul 15 11:21:12 EBENE kernel: [30046.864445] sd 0:0:0:0: [sda]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Jul 15 11:21:12 EBENE kernel: [30046.864449] sd 0:0:0:0: [sda] CDB: Read(10): 28 00 2f 91 76 00 00 00 a0 00
Jul 15 11:21:12 EBENE kernel: [30046.864508] sd 2:0:0:0: [sdc] Unhandled error code
Jul 15 11:21:12 EBENE kernel: [30046.864510] sd 2:0:0:0: [sdc]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Jul 15 11:21:12 EBENE kernel: [30046.864513] sd 2:0:0:0: [sdc] CDB: Read(10): 28 00 2f 91 75 a0 00 00 60 00
Jul 15 11:21:12 EBENE kernel: [30046.864638] sd 0:0:0:0: [sda] Unhandled error code
Jul 15 11:21:12 EBENE kernel: [30046.864640] sd 0:0:0:0: [sda]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Jul 15 11:21:12 EBENE kernel: [30046.864642] sd 0:0:0:0: [sda] CDB: Read(10): 28 00 2f 91 75 a0 00 00 60 00
Jul 15 11:21:12 EBENE kernel: [30046.864680] sd 2:0:0:0: [sdc] Unhandled error code
Jul 15 11:21:12 EBENE kernel: [30046.864681] sd 2:0:0:0: [sdc]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Jul 15 11:21:12 EBENE kernel: [30046.864683] sd 2:0:0:0: [sdc] CDB: Read(10): 28 00 2f 91 76 00 00 00 a0 00
Jul 15 11:23:38 EBENE kernel: [30192.746530] sd 0:0:0:0: [sda] Unhandled error code
Jul 15 11:23:38 EBENE kernel: [30192.746534] sd 0:0:0:0: [sda]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Jul 15 11:23:38 EBENE kernel: [30192.746539] sd 0:0:0:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 20 00
Jul 15 11:23:38 EBENE kernel: [30192.746810] sd 0:0:0:0: [sda] Unhandled error code
Jul 15 11:23:38 EBENE kernel: [30192.746812] sd 0:0:0:0: [sda]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Jul 15 11:23:38 EBENE kernel: [30192.746815] sd 0:0:0:0: [sda] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00

da ich nichts wichtiges auf das Array geschrieben habe (zum Aufwach-testen nur 512 Byte Daten mittels dd in eine Datei geschrieben) habe ich einfach einen restart durchgeführt, damit die Platten sich wieder fangen. Das taten sie dann auch, nur dummerweise das RAID nicht. Zwei disk active, zwei nicht. Ich bin dann so vorgegangen wie unter https://raid.wiki.kernel.org/index.php/RAID_Recovery beschrieben, also der gleiche Weg, den mixn_mojo gegangen ist.
Mittels

Code:

mdadm --examine /dev/sd[acde]1 > raid.status

raidstatus gesichert, dann

Code:

grep Role raid.status

Device Role : Active device 3
Device Role : Active device 1
Device Role : Active device 2
Device Role : Active device 0
und dann:

Code:

mdadm --create --assume-clean --level=5 --raid-devices=4 --chunk=128 /dev/md0 /dev/sde1 /dev/sdc1 /dev/sd1 /dev/sda1

Daraufhin kam zwar ein /dev/md0, dieses enthielt aber nicht meine Daten (cryptSetup luksOpen ... funktionierte nicht, kein luksHeader).
Habe daraufhin mit einem provisorischen script sämtliche 24 möglichen Permutationen in der disk-Anordnung ausprobiert, aber bei keiner war anschliessend ein luks-Header auf /dev/md0. Ich befürchte, dass ich mein Array irgendwie kaputtgespielt habe.
Die Ausgabe von

Code:

mdadm --examine /dev/sd[acde]1 > raid.status

:

Code:

/dev/sda1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 65089aca:483766d3:0db55271:27c73384
           Name : oldman:0
  Creation Time : Sun Jun 26 14:35:51 2011
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 3907024896 (1863.01 GiB 2000.40 GB)
     Array Size : 5860536576 (5589.04 GiB 6001.19 GB)
  Used Dev Size : 3907024384 (1863.01 GiB 2000.40 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : 3d7a888c:7488a859:f53a0fe5:5bbc1bda

    Update Time : Sat Jul 14 22:08:08 2012
       Checksum : eeb6d1f1 - correct
         Events : 266

         Layout : left-symmetric
     Chunk Size : 128K

   Device Role : Active device 3
   Array State : AAAA ('A' == active, '.' == missing)
/dev/sdc1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 65089aca:483766d3:0db55271:27c73384
           Name : oldman:0
  Creation Time : Sun Jun 26 14:35:51 2011
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 3907024896 (1863.01 GiB 2000.40 GB)
     Array Size : 5860536576 (5589.04 GiB 6001.19 GB)
  Used Dev Size : 3907024384 (1863.01 GiB 2000.40 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : 578cb781:387a3537:e42e9414:3d6e25e7

    Update Time : Sat Jul 14 22:08:08 2012
       Checksum : fe017b9c - correct
         Events : 266

         Layout : left-symmetric
     Chunk Size : 128K

   Device Role : Active device 1
   Array State : AAAA ('A' == active, '.' == missing)
/dev/sdd1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 65089aca:483766d3:0db55271:27c73384
           Name : oldman:0
  Creation Time : Sun Jun 26 14:35:51 2011
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 3907024896 (1863.01 GiB 2000.40 GB)
     Array Size : 5860536576 (5589.04 GiB 6001.19 GB)
  Used Dev Size : 3907024384 (1863.01 GiB 2000.40 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : 3dc3e9e2:ab9a2199:5618c6cd:ca0631fa

    Update Time : Sun Jul 15 11:25:20 2012
       Checksum : 8d5c0fd0 - correct
         Events : 271

         Layout : left-symmetric
     Chunk Size : 128K

   Device Role : Active device 2
   Array State : A.A. ('A' == active, '.' == missing)
/dev/sde1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 65089aca:483766d3:0db55271:27c73384
           Name : oldman:0
  Creation Time : Sun Jun 26 14:35:51 2011
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 3907024896 (1863.01 GiB 2000.40 GB)
     Array Size : 5860536576 (5589.04 GiB 6001.19 GB)
  Used Dev Size : 3907024384 (1863.01 GiB 2000.40 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : 22ecbee2:a26678a3:c2aeca18:007edd48

    Update Time : Sun Jul 15 11:25:20 2012
       Checksum : 3139124b - correct
         Events : 271

         Layout : left-symmetric
     Chunk Size : 128K

   Device Role : Active device 0
   Array State : A.A. ('A' == active, '.' == missing)

Hat evtl. noch jemand eine hilfreiche Idee, ich wäre wirklich sehr dankbar

freundliche Grüße
André

Suche

[Linux] mdadm Raid-Array verloren

mixn_mojo

Lieutenant Pro

VPN-User

Ensign

mixn_mojo

Lieutenant Pro

VPN-User

Ensign

mixn_mojo

Lieutenant Pro

Ernst@at

Admiral

gurdel

Newbie

Ähnliche Themen

Passend zum Thema

SM8466 Silicon Motion arbeitet an erstem PCIe-6.0-SSD-Controller

Corsair EX400U Erste Benchmarks zum Marktstart der schnellen USB4-SSD

HAMR-Festplatten Update Seagate erhöht auf 36 TB mit 10 Scheiben und SMR