[gelöst] hw_raid6 & LUKS & mkfs.ext4 = freeze ?!

[Rendal]

Hallo zusammen,

es ist mal wieder soweit, nach vielen erfolgreichen Versuchen mit VM´s und unzähligen Distro´s entschied ich mich meinen kleinen Heimserver zu optimieren.

Meine HW
i7 6700k mit 16GB Ram
3ware 9650SE mit 16 Ports
USB-Stick 64 GB (boot/efi)
SSD 256GB auf sata1 (root) mit LUKS
SSD 256GB auf sata2 für Win10 in einer VM
BluRay auf sata3
3TB Daten für die VM auf hw_raid in single Disk (über 3ware 9650SE)

= läuft super. ABER

Ich habe noch 5x WD RED 3TB hier welche auf dem Raid Controller ein Raid 6 ergeben (~ 8,2 TB Daten auf /dev/sdc).

Ziel:
Ich möchte sdc verschlüsseln, mit ext4 Formatieren und per /etc/crypttab & fstab beim start mit einem key einhängen.

1. Partition Table erstellt (fdisk order gdisk = kein Thema)

Code: Alles auswählen

sdc                                8:32   0   8,2T  0 disk  
└─sdc1                             8:33   0   8,2T  0 part  

2. cryptsetup -c aes-xts-plain64 -y -s 512 luksFormat /dev/sdc1

3. cryptsetup luksOpen /dev/sdc1 sdc1_crypt

4. mkfs.ext4 /dev/mapper/sdc1_crypt

5. mount /dev/mapper/sdc1_crypt /mnt
Can´t read superblock

- oder -

4. mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/sdc1
-> system Freeze nach dem schreiben von ca 2000 Inodes (oder warens Superblöcke)


Frage:
Was übersehe ich ?!


Weiterer Test
wenn mkfs.ext4 dev/sdc1 dann läufts wie immer....

[rendegast]

stretch hat den kernel 4.4 bekommen,
damit gibt es auf anderem Feld Probleme (ZONE_DMA / sound).
Wie ist es mit dem vorherigen kernel 4.3?

Wie ist es mit jessie (3.16 / 4.3bpo / 4.4bpo)?
(falls radeon-Grafik, der aktuelle kernel 3.16.7-ckt25-1 ist buggy diesbezüglich,
gegebenenfalls das radeon-Modul beim Booten deaktivieren)



Hier jessie 4.4bpo (Doppelkern, haveged läuft),
schreibt in einen luks-Container auf tmpfs mit ~ 130MB/s
<-> als einfaches loop-device 730MB/s.

[Rendal]

stretch hat den kernel 4.4 bekommen,
damit gibt es auf anderem Feld Probleme (ZONE_DMA / sound).
Wie ist es mit dem vorherigen kernel 4.3?

Habe das System mit Raid6 und Verschlüsselung neu aufgesetzt, kann leider dazu nichts sagen ob es davor funktioniert hat oder nicht.

Wie ist es mit jessie (3.16 / 4.3bpo / 4.4bpo)?
(falls radeon-Grafik, der aktuelle kernel 3.16.7-ckt25-1 ist buggy diesbezüglich,
gegebenenfalls das radeon-Modul beim Booten deaktivieren)

Derzeit ist keine AMD Grafikkarte verbaut bzw werden Treiber genutzt.
Den möglichen Sprung auf Stable +bpo hatte ich anfangs in Betracht gezogen,
mich dann aber wegen der doch neuen Hardware und neueren Software
dagegen entschieden. Als Plan B kommt das aber in Frage.

Nur zu erst möchte ich versuchen das entweder "auszusitzen" oder
das Problem zu beseitigen.

Ich habe noch einen Tests gemacht:
Single Drive -> crypt -> ext4 -> läuft

Werde das ganze nochmal mit anderen möglichen Raid´s testen.... derzeit,
wenn ich mit dem Finger auf den Fehler zeigen soll müsste, würde ich auf
den Kernel oder das cryptomodul deuten....
Oder hat jemand noch ne Idee?

MfG

[NAB]

Eh ... also ohne deinen Raid-Controller dazwischen läuft es, und mit Controller nicht? Ich würd ja den Controller mal scharf angucken ...

[Rendal]

Also Single Disk am Raidkontroller
Raid6 ohne LUKS geht auch

weiteres werde ich noch testen...

[NAB]

Raid6 ohne LUKS geht auch

Ah!
Eh ... sicher? Kann die Firmware mehr als 2 TB? Sonst kann es da komische Überraschungen geben.
Und bleibt der Controller kühl genug?

Und ist "intel-microcode" installiert?

hmmm ... dein Raid6 hat vermutlich eine höhere Schreibperformance als eine "single disk". Also hätte die AES-NI-Einheit bei einem Crypt-Container mehr zu tun als ohne. Ist die CPU übertaktet?

[Rendal]

Die Hardware wird nicht übertaktet (Spezifikation in der Signatur). Der PC lief vorher mit Win7 und
DiskCryptor Vollverschlüsselung mit folgender Konfiguration:

