md_update_sb поддерживает загрузочный RAID 1 занятым

md_update_sb поддерживает загрузочный RAID 1 занятым

Я установил Ubuntu 18.04 LTS на 4 жестких диска в конфигурации RAID 1. Что-то держит жесткие диски занятыми, и они никогда не останавливаются. Что я сделал: - отобразил часто используемые каталоги (/var/log, /tmp и т. д.) как tmpfs в памяти - заблокировал /bin, /sbin и несколько библиотек через vmtouch в памяти

После этих изменений iotop показывает, что к массиву имеет доступ только kworker.

btrace показывает это:

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

Если я правильно понял трассировку, что-то обновляет суперблок массива? Что еще я могу сделать, чтобы отследить, что не дает дискам спать?

Обновление 1: RAID 6 также настроен на тех же дисках, но он не смонтирован и, похоже, к нему нет доступа.

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>

Обновление 2: inotifywait -r -m /отслеживает все обращения к файловой системе. Постепенно отфильтровывая все, что уже смонтировано в памяти...

inotifywait -r -m / @/dev @/sys @/proc @/run @/var/tmp @/tmp @/var/log @/var/spool

... показал snapd записывает файлы. Поскольку я не знаю ничего, что требует snapd в моей установке, я очистил его.

решение1

В любом случае, следуя логам inotifywait, я обнаружил один за другим процессы (их было много!), пишущие в файловую систему. Я переназначил каждый каталог на tmpfs с помощью загрузочного скрипта, скопировал файлы в tmpfs и перемонтировал его вместо расположения в файловой системе, а затем скопировал файлы обратно при выключении. Это имеет оговорки, но пока сойдет.

Связанный контент