Date: Mon, 26 Oct 1998 15:09:37 -0800 From: Kirk McKusick <mckusick@McKusick.COM> To: Don Lewis <Don.Lewis@tsc.tdk.com> Cc: Julian Elischer <julian@whistle.com>, current@FreeBSD.ORG Subject: Re: Soft-Updates aware fsck available. Message-ID: <199810262309.PAA27194@flamingo.McKusick.COM> In-Reply-To: Your message of "Fri, 23 Oct 1998 00:03:34 PDT." <199810230703.AAA20052@salsa.gv.tsc.tdk.com>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Don Lewis <Don.Lewis@tsc.tdk.com> Message-Id: <199810230703.AAA20052@salsa.gv.tsc.tdk.com> Date: Fri, 23 Oct 1998 00:03:34 -0700 In-Reply-To: Kirk McKusick <mckusick@McKusick.COM> "Re: Soft-Updates aware fsck available." (Oct 22, 10:40pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Kirk McKusick <mckusick@McKusick.COM>, Don Lewis <Don.Lewis@tsc.tdk.com> Subject: Re: Soft-Updates aware fsck available. Cc: Julian Elischer <julian@whistle.com>, current@FreeBSD.ORG On Oct 22, 10:40pm, Kirk McKusick wrote: } Subject: Re: Soft-Updates aware fsck available. } If there were a bad block, then `resolved' would not be true } and we would not take this action. I added the resolved variable, } so if we find something fishy in the first or second pass, we } will back off on the aggressive tossing in later passes. If you } remove a large file tree, then some of the subdirectories may not } be completely cleaned out yet, but you still want to nuke them. } So using empty as a criterion is likely to put a bunch of } undesirable stuff in lost+found. Does this seem reasonable? Ok, I feel somewhat better about this now, though autonuking has always bothered me. My big concern is that resolved might be cleared later on, and by then it would be too late ... By the time that we have gotten to the auto-nuking stage, we have had to read all the inodes, indirect blocks, and directory contents. If any of those reads fails, then we will not auto-nuke. In short, everything of importance that might be read has already been found, plus we have not found any unexpected inconsistencies. I could imagine a senario that passed these tests and still had serious errors, but they are pretty unlikely and almost certainly would be serious enough that you would still be stuck with restoring your disk from tape. Something that occurred to me in another thread where I was thinking that unreferenced empty directories should be cleared (the more conservative approach), is that unless you cleared the directories in the correct order, you could end up with links (usually "..") pointing to unallocated inodes if fsck were interrupted while it was cleaning. This would be bad because a subsequent fsck run could stumble over these dangling links and require manual intervention. The case of ".." referring to an unallocated inode is treated specially in fsck. Specifically, it is viewed as the top of an orphaned tree, so is stuck in lost+found with the comment "previous parent was XX" where XX is the inode value for "..". So, here, unlike any other name that references an unallocated inode, the ordering of removals does not matter. ~Kirk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810262309.PAA27194>