Skip to content

Festplatten-Sektoren bei USB-SATA Gehäusen

Der Witz zu diesem Thema schreibt sich wie von selbst - "2013 hat angerufen und will seine USB-Gehäuse wieder". Manch einer erinnert sich an die Zeit, als man die neuen SATA-Festplatte aus dem PC ausgebaut in ein USB-Gehäuse steckte und - zack - es ging nichts. Die Partitionen wurden mit zig Terrabyte Kapazität angezeigt, liessen sich aber nicht mounten. Man kam nicht mehr an die Daten ran.



Die Ursache damals waren die neuen Festplatten, welche mit 4096-Byte Sektoren sich direkt per SATA verbunden an der Southbridge meldeten. Die USB-Gehäuse waren aber auf die alten Festplatten mit 512-Byte Sektoren eingestellten und nahmen diesen Wert auch sturr bei den neuen Festplatten an. Dadurch waren die Werte in der Partitionstabelle um den Faktor 8 (4096 statt 512er Sektoren) zu gross. Dazu kam dann noch die Umstellung von MBR auf GPT, wobei Tools (fdisk) noch kein GPT konnten. Es blieb also Taschenrechner und "hexedit /dev/sda"... Das Chaos war also perfekt!



Jetzt haben wir 2018 und Festplattengeometrie ist mir ein wenig in Vergessenheit geraten. Zum Testen von meinem neuen NAS baue ich drei Notebookfestplatten in USB-Gehäuse, formatiere am PC darauf Raid,lvm,crypto und baue sie ins NAS. Das NAS erkennt aber nicht ein einziges Raid, sondern viele (md7, md126,md127,...) und synct fröhlich los (sic!). Also Festplatten wieder in USB-Gehäuse, PC an und auch am PC kein funktionierendes raid mehr!? Auch zu Fuss das raid zusammenbauen ging nicht:





$ mdadm --assemble /dev/md0 /dev/sda1 /dev/sdb1 /dev/sdc1
mdadm: no recogniseable superblock on /dev/sdc1
mdadm: /dev/sdc1 has no superblock - assembly aborted



Also sda1 und sdb1 haben ihren Superblock noch (!), aber sdc1 hat seinen verloren? Festplatte kaputt? Ne, S.M.A.R.T.-Werte alle OK.  Also wieder raid am PC gebaut und ins neue NAS und wieder zurück:





$ mdadm --assemble /dev/md0 /dev/sda1 /dev/sdb1 /dev/sdc1
mdadm: no recogniseable superblock on /dev/sdb1
mdadm: /dev/sdb1 has no superblock - assembly aborted
$ mdadm --assemble /dev/md0 /dev/sda1 /dev/sdc1 /dev/sdb1
mdadm: no recogniseable superblock on /dev/sdb1
mdadm: /dev/sdb1 has no superblock - assembly aborted



 



Also jetzt hat nur sdb1 seinen Superblock nicht mehr? Als dann Schächte tauschen am NAS keine Änderung brachte, habe ich mit den unterschieden Gehäusen mir sdb1 angeschaut:





$ #USB-3.0-Gehäuse
$ fdisk -l /dev/sdb
Festplatte /dev/sdb: 93,2 GiB, 100030242816 Bytes, 24421446 Sektoren
Einheiten: Sektoren von 1 4096 = 4096 Bytes
Sektorgröße (logisch/physikalisch): 4096 Bytes / 4096 Bytes
E/A-Größe (minimal/optimal): 4096 Bytes / 268431360 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0xc9093972

Gerät Boot Anfang Ende Sektoren Größe Kn Typ
/dev/sdb1 65535 24421445 24355911 92,9G fd Linux raid autodetect
$ #USB-2.0-Gehäuse
$ fdisk -l /dev/sdc
Festplatte /dev/sdc: 93,2 GiB, 100030242816 Bytes, 195371568 Sektoren
Einheiten: Sektoren von 1
512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0xc9093972

Gerät Boot Anfang Ende Sektoren Größe Kn Typ
/dev/sdc1 65535 24421445 24355911 11,6G fd Linux raid autodetect



Was war passiert?

Während das alte USB-2.0-Gehäuse 512-byte Sektoren an meinem PC angezeigt hat, hat das neue USB-3.0-Gehäuse 4096-byte Sektoren angezeigt. Die Festplatte aus dem USB-3.0-Gehäuse hat also eine Partitionstabelle auf 4k Sektoren bekommen und die im USB-2.0-Gehäuse Partitionstabellen auf Basis von 512-byte Sektoren.



Bei Festplatten und USB-Gehäusen muss man also immer nochmal ein Blick auf die Sektoregroesse werfen und alte Festplatten (kleiner 2TB?) nicht in neue (USB-3.0-)Gehäuse bauen!


DKB: Dauer der Kontoeröffnung

Für die logs: Vom Klicken "Kontoeröffnen" bis zum Zugriff auf Kreditkarte braucht es bei der DKB >4 Wochen. (Nix 2 Wochen, wie oft woanders im Internet steht!)


Man bekommt insgesamt 8 Briefe (Kontonummer, Girocard, Gircopin, VISAcard, Visapin, Tan, Tan-aktivierungscode, Online-Pin). Alle 3 Tage ein Brief.


Geld auf die Kreditkarte muss erst aufs Girokonto überwiesen werden (1-3Tage) und im onlinebanking auf die Kreditkarte "überwiesen" werden(1Tag).
Und es braucht nochmals um den Kreditkartenrahmen zu erhöhen, damit man die Karte mit 1500$ belasten kann als Pfand um ein Auto im Ausland zu leihen.



Ist es woanders schneller? Wie ist es bei der GLS? Die ist ja wenigstens moralischen Unbedenklich.

Neues Raid, Neues Glück: 4k Disk Alignment mit RAID, dmcrypt, LVM und ext4

Die 4k-Blöcke Problematik ist ja nichts neues, da mich das aber einen
langen Abend googlen und man-pages lesen gekostet hat fasse ich mal
zusammen.


Das Problem hat am Beispiel einer InnoDB in diesem Blogpost
ausführlichst erklärt. Im Bild dazu wird deutlich, warum man auf jeder
Schicht (RAID,LVM,..) auf das richtige alignment achten muss:


Beispiel anhand von innoDB


Außerdem lässt sich erahnen, warum beim Filesystem auf einem RAID5 die Aufteilung der Strides und Stripes eine wichtige Rolle spielen. Aber dazu später.



Bevors ans Einrichten geht, muss man sich Überlegen in welcher Reihenfolge man RAID,dmcrypt und LVM aufeinaner stapelt.
Ich habe mich bei meiner Konfiguration für folgendes Vorgehen entschieden:



  1. Burn-In. Klingt übertrieben, aber ich kenne da wen der nach einer Datenrettung auf ein neue Platte nochmals Daten retten musste..

  2. Da nicht jede 4TB Festplatte exakt 4TB groß ist, sollte man zu erst eine Partition erstellen die ein tick kleiner ist (parted -a optimal aligned automatisch).

  3. Dann kommt das RAID5. Entgegen diverser Anleitungen geht das mit dem 4k Alignment auch bei Superblock-1.2 (default).

  4. Dann LVM mit alignment.

  5. dmcrypt (mit --align-payload=8192 und auf embedded Geräten mit -i 10000)

  6. ext4 mit je nach Anzahl der Platten im Raid5 passenden Stripes und strides.


Am Ende sollte man das ganze nochmal Überprüfen und macht am besten noch einen Benchmark mit hdparm -tT oder bonnie++ und vergleicht das Ergebnis.