kernel / mm / slab.c
содержит несколько последних (январь, февраль 2017 г.) исправлений, направленных, среди прочего, на медленное разрушение кеша; в некоторых случаях операция уничтожения кеша могла длиться много часов. Сама операция также была дорогостоящей.
При этом вполне нормально видеть высокие цифры, если у вас много операций ввода-вывода на диске. Хотя, ваши подсчеты, вероятно, были высокими и, возможно, страдали от одной из исправленных ошибок, касающихся медленного разрушения.
В конце концов я нашел решение проблемы:
Я видел разные сообщения о статусе
в зависимости от того, какие диски я взял, чтобы снова поднять пул.
Я предпринял несколько попыток импортировать пул в деградированном состоянии с различными комбинациями четырех соответствующих дисков, и в итоге получил вот это:
NAME STATE READ WRITE CKSUM
zdata DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
dm-name-n8_2 ONLINE 0 0 0 (resilvering)
11141007683912581709 UNAVAIL 0 0 0 was /dev/disk/by-id/dm-name-n8_3
mirror-1 DEGRADED 0 0 0
16620393607066428577 FAULTED 0 0 0 was /dev/disk/by-id/dm-name-n8_0
dm-name-n8_0 ONLINE 0 0 0
mirror-2 DEGRADED 0 0 0
replacing-0 DEGRADED 85 0 0
1051730541091272780 FAULTED 0 0 0 was /dev/disk/by-id/dm-name-n8_4
dm-name-n8_6 ONLINE 0 0 85 (resilvering)
dm-name-n8_4 ONLINE 0 0 0 (resilvering)
mirror-3 DEGRADED 0 0 0
dm-name-n8_5 ONLINE 0 0 0
13833275275194605312 FAULTED 0 0 0 was /dev/disk/by-id/dm-name-n8_6
, что позволило мне очистить почти все данные с поврежденных дисков. Потери составили около ~0,1% (134 из >70000) файлов.
Насколько я понимаю, zfs хранит данные конфигурации на каждом устройстве этого пула и обеспечивает их синхронизацию. Может быть, отключение электричества повредило это или умирающие диски?
В любом случае, я снова счастлив. Спасибо, что читаете и помогаете!