Date: Mon, 21 Feb 2005 11:13:56 +0800 From: Xin LI <delphij@delphij.net> To: David Schultz <das@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: <1108955636.624.16.camel@spirit> In-Reply-To: <20050220231711.GA8172@VARK.MIT.EDU> References: <200502200802.j1K82G2M003470@repoman.freebsd.org> <20050220231711.GA8172@VARK.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 在 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? > 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. Cheers, -- Xin LI <delphij delphij net> http://www.delphij.net/ [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCGVH0/cVsHxFZiIoRAn3zAJ9WGdY5W0Kk1unD5aH7Q+INiryYsACdFFMW TjLoNKnQ0BBFVRIuTSa1fFk= =v6zX -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1108955636.624.16.camel>