Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 03 Jul 2005 01:25:38 -0000
From:      David Schultz <das@FreeBSD.ORG>
To:        Xin LI <delphij@delphij.net>
Cc:        cvs-src@FreeBSD.ORG, src-committers@FreeBSD.ORG, Xin LI <delphij@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:  <20050221060844.GA700@VARK.MIT.EDU>
In-Reply-To: <1108955636.624.16.camel@spirit>
References:  <200502200802.j1K82G2M003470@repoman.freebsd.org> <20050220231711.GA8172@VARK.MIT.EDU> <1108955636.624.16.camel@spirit>

next in thread | previous in thread | raw e-mail | index | archive | help
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.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050221060844.GA700>