From owner-freebsd-current@freebsd.org Sat Jun 22 00:18:02 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 81A1D15C4A7C for ; Sat, 22 Jun 2019 00:18:02 +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 19E5788943; Sat, 22 Jun 2019 00:18:02 +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 234B2B412; Sat, 22 Jun 2019 00:18:01 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Date: Fri, 21 Jun 2019 17:17:58 -0700 (PDT) From: Don Lewis Subject: Re: Reducing UFS corruption from unclean shutdowns? To: Scott Long cc: Warner Losh , "Conrad E. Meyer" , Alan Somers , FreeBSD Current In-Reply-To: <17B3F210-5101-449F-AE06-326F890C3C01@samsco.org> Message-ID: References: <17B3F210-5101-449F-AE06-326F890C3C01@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=iso-2022-jp Content-Disposition: INLINE X-Rspamd-Queue-Id: 19E5788943 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.93 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_SHORT(-0.93)[-0.930,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; 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: Sat, 22 Jun 2019 00:18:02 -0000 On 21 Jun, Scott Long wrote: > > >> On Jun 21, 2019, at 4:37 PM, Warner Losh wrote: >> >> On Fri, Jun 21, 2019, 3:33 PM Conrad Meyer wrote: >> >>> On Fri, Jun 21, 2019 at 2:55 PM Alan Somers wrote: >>>> I would've thought that immediately following a sync(8), the >>>> filesystem would be consistent. Why do I still see errors after a >>>> panic in files that were written before I sync()ed? >>>> -Alan >>> >>> Hi Alan, >>> >>> Contra the name, sync(2) (sync(8)) isn't synchronous. It invokes >>> VFS_SYNC() with MNT_NOWAIT across all mountpoints. >>> >> >> Yes. Sync(2) just starts the I/O, but it may be delayed if there is a lot >> of dirty buffers. The other issue is that new buffers may be dirtied… >> > > Still, the point of SU and SU+J is that the filesystem should not be > damaged and require active repair on reboot, whether or not a > sync or fsync was done. There’s certainly issues with disk lying > about out of order writes, POSIX sematics of unlinked files, and the > inherent design of UFS superblock updates, but the problems that > Alan reported should still be looked at, they’re not expected and > they undermine the usefulness of SU+J. Other that the inode hash error, the other issues should not prevent safely mounting the filesystem read-write. SU without J is able to fix these problems with a background fsck while the filesystem is mounted and in use. SU+J should be able to fix all of these except for the inode hash error by replaying the journal, but that is done by fsck. At least it can avoid the need to scan the entire filesystem. The problem of the disk lying about write completions should only be a problem if the power fails, or if we do something during the panic and recovery that tells the disk to toss its write cache. The main problem here is the inode hash error. That shouldn't be happening.