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.