Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 Oct 1998 00:03:34 -0700
From:      Don Lewis <Don.Lewis@tsc.tdk.com>
To:        Kirk McKusick <mckusick@McKusick.COM>, 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:  <199810230703.AAA20052@salsa.gv.tsc.tdk.com>
In-Reply-To: Kirk McKusick <mckusick@McKusick.COM> "Re: Soft-Updates aware fsck available." (Oct 22, 10:40pm)

next in thread | previous in thread | raw e-mail | index | archive | help
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 ...

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.

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?199810230703.AAA20052>