Date: Fri, 27 Feb 2004 15:09:52 +0300 From: Yar Tikhiy <yar@freebsd.org> To: Brian Fundakowski Feldman <green@freebsd.org> Cc: mckusick@freebsd.org Subject: Re: SoftUpdates/fsck considered harmful Message-ID: <20040227120951.GC20684@comp.chem.msu.su> In-Reply-To: <200402212132.i1LLWa7P057630@green.homeunix.org> References: <200402212132.i1LLWa7P057630@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Feb 21, 2004 at 04:32:36PM -0500, Brian Fundakowski Feldman wrote: > I lost some data which was important to me (thankfully, not lost completely, > as a fgrep on the hard disk was able to find a copy) because of a crash > while SoftUpdates had some data not yet flushed. I simply had done this: > > 1. vi file > 2. *edit edit edit, :wq* > 3. ci file > 4. co -l file > > That should have left me with several copies of it, but when the system > panicked, upon reboot fsck told me: > > Feb 19 21:34:46 green fsck: /dev/ad0s2e: UNREF FILE I=448021 OWNER=green MODE=100644 > Feb 19 21:34:46 green fsck: /dev/ad0s2e: SIZE=6298 MTIME=Feb 19 20:38 2004 (CLEARED) > > I'm certain this was the file I was editing. SoftUpdates only guarantees > the disk is in a valid state, not that I won't lost files, but if fsck > hadn't decided that "UNREF" meant "the user did not intend this file to > exist any longer", I would have had a copy of it in /home/lost+found! Can > there please be a less harmful behavior than simply not restoring unlinked > files just because they appear to be "UNREF"? I'm afraid you demand from the filesystem logic what it isn't supposed to provide. In the case you described, having a remote repository on a stable machine would be the solution. On the one hand, using Softupdates indeed leads to probably "losing" recently created files upon a system crash (which may be compensated for by deleted files reappearing :-) On the other hand, without Softupdates one would have a close chance to end up with files that existed but had inconsistent contents because of the crash preventing some buffered data from being committed to stable storage. Personally, I see no point in trying to choose the lesser of the two evils when an orthogonal path can be followed. And Softupdates has the advantage of keeping at least the filesystem metadata in a consistent state. Now let's return to the fsck topic. AFAIK "UNREF" means that the reference count of an inode has dropped to zero because all links from directories are gone, but the inode hasn't actually been freed due to a system crash or malfunction. This is different from the case of a lost inode, which has a non-zero reference count but no actual references from directories. Therefore fsck will clear UNREF'ed inodes, but reconnect lost ones to lost+found. Please correct me if I'm wrong. -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040227120951.GC20684>