Date: Thu, 22 Oct 1998 22:49:53 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Don Lewis <Don.Lewis@tsc.tdk.com>, Warner Losh <imp@village.org> Cc: hackers@FreeBSD.ORG Subject: Re: softupdates and/or fsck bugs or features? Message-ID: <199810230549.WAA19888@salsa.gv.tsc.tdk.com> In-Reply-To: Don Lewis <Don.Lewis@tsc.tdk.com> "Re: softupdates and/or fsck bugs or features?" (Oct 22, 4:01am)
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 22, 4:01am, Don Lewis wrote:
} Subject: Re: softupdates and/or fsck bugs or features?
} } I think what
} } was happening was that the link count was adjusted for files that were
} } dangling because fsck couldn't attach them to lost+found because the
} } directory was full.
}
} That might explain the link count on lost+found,
And indeed it does. In pass3() there is the following code:
(void)linkup(orphan, inp->i_dotdot);
inp->i_parent = inp->i_dotdot = lfdir;
lncntp[lfdir]--;
So even if linkup() fails because lost+found is full, lncntp[lfdir]-- still
happens. During the phase where the link counts are adjusted, they are
decreased by lncntp[inumber], which will be a large negative number in
your case, causing the link count in lost+found to be set to a large number.
My patch in bin/8055 doesn't have this problem, but now I think it might
have other problems if lost+found overflows.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810230549.WAA19888>