Date: Thu, 22 Oct 1998 22:40:39 -0700 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: <199810230540.WAA19582@flamingo.McKusick.COM> In-Reply-To: Your message of "Thu, 22 Oct 1998 23:16:49 PDT." <199810230616.XAA19968@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> Date: Thu, 22 Oct 1998 23:16:49 -0700 In-Reply-To: Julian Elischer <julian@whistle.com> "Soft-Updates aware fsck available." (Oct 20, 8:22pm) To: Julian Elischer <julian@whistle.com>, current@FreeBSD.ORG, mckusick@McKusick.COM Subject: Re: Soft-Updates aware fsck available. On Oct 20, 8:22pm, Julian Elischer wrote: } Subject: Soft-Updates aware fsck available. } Kirk has supplied a 'soft-updates aware' fsck. } It requires a small tweek to compile under FreeBSD } but that's all. } } I've made the shar file available at: } http://www.freebsd.org/~julian/ } (at the bottom of the page). I now think that inoinfo(orphan)->ino_state = DFOUND; propagate(); needs to happen in pass3() even if linkup() fails (because lost+found filled or whatever), otherwise we risk tossing away files because their parent directory could not be reconnected. This gives the administrator the option of cleaning out lost+found and rerunning fsck to reconnect more stuff, and comes closer to the behavior of the current version of fsck in the tree. I agree (in both cases). I also worry that /* * If we are running with soft updates and we come * across unreferenced directories, we just leave * them in DSTATE which will cause them to be pitched * in pass 4. */ if (preen && resolved && usedsoftdep && state == DSTATE) { if (inp->i_dotdot >= ROOTINO) inoinfo(inp->i_dotdot)->ino_linkcnt++; continue; } might be too agressive. What happens if we lose a directory close to the root due to an bad block? I'd only toss the directory if it is empty, which appears to be the usual cruft left behind by a crash when softupdates is in use. 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? Kirk McKusick 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?199810230540.WAA19582>