From owner-freebsd-fs@freebsd.org Mon Apr 2 22:23:41 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 853A2F533C2 for ; Mon, 2 Apr 2018 22:23:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F17DE75CE5 for ; Mon, 2 Apr 2018 22:23:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 0D3E6123F3 for ; Mon, 2 Apr 2018 22:23:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w32MNdQf009826 for ; Mon, 2 Apr 2018 22:23:39 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w32MNdd9009825 for freebsd-fs@FreeBSD.org; Mon, 2 Apr 2018 22:23:39 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 227204] Combination of gmirror and enabled softupdates journalling cause slow filesystem degradation Date: Mon, 02 Apr 2018 22:23:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mckusick@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Works As Intended X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 22:23:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227204 Kirk McKusick changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed CC| |mckusick@FreeBSD.org Resolution|--- |Works As Intended --- Comment #1 from Kirk McKusick --- This is a problem that is endemic to all overwriting filesystems that use journalling. Specifically, the journal only checks and corrects things that= it knows need to be fixed. Under normal circumstances it knows about everything that might be wrong. Unfortunately most disks are run with `write cache enabled' which means that they can lie about completing writes to stable st= ore. Specifically they report that a write is on the platter (or in the flash) w= hen in fact it is only in the disk's volatile cache. If there is a power-fail event, they are usually able to flush their cache, but not always. Since the journal has been told that the write completed, it does not check for the missed write and the corresponding corruption of the filesystem remains unt= il a full fsck is run (which checks all of the metadata integrity). If the missed write was an update to a cylinder-group map, then you can end up double-allocating a block (such as you see in your example). When an attemp= t is made to free a double-allocated block you will get a system panic with "fre= eing free block". Some systems have tried periodically forcing a full fsck (on the order of e= very month or so) to catch these types of errors, but the disruption if the rebo= ot happened during a busy period led them to drop this practice. Still it is a good idea to periodically run a full fsck just to ensure that your filesyst= ems stay healthy. If this is not practical you should consider using ZFS which provides a great deal more redundancy and integrity though requires considerably more resources (disk + CPU + memory) for a given storage load = than does UFS. I am closing this report with "Works as Intended" as that is the closest to "This is a known shortcoming of journalled overwriting filesystems". --=20 You are receiving this mail because: You are the assignee for the bug.=