From owner-cvs-all@FreeBSD.ORG Sun Feb 20 23:17:15 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7253B16A4CE; Sun, 20 Feb 2005 23:17:15 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0AA743D5D; Sun, 20 Feb 2005 23:17:14 +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 j1KNHB1W008258; Sun, 20 Feb 2005 18:17:11 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j1KNHBRG008257; Sun, 20 Feb 2005 18:17:11 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Sun, 20 Feb 2005 18:17:11 -0500 From: David Schultz To: Xin LI Message-ID: <20050220231711.GA8172@VARK.MIT.EDU> Mail-Followup-To: Xin LI , src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG References: <200502200802.j1K82G2M003470@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502200802.j1K82G2M003470@repoman.freebsd.org> cc: cvs-src@FreeBSD.ORG cc: src-committers@FreeBSD.ORG cc: 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-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2005 23:17:15 -0000 On Sun, Feb 20, 2005, Xin LI wrote: > delphij 2005-02-20 08:02:16 UTC > > FreeBSD src repository > > Modified files: > sbin/fsck_ffs fsck.h pass5.c > sys/ufs/ffs ffs_alloc.c ffs_softdep.c fs.h > Log: > The recomputation of file system summary at mount time can be a > very slow process, especially for large file systems that is just > recovered from a crash. > > 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?) I don't mean to suggest that this is a bad idea; to the contrary, I think it's a great idea. But unless I'm missing something, it has larger adverse effects than claimed in the commit message. FWIW, I run bgfsck on my development box once a month from a cron job, rather than after every crash. As long as there's free space and no bugs in the filesystem or I/O system (okay, a big assumption), this doesn't hurt anything and saves me lots of time.