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 // <ab...@webgiro.com> 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
