staging.inyokaproject.org

Problem

Verzeichnis-Sync auf verschlüsselte LUKS-Partition blockiert Prozesse:

task kworker blocked for more than 120 seconds
task jbd2 blocked for more than 120 seconds
task rsync blocked for more than 120 seconds

Rettungsversuche

• ctrl+c rsync → kein Effekt

• kill -9 rsync Prozess → kein Effekt

• umount disk → target is busy

• shutdown -r now → Shutdown wird initiiert, bleibt aber hängen, weil Prozesse blockiert sind

• verschiedene rsync Optionen wie --whole-file, --block-size, --bwlimit, ohne -v → kein Erfolg

• rclone statt rsync → Resultat unverändert, task rclone blocked for more than 120 seconds

• andere Disk → kein Effekt

• andere Disk-Dockingstation, USB 3.1 statt eSATA → kein Effekt

• Upgrade von Ubuntu Server 18.04 LTS auf 20.04 LTS → ohne Erfolg

Systeminformationen

• Ubuntu Server 20.04.2 LTS

• rsync 3.1.3

• rclone 1.50.2

• Disks 3 TByte WD Red

• LUKS-Verschlüsselung gemäss Wiki-Artikel LUKS/Partitionen verschlüsseln

Meine Daten kopiere ich seit Jahren regelmässig mittels rsync auf eine externe Disk mit LUKS verschlüsselter ext4-Partition, bisher ohne Probleme. Seit dem Umzug auf eine neue Hardware mit grösseren Disks bleibt der Kopiervorgang aber immer stehen mit den oben beschriebenen Auswirkungen. Auf eine nicht verschlüsselte ext4-Partition lassen sich die Daten mittels rsync problemlos kopieren. Verbunden ist die externe Disk mittels eSATA, habe aber auch eine andere Docking-Station mit USB 3.1 ausprobiert, ohne Veränderung. Habe im Internet gelesen, dass sich IO-Buffer füllen können, was rsync und das gesamte System langsam machen kann. Aber dass Prozesse komplett einfrieren und sogar ein Shutdown verzögert wird, habe ich nicht gelesen.

Hätte jemand einen Tipp, was ich noch probieren oder analysieren könnte, um das Problem zu lösen?

mstd schrieb:

[…] Hätte jemand einen Tipp, was ich noch probieren oder analysieren könnte, um das Problem zu lösen?

Was sagt das Systemlog nach solch einem Ereignis und Neustart?

Auf das Systemlog vor dem aktuellen Hochlauf zugreifen und nach SUCHBEGRIFF filtern:

journalctl -b -1 | grep SUCHBEGRIFF 

Dabei ist das Wort „SUCHBEGRIFF“ natürlich in einem kreativen Gestaltungsprozess umzuformen.

Habe in der Zwischenzeit die LUKS verschlüsselte Disk nochmals komplett neu initialisiert gemäss LUKS/Partitionen verschlüsseln:

1
2
3

sudo cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 -y /dev/sde1
sudo cryptsetup luksOpen /dev/sde1 backupext
sudo mkfs.ext4 /dev/mapper/backupext

Dabei bleibt nun auch mkfs.ext4 im Schritt "Creating journal" stehen. Auf dem Raspberry Pi mit Ubuntu 20.04.2 LTS geht das ohne Probleme durch mit der gleichen Disk. Die Initialisierung der externen Disk hatte ich auf dem gleichen System gemacht, seit dem Update von Ubuntu Server 18.04 auf 20.04 läuft also auch dieser Befehl nicht mehr durch.

Den Output von "journalctl -b -1" zur Laufzeit von mkfs.ext4 habe ich als journalctl.txt angehängt.

mstd schrieb:

[…] Dabei bleibt nun auch mkfs.ext4 im Schritt "Creating journal" stehen.

Im Journal finden sich mehrere Meldungen dieser Art:

INFO: task kworker/u8:2:196 blocked for more than 120 seconds.
Tainted: P           O      5.4.0-67-generic #75-Ubuntu

Diese besagen:

• Ein offenbar hängender Prozess wurde abgeschossen.

• Du benutzt einen verdreckten (tainted) Kernel. Du hast irgendein Modul geladen, welches nicht zu offiziellen Kernel 5.4.0-67-generic gehört.

Auf dem Raspberry Pi mit Ubuntu 20.04.2 LTS geht das ohne Probleme durch mit der gleichen Disk.

Vielleicht benutzt Du auf diesem Rechner einen anderen Kernel oder Du eben nicht das Modul, welches den Dreck mitbringt.

Ob der Dreck allerdings auch ursächlich für die Abstürze ist, darf nicht daraus geschlossen werden. Möglich ist es aber.

Mit der neuen Ausgangslage, dass auch mkfs.ext4 nicht mehr funktioniert, bin ich auf diesen Beitrag gestossen: LUKS hangs on CentOS running on Atom C3758 CPU 🇬🇧. Offenbar steht das Problem im Zusammenhang mit Intel QAT (QuickAssist-Technik unter anderem zur Performance-Verbesserung von Verschlüsselungen). Zur Lösung des Problems wurde dabei entweder QAT im BIOS deaktiviert oder die QAT-Module wurden deaktiviert:

blacklist intel_qat /bin/false
blacklist qat_c3xxx /bin/false

Mit der Suche nach QAT finden sich auch Beiträge zum Thema:

• Writes stall using LUKS on Atom 3xxx Processor 🇬🇧

• dm-crypt fails to load on an Atom system 🇬🇧

• QAT drivers for C3XXX and C62X not included as modules 🇬🇧

Scheinbar betrifft das Problem Systeme mit Intel Atom C3xxx, in diesem System ist ein C3558 verbaut. Es finden sich auch Artikel die besagen, dass es Probleme im Zusammenhang mit QAT und der Virtualisierung (VT-d) gibt (Referenz 1) oder dass QAT nur bestimmte Blockgrössen oder Verschlüsselungen unterstützt (Referenz 2).

Habe mich daher entschieden, QAT im BIOS zu deaktivieren:

• Advanced → South Bridge Configuration → IQAT Configuration → IQAT → Disabled

Dadurch konnte das Problem gelöst werden und mkfs.ext4 sowie rsync laufen wieder problemlos durch. Spannenderweise gibt cryptsetup benchmark nach dem Deaktivieren von QAT sogar einen grösseren Durchsatz aus:

cryptsetup benchmark
Algorithm |       Key |      Encryption |      Decryption
  aes-xts        512b       565.0 MiB/s       561.0 MiB/s   (QAT disabled)
  aes-xts        512b       225.2 MiB/s       220.8 MiB/s   (QAT enabled)

Referenzen

1. Setup QAT Compatible Hardware 🇬🇧

2. Intel QuickAssist How to enable QAT for ZFS on Linux in CentOS 7 🇬🇧

@kB: Vielen Dank für deinen Support 😀

PS: Die Ursache für den Tainted Kernel liegt im Filesystem ZFS, welches für die zuverlässige Datenspeicherung verwendet wird. Die Installation erfolgte aus den offiziellen Paketquellen von Ubuntu (sudo apt-get install zfsutils-linux), aber die Lizenz CDDL ist die Ursache. Somit von dieser Seite nicht die Ursache für das Problem:

journalctl -k | grep taint
Mar 21 10:10:35 nas kernel: spl: loading out-of-tree module taints kernel.
Mar 21 10:10:35 nas kernel: znvpair: module license 'CDDL' taints kernel.
Mar 21 10:10:35 nas kernel: Disabling lock debugging due to kernel taint

Danke für die Rückmeldung. Ich habe im Wiki einen Hinweis hinzugefügt.