From owner-cvs-src@FreeBSD.ORG Sun Jul 3 01:26:57 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.ORG Delivered-To: cvs-src@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B352316AFF1; Sun, 3 Jul 2005 01:01:23 +0000 (GMT) (envelope-from ps@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D85F4521D; Sun, 3 Jul 2005 00:50:07 +0000 (GMT) (envelope-from ps@mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id A47E46EA5A; Sat, 2 Jul 2005 17:40:34 -0700 (PDT) X-Original-To: ps@mu.org Delivered-To: ps@mu.org Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by elvis.mu.org (Postfix) with ESMTP id BC2005C9B2 for ; Sun, 20 Feb 2005 22:09:20 -0800 (PST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id A54B656A2C for ; Mon, 21 Feb 2005 06:09:19 +0000 (GMT) (envelope-from owner-src-committers@FreeBSD.org) Received: by hub.freebsd.org (Postfix) id C4CD616A53E; Mon, 21 Feb 2005 06:09:14 +0000 (GMT) Delivered-To: ps@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 538) id 7B06F16A4D0; Mon, 21 Feb 2005 06:09:12 +0000 (GMT) Delivered-To: src-committers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E36416A4CE; Mon, 21 Feb 2005 06:09:11 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C50243D1F; Mon, 21 Feb 2005 06:09:10 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j1L68ivl000720; Mon, 21 Feb 2005 01:08:44 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j1L68iSN000719; Mon, 21 Feb 2005 01:08:44 -0500 (EST) (envelope-from das@FreeBSD.ORG) From: David Schultz To: Xin LI Message-ID: <20050221060844.GA700@VARK.MIT.EDU> Mail-Followup-To: Xin LI , Xin LI , src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG References: <200502200802.j1K82G2M003470@repoman.freebsd.org> <20050220231711.GA8172@VARK.MIT.EDU> <1108955636.624.16.camel@spirit> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii:iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1108955636.624.16.camel@spirit> Sender: owner-src-committers@FreeBSD.org Precedence: bulk X-Loop: FreeBSD.ORG X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on elvis.mu.org X-Spam-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_00,BODY_8BITS, MIME_CHARSET_FARAWAY,SARE_SUB_GAPPY_3 autolearn=no version=3.0.2 X-Spam-Level: Cc: cvs-src@FreeBSD.ORG, src-committers@FreeBSD.ORG, Xin LI , cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sbin/fsck_ffs fsck.h pass5.c src/sys/ufs/ffs ffs_alloc.c ffs_softdep.c fs.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 03 Jul 2005 01:26:57 -0000 X-Original-Date: Mon, 21 Feb 2005 01:08:44 -0500 X-List-Received-Date: Sun, 03 Jul 2005 01:26:57 -0000 On Mon, Feb 21, 2005, Xin LI wrote: > 在 2005-02-20日的 18:17 -0500，David Schultz写道： > > > Since the summary is already re-sync'ed every 30 second, we will > > > not lag behind too much after a crash. With this consideration > > > in mind, it is more reasonable to transfer the responsibility to > > > background fsck, to reduce the delay after a crash. > > > > I'm not sure that I completely buy this explanation. If an > > application has a 1 GB temporary file open and unlinked at the > > time of the crash, then upon reboot, this change will make it seem > > as though I have 1 GB less space than I really do. This could > > lead to spurious disk full errors. (Or will that happen anyway if > > bgfsck hasn't recomputed all the free block bitmaps yet?) > > Hmm... Maybe we should add some constraint on this, for example, for > volumes that fssize < 20G do the recomputation at mount time, despite > the vfs.ffs.compute_summary_at_mount setting? I think the situation > only happens when bgfsck have not finished the scan yet, and on smaller > volumes, this should not affect so much (after all, we can always set > vfs.ffs.compute_summary_at_mount = 1 to restore the old behavior). > > Should I send a HEADSUP / update UPDATING so more people will know the > change? No, I don't think any major warnings or notices are needed. For about two years, IIRC, the SoftUpdates implementation would report spurious disk full errors when the disk was close to full, a large file was deleted, and another large file was immediately created, but practically nobody noticed at the time. I think practically nobody will notice your change either, except that they'll be glad that the time required to boot after a crash has dropped dramatically. ;-) A note in the fsck manpage couldn't hurt, though.