Я ненавижу, грубо говоря, но сохраняю себя ТОННА боли. При продолжении вниз этого пути Вы будете выбирать остатки компромисса в течение последующих лет. Так как это - сервер, Вы не должны делать никакой очистки вообще. Клонируйте диски и отложите их для анализа позже. Вытрите сервер, восстановление от резервных копий.
Запустить обычный сценарий (cron), который проверяет вывод zpool status -x
. В долгосрочной перспективе проект ZFS в Linux работает над этим в форме демона событий. Системы, производные от Solaris, имели доступ к архитектуре управления отказами.
Что касается автоматических отчетов, даже коммерческие решения, такие как NexentaStor , используют плановые проверки. В этом нет ничего плохого.
Примерно так:
[root@mdmarra ~]# zpool status -x
all pools are healthy
Против чего-то ужасного, например:
[root@mdmarra ~]# zpool status -x
pool: vol1
state: UNAVAIL
status: One or more devices are faulted in response to IO failures.
action: Make sure the affected devices are connected, then run 'zpool clear'.
see: http://www.sun.com/msg/ZFS-8000-JQ
scan: scrub repaired 0 in 1h15m with 0 errors on Sun Jul 28 21:15:10 2013
config:
NAME STATE READ WRITE CKSUM
vol1 UNAVAIL 0 0 0 insufficient replicas
mirror-0 DEGRADED 0 0 0
c1t0d0 UNAVAIL 0 0 0 cannot open
c2t0d0 ONLINE 0 0 0
mirror-1 DEGRADED 0 0 0
c1t1d0 UNAVAIL 0 0 0 cannot open
c2t1d0 ONLINE 0 0 0
mirror-2 DEGRADED 0 0 0
spare-0 UNAVAIL 0 0 0 insufficient replicas
c1t2d0 UNAVAIL 0 0 0 cannot open
c2t8d0 UNAVAIL 0 0 0 cannot open
c2t2d0 ONLINE 0 0 0
mirror-3 DEGRADED 0 0 0
c1t3d0 UNAVAIL 0 0 0 cannot open
c2t3d0 ONLINE 0 0 0
mirror-4 DEGRADED 0 0 0
c1t4d0 UNAVAIL 0 0 0 cannot open
c2t4d0 ONLINE 0 0 0
mirror-5 UNAVAIL 0 0 0 insufficient replicas
c1t5d0 UNAVAIL 0 0 0 cannot open
c2t5d0 FAULTED 0 0 0 too many errors
cache
c3t5d0 ONLINE 0 0 0
spares
c2t8d0 UNAVAIL cannot open
errors: No known data errors