Date: Fri, 28 Mar 2003 15:52:50 -0800 From: David Schultz <das@FreeBSD.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: Alexander Langer <alex@big.endian.de> Subject: Re: [Re: several background fsck panics Message-ID: <20030328235250.GA22044@HAL9000.homeunix.com> In-Reply-To: <3E810547.3653FFEA@mindspring.com> References: <20030324215712.GA844@fump.kawo2.rwth-aachen.de> <3E7FE3CE.ECD2775F@mindspring.com> <20030325110843.GF1700@fump.kawo2.rwth-aachen.de> <3E804392.40844D63@mindspring.com> <20030325161632.GB600@lenny.anarcat.ath.cx> <3E810547.3653FFEA@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Terry Lambert <tlambert2@mindspring.com>: > o Put a counter in the first superblock; it would be > incremented when the BG fsck is started, and reset > to zero when it completes. If the counter reaches > 3 (or some command line specified number), then the > BG flagging is ignored, and a full FG fsck is then > performed instead. I like this idea because it will > always work, and it's not actually a hack, it's a > correct solution. I'm glad you like it because AFAIK, it is already implemented. ;-) > o Implement "soft read-only". The place that most of > the complaints are coming from is desktop users, with > relatively quiescent machines. Though swap is used, > it does not occur in an FS partition. As a result, > the FS could be marked "read-only" for long period of > time. This marking would be in memory. The clean bit > would be set on the superblock. When a write occurs, > the clean bit would be reset to "dirty", and committed > to disk prior to the write operation being permitted > to proceed (a stall barrier). I like this idea because, > for the most part, it eliminates fsck, both BG and FG, > on systems that crash while it's in effect. The net > result is a system that is statistically much more > tolerant of failures, but which still requires another > safety net, such as the previous solution. I was thinking of doing something like this myself as part of an ``idle timeout'' for disks. (Marking the filesystem clean after a period of quiescence would actually interfere with ATA disks' built-in mechanism for spinning down after a timeout, which is important for laptops, so the OS would have to track the true amount of idle time.) Annoyingly, I can never get the disk containing /var to remain quiescent for long while cron is running (even without any crontabs), and I hope this can be solved without disabling cron or adding a nontrivial hack to bio.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030328235250.GA22044>