From owner-freebsd-current Thu Oct 22 23:33:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA29121 for freebsd-current-outgoing; Thu, 22 Oct 1998 23:33:00 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from knecht.Sendmail.ORG (knecht.sendmail.org [209.31.233.160]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA29116 for ; Thu, 22 Oct 1998 23:32:58 -0700 (PDT) (envelope-from mckusick@flamingo.McKusick.COM) Received: from flamingo.McKusick.COM (root@flamingo.mckusick.com [209.31.233.178]) by knecht.Sendmail.ORG (8.9.1/8.9.1) with ESMTP id XAA02924; Thu, 22 Oct 1998 23:32:29 -0700 (PDT) Received: from flamingo.McKusick.COM (mckusick@localhost [127.0.0.1]) by flamingo.McKusick.COM (8.8.5/8.8.5) with ESMTP id WAA19582; Thu, 22 Oct 1998 22:40:40 -0700 (PDT) Message-Id: <199810230540.WAA19582@flamingo.McKusick.COM> To: Don Lewis Subject: Re: Soft-Updates aware fsck available. cc: Julian Elischer , current@FreeBSD.ORG In-reply-to: Your message of "Thu, 22 Oct 1998 23:16:49 PDT." <199810230616.XAA19968@salsa.gv.tsc.tdk.com> Date: Thu, 22 Oct 1998 22:40:39 -0700 From: Kirk McKusick Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From: Don Lewis Date: Thu, 22 Oct 1998 23:16:49 -0700 In-Reply-To: Julian Elischer "Soft-Updates aware fsck available." (Oct 20, 8:22pm) To: Julian Elischer , 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