zfsd: unable to shutdown after pulling drive, high CPU load and syslog 'spamming' after rebooting

[Marco Steinbach]

Hi.

I'm using FreeBSD 11.2-STABLE #0 r339774 amd64.

For getting a better grip on zfsd and its capabilities, I plugged in a
USB drive (Samsung EVO in an external case driven by a JMicron),
created a zpool, a dataset, and then pulled the drive in the middle of
a cp(1) operation.

The cp then hangs as expected, but I'm still able to issue zpool/zfs
commands, and my zroot stays fully operational -- which is great, since
without zfsd I am used to any zpool command simply hanging after
loosing a device, forcing me to reboot.

Here's my questions:

1. Trying to shutdown(8) the system after pulling the drive does not
shutdown the machine. Instead, what I see on the console is the
following (transcribed from a photo I took with my mobile):

[...]
Writing entropy file:.
Writing early boot entropy file:.
90 econd watchdog timeout expired. Shutdown terminated.
[Timestamp displayed]
[Timestamp] bsdbuch init: /bin/sh on /etc/rc.shutdown terminated
abnormally, going to single user mode
[Timestamp] bsdbuch: syslogd exiting on signal 15
[Timestamp] init: some processes would not die; ps axl advised

I've tried this a few times, and waited for increasing amounts of time,
tapping <enter> and <space> occassionally, but after that last message,
nothing happens and I had to power off manually.

Also, in /var/log/syslog I see the following message
right before the watchdog timeout:

[Timestamp] console-kit-daemon[40332]: WARNING: Error waiting for
native console 3 activation: Inappropriate ioctl for device

(I am using i915kms, I tried switching consoles during shutdown to no
avail after seeing this message for the first time -- as expected)

Is the inability to shutdown intended behaviour or am
I missing something ?


2. After the machine comes back up, zfsd seems to hog one of the CPU
cores, busying itself in cooperation with devd, which seems to
consume about half a CPU core, with spilling a boatload of messages to
syslog like so:

[Timestamp] bsdbuch ZFS: vdev state changed,
pool_guid=3748130264323902517 vdev_guid=2431471203435552468
[Timestamp] bsdbuch syslogd: last message repeated 505 times

Replugging the USB drive, and thus making the pool available again
brings the load back to normal.

Is this also intended behaviour ?


MfG CoCo