Date: Mon, 19 Nov 2018 20:50:40 +0100 From: Marco Steinbach <coco@executive-computing.de> To: freebsd-fs@freebsd.org Subject: zfsd: unable to shutdown after pulling drive, high CPU load and syslog 'spamming' after rebooting Message-ID: <20181119205040.2be0f039@bsdbuch.c0c0.intra>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181119205040.2be0f039>