2x Samsung SSD 840 Pro 256GB im Raid 0 (System+Programme)

3Ware 9650SE ML 16
-> 5x WD RED 3TB Raid6
-> 2x Samsung Green 2TB im Raid 1
-> 1x WD Green 3TB als Single Drive

Die Hardware machte bis heute keine Probleme, was natürlich nichts zu 100% ausschließt.
Zudem testete ich kurz Win10, was ebenso lief (inkl. Raid und Verschlüsselung).


Am vorher installierten Stretch lies ich das Raid und die Verschlüsselung erst außen vor, da ich mich selbst in die Thematik
von einem verschlüsseltem Linux Systeme einlesen und via Virtueller Maschine testen wollte.


Derzeitige Konfiguration von Stretch
Der CPU schafft 3000 MB lesen/schreiben mit Verschlüsselung

System ist als (U)EFI und GRUB Bootloader installiert.
USB3.0: SanDisk USB 64GB als BOOT USB Stick ohne Verschlüsselung mit den Partitionen boot und efi
MB SATA3: 1x Samsung 840 Pro für / mit LUKS und LVM (Passworteingabe beim Booten nach GRUB)
MB SATA3: 1x Samsung 840 Pro ohne Verschlüsselung als Ablage für qcow2 Dateien

3ware 9650 als Datenspeicher
Single Drive Eine WD Green 3TB als Single Drive (keine Verschlüsselung, Filesystem ext4)
Raid6 5x WD Red 3TB (mit LUKS ohne LVM, hier das Problem mit dem Filesystem)

Zur genaueren Beschreibung:
Das Raid6 wurde am Controller neu initialisiert. -> OK
Im System ist es als /dev/sdc erkannt (siehe oben) -> OK
Partitioniert mit gdisk -> OK

Abholpunkt 1
mkfs.ext4 /dev/sdc1 -> Die LED´s der Platten fangen an zu arbeiten (mehrere Backplanes mit Icy Box IB-553SSK) -> Fertig
mounten und Zugriff möglich, Schreiben mit ca 350 MB/s (getestet mit ISO´s von der Verschlüsselten SSD)

Abholpunkt 2 (Setup wie oben bis Punkt 1)
cryptsetup mit den im ersten Post genannten Werten -> OK
luksOpen in /dev/mapper/daten -> OK
lsblk zeigt den gemappten Container an -> OK
mkfs.ext4 /dev/mapper/daten ->

LED´s beginnen nicht zu blinken,
HDD´s arbeiten akustisch nicht,
Vorgang dauert ca 5 Minuten

Platz für EDIT: Ein Bild fürs Protokoll hänge ich hier am Freitag ein, habe ab dann leider erst wieder Zeit

mounten -> can´t read superblock

Das System lässt sich daraufhin auch per sudo init 6 nicht richtig herunterfahren,
der Prozess mkfs.ext4 hängt mit deepsleep in den Prozessen

Ein Formatieren mit ext3 / vfat war ebenso ohne Erfolg.
Eine Deaktivierung aller Write Cache´s und andere Funktionen brachte auch keine Besserung


PS: Temperaturwerte und Installation des intel-microcode teste ich ebenso Freitag

[NAB]

Ehm ... warte ... verstehe ich das richtig ... der Befehl "mkfs.ext4" tut so, als sei er fertig, beendet sich aber nie? Da würde ich auch auf den Write Cache tippen. Verändert sich das Verhalten ohne Write Cache denn irgendwie? (Auch wenn's nicht besser wird)

Wird ein "sync" fertig?

Und wir haben bisher überhaupt keine verwertbare Fehlermeldung. Findet sich in "dmesg" irgendwas auffälliges?

Du kannst auch direkt auf /dev/mapper/daten schreiben. Damit zerstörst du natürlich jeglichen Inhalt, aber da ist ja eh nichts drauf. Du kannst z.B. mit "dd" ein DVD-Image da rein kopieren. Beim Auslesen musst du angeben, wieviele Bytes du lesen willst. Interessant wäre, ob das Geschriebene zum Gelesenen identisch ist.

Und nebenbei ... hat das Win7 auch über UEFI gebootet, oder über BIOS? Ich frage, weil die Firmware des Controllers jeweils unterschiedlich initialisiert worden sein könnte.

[Rendal]

Danke NAB der Hinweis auf den microcode war die Lösung.

Nach einer Auswertung von dmesg habe ich folgende Pakete nachinstalliert (non-free)

Für den CPU + iGPU
intel-microcode (3.20151106.1)
iucode-tool (1.5.1-1)
firmware-misc-nonfree (20160110-1)

Danach funktionierte alles wie es soll

Und wieder was gelernt

[NAB]

Dein BIOS solltest du auch noch aktualisieren

[Rendal]

Hab ich gemacht, alles stabil. Den Rest wird der Dauereinsatz zeigen...

Kleiner Test:
von der SSD kopiere ich auf´s Raid6 mit 400 MB/s (crypto to crypto)