From owner-freebsd-current@freebsd.org Fri Jun 21 21:49:11 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 BA04A15C08CF for ; Fri, 21 Jun 2019 21:49:11 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F3C5829F5; Fri, 21 Jun 2019 21:49:11 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (unknown [76.212.85.177]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: truckman) by smtp.freebsd.org (Postfix) with ESMTPSA id 18855A267; Fri, 21 Jun 2019 21:49:09 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Date: Fri, 21 Jun 2019 14:49:07 -0700 (PDT) From: Don Lewis Subject: Re: Reducing UFS corruption from unclean shutdowns? To: Scott Long cc: Alan Somers , Chuck Silvers , Kirk McKusick , FreeBSD CURRENT In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-7 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Disposition: INLINE X-Rspamd-Queue-Id: 5F3C5829F5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; NEURAL_HAM_SHORT(-0.97)[-0.972,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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:49:12 -0000 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 expecte= d. I > don=A2t think that the blks missing message is expected, and the unref fi= le message is > definitely a red flag of something that should have been handed with jour= nal > recovery. Kirk and Chuck, do you have any insight here? 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. 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.