Re: [Re: several background fsck panics

Thus spake Terry Lambert <tlambert2_at_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.