From owner-freebsd-fs@freebsd.org Mon Nov 19 19:50:30 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85ED61125468 for ; Mon, 19 Nov 2018 19:50:30 +0000 (UTC) (envelope-from coco@executive-computing.de) Received: from mail.moehre.org (mail.moehre.org [195.96.35.7]) by mx1.freebsd.org (Postfix) with ESMTP id CC27F89BBE for ; Mon, 19 Nov 2018 19:50:29 +0000 (UTC) (envelope-from coco@executive-computing.de) Received: from mail.moehre.org (unknown [195.96.35.7]) by mail.moehre.org (Postfix) with ESMTP id 130923A702 for ; Mon, 19 Nov 2018 20:50:29 +0100 (CET) X-Spam-Flag: NO X-Spam-Score: -100.818 X-Spam-Level: X-Spam-Status: No, score=-100.818 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, AWL=0.105, TW_ZF=0.077, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mail.moehre.org ([195.96.35.7]) by mail.moehre.org (mail.moehre.org [195.96.35.7]) (amavisd-new, port 10024) with ESMTP id cr5qTLt8eRQK for ; Mon, 19 Nov 2018 20:50:28 +0100 (CET) Received: from bsdbuch.c0c0.intra (p54BEC3C8.dip0.t-ipconnect.de [84.190.195.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: coco@executive-computing.de) by mail.moehre.org (Postfix) with ESMTPSA id 9EC5E3A6FB for ; Mon, 19 Nov 2018 20:50:28 +0100 (CET) Date: Mon, 19 Nov 2018 20:50:40 +0100 From: Marco Steinbach 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> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd11.2) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: CC27F89BBE X-Spamd-Result: default: False [-0.76 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.76)[-0.763,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[executive-computing.de]; NEURAL_SPAM_SHORT(0.22)[0.217,0]; MX_GOOD(-0.01)[cached: mail.moehre.org]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; IP_SCORE(-0.00)[country: DE(-0.01)]; ASN(0.00)[asn:8354, ipnet:195.96.32.0/19, country:DE]; RECEIVED_SPAMHAUS_PBL(0.00)[200.195.190.84.zen.spamhaus.org : 127.0.0.10] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 19:50:30 -0000 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 and 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