Thus spake Terry Lambert <[EMAIL PROTECTED]>:
> 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.
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to