From owner-freebsd-current@freebsd.org Thu Oct 24 22:27:55 2019 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5D47815BFC5 for ; Thu, 24 Oct 2019 22:27:55 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46zhhV2hkNz3DQq for ; Thu, 24 Oct 2019 22:27:53 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (localhost [IPv6:::1]) by chez.mckusick.com (8.15.2/8.15.2) with ESMTP id x9OMgVER001027; Thu, 24 Oct 2019 15:42:32 -0700 (PDT) (envelope-from mckusick@mckusick.com) Message-Id: <201910242242.x9OMgVER001027@chez.mckusick.com> From: Kirk McKusick To: "Bjoern A. Zeeb" Subject: Re: fsync: giving up on dirty, umount -f fails cc: "FreeBSD Current" X-URL: http://WWW.McKusick.COM/ Reply-To: Kirk McKusick In-reply-to: <132B079B-69D3-4525-A1B1-076514ED7ED5@lists.zabbadoz.net> Comments: In-reply-to "Bjoern A. Zeeb" message dated "Thu, 24 Oct 2019 07:58:39 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <1025.1571956951.1@chez.mckusick.com> Content-Transfer-Encoding: 8bit Date: Thu, 24 Oct 2019 15:42:31 -0700 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,MISSING_MID, UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on chez.mckusick.com X-Rspamd-Queue-Id: 46zhhV2hkNz3DQq X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of mckusick@mckusick.com has no SPF policy when checking 70.36.157.235) smtp.mailfrom=mckusick@mckusick.com X-Spamd-Result: default: False [-1.11 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[mckusick@mckusick.com]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-0.93)[-0.934,0]; NEURAL_HAM_LONG(-0.98)[-0.981,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[mckusick.com]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[235.157.36.70.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:46375, ipnet:70.36.128.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-0.09)[ip: (0.08), ipnet: 70.36.128.0/19(0.04), asn: 46375(-0.52), country: US(-0.05)] X-Mailman-Approved-At: Thu, 24 Oct 2019 23:31:30 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 22:27:55 -0000 > From: "Bjoern A. Zeeb" > To: "FreeBSD Current" > Subject: fsync: giving up on dirty, umount -f fails > Date: Thu, 24 Oct 2019 07:58:39 +0000 > > Hi, > > I am archiving some old disks and while trying to umount [-f] them I am > getting errors and I basically cannot get rid of the mount anymore > without rebooting. This is on a HEAD from mid-end-August (around > r351518M). > > Given there is a lot of work going on at the moment to deal with > “disks dropping out by error” and not to panic I was just wondering > if this is something to address as well? Somehow umount -f should be > able to succeed (in the future)? > > > fsync: giving up on dirty (error = 5) > g_vfs_done():da0s2g[READ(offset=4666441728, length=16384)]error = 5 > 0xfffff803533b81e0: tag devfs, type VCHR > usecount 1, writecount 0, refcount 1661 rdev 0xfffff8015372a800 > flags (VI_ACTIVE) > v_object 0xfffff80365537c00 ref 0 pages 8340 cleanbuf 1561 dirtybuf 97 > lock type devfs: EXCL by thread 0xfffff80006a57000 (pid 26526, > umount, tid 100091) > dev da0s2g > > /bz In the above example the unmount is failing because it is getting back EIO for one of its dirty buffers. Thus it is not able to get everything written out, so refuses to do the unmount. What we are working on doing is implementing a `very forcible' unmount (which I would love to specify using `umount -F', but regretably -F is already in use to specify an alternate fstab file). A very forcible unmount says to simply abandon dirty buffers that it cannot write. In the event of a disk dying, that would be all of the dirty buffers. Kirk McKusick