Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 03 Jul 2005 01:26:15 -0000
From:      David Schultz <das@FreeBSD.ORG>
To:        Xin LI <delphij@FreeBSD.ORG>
Cc:        cvs-src@FreeBSD.ORG, src-committers@FreeBSD.ORG, 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>