From owner-freebsd-current@freebsd.org Fri Jun 21 21:51:51 2019 Return-Path: Delivered-To: freebsd-current@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 189F515C0BEA for ; Fri, 21 Jun 2019 21:51:51 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 3CB3882D63; Fri, 21 Jun 2019 21:51:50 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 64CC921785; Fri, 21 Jun 2019 17:51:49 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Fri, 21 Jun 2019 17:51:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsco.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=1 iKPoZ8y4oYaIwm+TB7+G55Bg9RoZwODxH0i57o4PNw=; b=kpANczBP1Z2Cgp71Y qp8qAghHkSiANZ5KphTgEuC9zifrnE5QF5na12YF8akki7ZTeXspZZldXkKqcArR 1IWi383AjbIAr6TwwC8AYJqzrvZFAcYdD47ZJ+c+MzNa9y3A3UVHlqscmSbuJsCC 3cfdAZt+qiK8+qg0bMfNwNkHseh6QYiw7YfcWDjiSTpy3FQw4y9BxrVWvKBrBF+G 6XHmwHzEU8pDVgmJ5slgrwz2deh3QbSwczP96earqcy/UfwW7TdBO+ad4ztWLxrW hVl4Q3QYeuaQojCxLzOYmnTBv/9/MqIQ73KinoOjGzk8IvDbpwW3Scq1uz81M2P9 Q6QGg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=1iKPoZ8y4oYaIwm+TB7+G55Bg9RoZwODxH0i57o4P Nw=; b=EgeAMhDIsuwtiCM+Oj1c1Lnvyx++zdp1utFv83hPWbPBTuuAU7vbHU7VG W8UUscWKUYSfKW9a0Z00u9mbKrpC9IFKUpHseYtV4oBXNdk5M1hq6MR7bj7L2loA 8FiIh1q6EoQRRFevCLwkTUZfxfrb9oFBl3Ixqsh5A+6m7SCw4o5nU/4nUxl9OJs/ 5/PZnzRTnUw3WDJWPcfMs+LlrATAAxrm5pFE2uwZkLYoz5VWMB5o4cZEiTR18Kwg Ic+U42mxutwpfjI03Flg1/c02OrqaCnDjpVPz1/9bdabNBSUGOXiKXZVUBHt84Qm hdQZwvLoSOD22DtR2uEC9Y0koJaLQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrtdejgddtvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpefutghothht ucfnohhnghcuoehstghothhtlhesshgrmhhstghordhorhhgqeenucfkphepudelvddrhe ehrdehgedrheelnecurfgrrhgrmhepmhgrihhlfhhrohhmpehstghothhtlhesshgrmhhs tghordhorhhgnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [10.178.24.13] (unknown [192.55.54.59]) by mail.messagingengine.com (Postfix) with ESMTPA id 4992B380075; Fri, 21 Jun 2019 17:51:48 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Reducing UFS corruption from unclean shutdowns? From: Scott Long In-Reply-To: Date: Fri, 21 Jun 2019 15:51:46 -0600 Cc: Alan Somers , Chuck Silvers , Kirk McKusick , FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Don Lewis X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 3CB3882D63 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=samsco.org header.s=fm3 header.b=kpANczBP; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=EgeAMhDI; spf=pass (mx1.freebsd.org: domain of scottl@samsco.org designates 66.111.4.28 as permitted sender) smtp.mailfrom=scottl@samsco.org X-Spamd-Result: default: False [-5.63 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[samsco.org:s=fm3,messagingengine.com:s=fm3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.28]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[samsco.org]; RCPT_COUNT_FIVE(0.00)[5]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: in2-smtp.messagingengine.com]; DKIM_TRACE(0.00)[samsco.org:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; IP_SCORE(-3.53)[ip: (-9.79), ipnet: 66.111.4.0/24(-4.74), asn: 11403(-3.07), country: US(-0.06)]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[28.4.111.66.list.dnswl.org : 127.0.5.1] 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: Fri, 21 Jun 2019 21:51:51 -0000 > On Jun 21, 2019, at 3:49 PM, Don Lewis wrote: >=20 > On 21 Jun, Scott Long wrote: >>=20 >>> On Jun 21, 2019, at 2:09 PM, Alan Somers = wrote: >>>=20 >>> On Fri, Jun 21, 2019 at 1:56 PM Scott Long = wrote: >>>>=20 >>>>=20 >>>>=20 >>>>> On Jun 21, 2019, at 1:49 PM, Alan Somers = wrote: >>>>>=20 >>>>> I panic my development VM regularly. Each time, I need to fsck = the >>>>> file system. Even if I had run sync(8) just before the panic, I >>>>> frequently find corruption. What should I change to make sync(8) >>>>> work, or at least to make corruption rare? It looks like my root = file >>>>> system is using soft-updates+journal. Should I disable those? >>>>>=20 >>>>=20 >>>> What corruption do you regularly see? >>>>=20 >>>> Scott >>>=20 >>> fsck reports various types of errors, all repairable, like "INODE >>> CHECK-HASH FAILED", "FREE BLK COUNT(S) WRONG IN SUPERBLK", "SUMMARY >>> INFORMATION BAD", "BLK(S) MISSING IN BIT MAPS", and "UNREF FILE". = If >>> I don't run fsck, then I get errors when I try to access files. = Like >>> "inode XXX: check-hash failed" and "such and such is marked as an >>> executable file but could not be run by the operating system". >>> -Alan >>=20 >> The freeblk count and summary information messages are normal and = expected. I >> don=E2=80=99t think that the blks missing message is expected, and = the unref file message is >> definitely a red flag of something that should have been handed with = journal >> recovery. Kirk and Chuck, do you have any insight here? >=20 > Blks missing is to be expected. The free block bitmap isn't updated > until after the pointers to them in the inode are cleared. Likewise = the > unref file warning is also to be expected because the reference to the > inode in the parent directory is cleared before the inode is cleared. > These aren't a fatal problem, just a resource leak until fsck is run. >=20 > I would not expect the inode check-hash error. I would expect the = hash > update to happen at the same time as any other bits of the inode are > changed, but this is a new feature that went in after I last looked at > the code. >=20 I thought that unref=E2=80=99d files were also supposed to be cleaned up = on journal recovery, different from plain SU recovery/preening. It=E2=80=99s been so long, = maybe I don=E2=80=99t remember correctly anymore. Scott