Date: Thu, 29 Mar 2001 21:58:11 -0800 From: Kirk McKusick <mckusick@mckusick.com> To: Bakul Shah <bakul@bitblocks.com> Cc: arch@freebsd.org Subject: Re: Background Fsck Message-ID: <200103300558.VAA09201@beastie.mckusick.com> In-Reply-To: Your message of "Thu, 29 Mar 2001 16:53:55 PST." <200103300053.TAA27553@thunderer.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
To: Kirk McKusick <mckusick@mckusick.com> cc: arch@freebsd.org Subject: Re: Background Fsck In-Reply-To: Your message of "Wed, 28 Mar 2001 21:22:10 PST." <200103290522.VAA06966@beastie.mckusick.com> Date: Thu, 29 Mar 2001 16:53:55 -0800 From: Bakul Shah <bakul@bitblocks.com> Dumb question time. Why would I want to run a background fsck on an active filesystem? One wouldn't mount an unsafe filesystem in the first place. Background fsck can only be run on filesystems that are using soft updates. It is safe to mount a soft updates filesystem after a crash because the only inconsistencies will be lost block and inodes. So, in a sense you are mouting a dirty filesystem, albeit one on which it is safe to operate. Perhaps you are talking about background garbage collection on an active fs -- blocks and 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)? I agree that background fsck is doing garbage collection, but then one can argue that traditional fsck is doing garbage collection too. It might have been reasonable to call the original program fsgc, but it was called fsck. The background fsck is doing exactly the same set of fixes that the traditional fsck does. The only difference is that it has to do system calls to update the bitmaps rather than writing them directly. So, changing the name seems unnecessarily confusing to me. 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). Many improvements have been made to fsck over the years. Through there are undoubtedly more that could be made, there are no big easy improvements left. Kirk 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?200103300558.VAA09201>