Nicht schön. Nach dem Reboot eines Server musste ich feststellen, dass diverse Storages nicht mehr zugreifbar waren. Schnell stellte sich heraus, dass alle ZFS-Pools offline waren und die Geräte mit der Meldung „too many errors“ als FAULTED markiert wurden.
zpool import
pool: tempstore
id: xyz
state: UNAVAIL
status: One or more devices are faulted.
action: The pool cannot be imported due to damaged devices or data.
config:
tempstore UNAVAIL insufficient replicas
sdd FAULTED too many errors
sde FAULTED too many errors
pool: storage
id: xyy
state: UNAVAIL
status: One or more devices are faulted.
action: The pool cannot be imported due to damaged devices or data.
config:
storage UNAVAIL insufficient replicas
sdb FAULTED too many errors
Nunja, Consumer-Platten traue ich ja viele defekte zu, aber drei unabhängige Platten gleichzeitig? Eher nein. Auch S.M.A.R.T. zeigte keine wirklich bedenkenswerten Werte. Aufschlussreicher ist da schon das Kernel-Log:
[ 776.890127] Large kmem_alloc(131128, 0x1000), please file an issue at:
https://github.com/zfsonlinux/zfs/issues/new
[ 776.890129] CPU: 1 PID: 12969 Comm: vdev_open Tainted: P O 4.4.39-gentoo-adlerweb #2
[ 776.890130] Hardware name: LENOVO yxz/ , BIOS xyz 01/10/2012
[ 776.890132] 0000000000000000 ffff880417a37bc0 ffffffff813545d8 000000000240c200
[ 776.890134] 0000000000000000 ffff880417a37c00 ffffffffa0018af1 0000000017a37be0
[ 776.890138] 0000000000000000 ffff88041626d480 ffff8804174ed660 0000000000004000
[ 776.890139] Call Trace:
[ 776.890144] [<ffffffff813545d8>] dump_stack+0x4d/0x65
[ 776.890148] [<ffffffffa0018af1>] spl_kmem_zalloc+0x131/0x180 [spl]
[ 776.890163] [<ffffffffa0109aa8>] vdev_cache_stat_fini+0x258/0xcc0 [zfs]
[ 776.890175] [<ffffffffa010a3ba>] vdev_cache_stat_fini+0xb6a/0xcc0 [zfs]
[ 776.890188] [<ffffffffa014426a>] zio_data_buf_free+0x51a/0xdc0 [zfs]
[ 776.890200] [<ffffffffa014798f>] zio_nowait+0xaf/0x190 [zfs]
[ 776.890215] [<ffffffffa0104cce>] vdev_probe+0xfe/0x200 [zfs]
[ 776.890228] [<ffffffffa01059e0>] ? vdev_accessible+0x70/0x2b0 [zfs]
[ 776.890240] [<ffffffffa0107969>] vdev_open+0x3c9/0x4b0 [zfs]
[ 776.890251] [<ffffffffa0107bdd>] vdev_open_children+0x18d/0x1c0 [zfs]
[ 776.890254] [<ffffffffa001b8ec>] taskq_dispatch+0x3ac/0x5b0 [spl]
[ 776.890257] [<ffffffff810c1ed0>] ? wake_up_q+0x70/0x70
[ 776.890261] [<ffffffffa001b6e0>] ? taskq_dispatch+0x1a0/0x5b0 [spl]
[ 776.890263] [<ffffffff810b8c04>] kthread+0xc4/0xe0
[ 776.890265] [<ffffffff810b8b40>] ? kthread_park+0x50/0x50
[ 776.890268] [<ffffffff81a6a5df>] ret_from_fork+0x3f/0x70
[ 776.890270] [<ffffffff810b8b40>] ? kthread_park+0x50/0x50
*kick* Da war ja was. ZOL läuft wegen der Lizenzproblematik als Kernel-Modul. Ich hatte zuletzt am Kernel einige Treiber nachgezogen. Hierbei sind zwar Version und Ablageort gleich geblieben, offenbar ist aber die ABI etwas gewandert, sodass SPL/ZFS etwas verwirrt den Dienst quittierten.
Für Gentoo heißt das einmal Module neu Bauen, in meinem Fall
emerge -va spl zfs-kmod
Alternativ und in den meisten Fällen zuverlässiger ist es nach jeder Kernel-Änderung alle Module automatisch neu zu erstellen:
emerge -va @module-rebuild
Storage online, Admins glücklich, Update-Doku ergänzt. Passt.
