Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Mar 2001 20:11:56 -0800
From:      Alfred Perlstein <bright@wintelcom.net>
To:        "Michael C . Wu" <keichii@peorth.iteration.net>
Cc:        Bakul Shah <bakul@bitblocks.com>, Kirk McKusick <mckusick@mckusick.com>, arch@FreeBSD.ORG
Subject:   Re: Background Fsck
Message-ID:  <20010329201156.P9431@fw.wintelcom.net>
In-Reply-To: <20010329220128.B21838@peorth.iteration.net>; from keichii@iteration.net on Thu, Mar 29, 2001 at 10:01:28PM -0600
References:  <200103290522.VAA06966@beastie.mckusick.com> <200103300053.TAA27553@thunderer.cnchost.com> <20010329220128.B21838@peorth.iteration.net>

next in thread | previous in thread | raw e-mail | index | archive | help
* Michael C . Wu <keichii@iteration.net> [010329 20:01] wrote:
> I think Kirk would know a thing or two about FFS. ;-)
> 
> On Thu, Mar 29, 2001 at 04:53:55PM -0800, Bakul Shah scribbled:
> | Dumb question time.  Why would I want to run a background
> | fsck on an active filesystem? One wouldn't mount an unsafe
> 
> You want your system to be up as soon as possible.
> Have you ever tried to fsck even just a 200gb system?
> 
> | filesystem in the first place.  Perhaps you are talking about
> | background garbage collection on an active fs -- blocks and
> 
> No, he calls it background fsck because that is what it is.
> 
> | inodes not reachable from the root set of objects (root inode
> | + freelist + superblock?) recovered lazily.  If this is
> | really what you have, wouldn't it make sense to call it
> | something else (e.g. fsgc)?
> 
> Please at least try to understand what this feature is and does.
> 
> | On a somewhat related note, I have always wondered if the
> | current fsck algorithm can be significantly improved or if it
> | is about as efficient as it can be (barring any peephole code
> | improvements).
> 
> This is a significant architecture addition/redesign to 
> reduce fsck time.

er, actually Bakul Shah is correct in his questions, you're the
one who doesn't seem to understand. :)

It is basically a garbage collection that's possible because the
disk is "frozen" in the snapshot.

As far as speeding up fsck in general, I haven't heard anything,
suggestions are welcome. :)

And as far as 'fsgc', that might be a good thing to call it,
basically put code into 'fsck' so that when argv[0] = "fscg"
it does the snapshotting and gc sweep.

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010329201156.P9431>