Date: Sun, 20 Feb 2005 18:17:11 -0500 From: David Schultz <das@FreeBSD.ORG> To: Xin LI <delphij@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 Message-ID: <20050220231711.GA8172@VARK.MIT.EDU> In-Reply-To: <200502200802.j1K82G2M003470@repoman.freebsd.org> References: <200502200802.j1K82G2M003470@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050220231711.GA8172>