Date: Fri, 30 Mar 2001 09:53:06 -0800 From: Bakul Shah <bakul@bitblocks.com> To: Kirk McKusick <mckusick@mckusick.com> Cc: arch@freebsd.org Subject: Re: Background Fsck Message-ID: <200103301753.MAA03709@valiant.cnchost.com> In-Reply-To: Your message of "Thu, 29 Mar 2001 21:58:11 PST." <200103300558.VAA09201@beastie.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. Okay, this makes sense (modulo the questions Terry Lambert has raised). See below. > 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. I am used to distinguish between the `structure repair of the FS' task from any garbage collection task of the traditional fsck. In fact the structural consistency of reachable nodes, dirs + files must be a precondition before you can do GC. Seems to me, the two tasks can be separated in two programs. Then perhaps even on a non soft-update system you can run the repair part in fg and the garbage collection part in bg. Of course, a soft-update enabled fs won't need the repair part. Anyway that is what I was thinking when I suggested a name change but the name issue by itself is not important to me; sorry I brought it up. But like Terry I worry about disks write errors or blocks going bad. And not knowing how well the bg fsck (or for that matter soft-updates) copes with that gives me an uneasy feeling. Perhaps bg fsck should not do anything if it discovers structural inconsistency? I know I don't have to run it if I feel this way but the point is to understand the behavior. > 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. I was less than clear; what I was asking is if anyone has looked at whether the fsck *algorithm* is optimal. I wondered about its complexity -- is it O(n^2) or O(n log n) or something else and whether it is the best possible algorithm. Thanks for your response (and others, especially Jordan as snaphots was one critical piece I had completely missed)! -- bakul 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?200103301753.MAA03709>