On Tue, 24 Aug 1999, Matthew Dillon wrote:
> :I know it's not the answer, it's just related question: do you know
> :perhaps of any initiatives (except XFS) that could significantly shorten
> :time it takes fsck to check big filesystems, let's say 64GB? As it is now,
> :it's almost unbearable. I naively thought softupdates would (almost)
> :eliminate the need to do fsck...
> :
> :Andrzej Bialecki
>
> Eventually Kirk is planning for softupdates to allow you to run a special
> version of fsck in the background to clean up the block bitmap on a live
> filesystem. The time frame for this project is not known.
>
> Another possibility would be to mark individual cylinders clean/dirty
> to reduce the amount of work fsck must do on a normal filesystem. It
> would be a pretty hefty project for someone to take on, though.
Hmm.. If I understand you correctly:
* the ffs code would have to be modified to mark cylinder groups "dirty"
when there are writes to that CG.
* on unmount, after the buffers are flushed they would be marked
clean.
* on mount all "clean" flags in CGs would have to be ckecked (instead of
the single bit)
* fsck would have to be modified to recognize CG "clean" flag and prune
only those CGs.
Overall, doesn't sound _that_ complicated... but most probably I'm missing
something.
Andrzej Bialecki
// <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com)
// -------------------------------------------------------------------
// ------ FreeBSD: The Power to Serve. http://www.freebsd.org --------
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ----
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
