Date: Sat, 11 May 2002 02:26:11 -0500 From: Dan Nelson <dnelson@allantgroup.com> To: Edwin Groothuis <edwin@mavetju.org> Cc: freebsd-questions@FreeBSD.ORG Subject: Re: blackout - fsck - cleared files Message-ID: <20020511072611.GM13627@dan.emsphone.com> In-Reply-To: <20020511155044.A748@k7.mavetju.org> References: <20020511104229.A750@k7.mavetju.org> <20020511023511.GL13627@dan.emsphone.com> <20020511155044.A748@k7.mavetju.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (May 11), Edwin Groothuis said: > On Fri, May 10, 2002 at 09:35:11PM -0500, Dan Nelson wrote: > > In the last episode (May 11), Edwin Groothuis said: > > > Last night it was suddenly very dark in the neighbourhood here. > > > Luckely the electricity came back within the hour, but still, my > > > computer didn't like me anymore. It boots without problem, but > > > fsck gave me a lot of lines like: > > > > > > <118> I=1119059 OWNER=edwin MODE=100600 > > > <118>/dev/ad0s1f: SIZE=443 MTIME=May 10 23:44 2002 (CLEARED) > > > <118>/dev/ad0s1f: > > > <118>UNREF FILE > > > > > > The cleared message, does it mean the directory entrance for this > > > file is cleared or that some dirty-flag is cleared? > > > > The UNREF FILE message means there is a valid inode but there are > > no directory entries pointing to it. If you're running softupdates > > you > > So euh... shouldn't these allocated pieces then be stored in > lost+found for possible recovery, or isn't that needed because fsck > does know they're already somewhere else also in a real file? If you have softupdates enabled, it takes care to commit to disk all directory operations in a specific order that guarantees that any unreferenced inodes can be removed. You should actually never need lost+found with softupdates. -- Dan Nelson dnelson@allantgroup.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020511072611.GM13627>