Ich habe Ubuntu 18.04 LTS auf 4 Festplatten in einer RAID 1-Konfiguration installiert. Irgendetwas hält die Festplatten beschäftigt und sie fahren nie herunter. Was ich getan habe: - häufig aufgerufene Verzeichnisse (/var/log, /tmp usw.) als tmpfs in den Speicher gemappt - /bin, /sbin und mehrere Bibliotheken über vmtouch in den Speicher gesperrt
Nach diesen Änderungen zeigt iotop nur Kworker an, die auf das Array zugreifen.
btrace zeigt Folgendes:
9,0 0 0 350.464025971 0 m N md md_update_sb
9,0 0 98 350.849029580 2206 Q WM 71305144 + 8 [kworker/u128:0]
9,0 0 99 350.849034110 2206 Q WM 71305216 + 8 [kworker/u128:0]
9,0 0 100 350.849038452 2206 Q WM 71371648 + 8 [kworker/u128:0]
9,0 0 101 350.849045694 2206 Q W 0 + 8 [kworker/u128:0]
9,0 0 102 350.849048534 2206 Q WM 40 + 8 [kworker/u128:0]
9,0 1 137 350.976982774 0 C W 0 + 8 [0]
9,0 1 138 350.994303913 0 C WM 40 + 8 [0]
9,0 1 139 350.997638530 0 C WM 71303296 + 8 [0]
9,0 1 140 351.011237159 353 C WM 71305144 + 8 [0]
9,0 1 141 351.011403025 0 C WM 71305216 + 8 [0]
9,0 1 142 351.276814094 353 C WM 71371648 + 8 [0]
9,0 0 0 351.599976239 0 m N md md_update_sb
Wenn ich die Ablaufverfolgung richtig verstehe, aktualisiert etwas den Superblock des Arrays? Was kann ich sonst noch tun, um herauszufinden, was die Festplatten wach hält?
Aktualisierung 1: Auf denselben Festplatten ist auch ein RAID 6 eingerichtet, aber es ist nicht gemountet und es scheint kein Zugriff darauf möglich zu sein.
cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md127 : active raid6 sde3[5] sdd3[4] sdc3[1] sdb3[0]
10737154048 blocks super 1.2 level 6, 512k chunk, algorithm 2 [4/4] [UUUU]
bitmap: 0/40 pages [0KB], 65536KB chunk
md0 : active raid1 sde2[5] sdd2[4] sdc2[2] sdb2[6]
52395008 blocks super 1.2 [4/4] [UUUU]
unused devices: <none>
Aktualisierung 2: inotifywait -r -m /verfolgt alle Zugriffe auf das Dateisystem. Filtert nach und nach alles heraus, was bereits im Speicher gemountet ist ...
inotifywait -r -m / @/dev @/sys @/proc @/run @/var/tmp @/tmp @/var/log @/var/spool
... zeigte, wie Snapd Dateien schreibt. Da ich nichts in meiner Installation kenne, das Snapd benötigt, habe ich es gelöscht.
Antwort1
Wie dem auch sei, ich habe anhand der inotifywait-Protokolle nacheinander die Prozesse gefunden (es waren viele!), die in das Dateisystem schrieben. Ich habe jedes Verzeichnis mit einem Boot-Skript einem tmpfs neu zugeordnet, Dateien in das tmpfs kopiert und es anstelle des Dateisystemspeicherorts neu gemountet und dann die Dateien beim Herunterfahren zurückkopiert. Das hat zwar seine Tücken, aber für den Moment reicht es.