Date: Mon, 20 Jan 2003 10:34:43 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Jan Srzednicki <winfried@student.agh.edu.pl> Cc: current@FreeBSD.ORG Subject: Re: background fsck did not create lost+found Message-ID: <20030120183442.GA2778@HAL9000.homeunix.com> In-Reply-To: <Pine.GSO.4.44.0301201630350.22474-100000@student.uci.agh.edu.pl> References: <Pine.GSO.4.44.0301201630350.22474-100000@student.uci.agh.edu.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Jan Srzednicki <winfried@student.agh.edu.pl>: > This massive disk mangling occured on /usr, but still, one file in /home > got lost - which happened to be quite important file. Background fsck > logged: > > Jan 20 16:06:30 stronghold root: /dev/ad1s1d: UNREF FILE I=1723065 > OWNER=winfried MODE=100644 > Jan 20 16:06:30 stronghold root: /dev/ad1s1d: SIZE=23397 MTIME=Jan 20 > 15:57 2003 (CLEARED) > Jan 20 16:06:30 stronghold root: /dev/ad1s1d: Reclaimed: 0 directories, 8 > files, 16439 fragments > Jan 20 16:06:30 stronghold root: /dev/ad1s1d: 33802 files, 13109700 used, > 6310697 free (11577 frags, 787390 blocks, 0.1% fragmentation) > > First two entries clearly correspond to the missing file, which should > have been put in /home/lost+found. But, the poroblem is that no lost+found > directory was created, while it should (as fsck_ffs(8) says). I guess its > a bug, probably in the background fsck code. Still, is there any way to > reclaim the file now, besides running strings(1) on the whole partition? Consider what happens when you remove a large directory tree. Thousands of directory entries may be removed, but in the softupdates case, the inodes will stick around a bit longer. The same also applies to files that have been intentionally unlinked but are still open. To avoid a syndrome where all these thousands of files end up in lost+found after a crash or power failure, fsck just removes them on softupdates-enabled filesystems. Unfortunately, this means that a newly-created file that has an inode but no directory entry will also be cleared. In some sense, this race is equivalent to the situation where something went wrong before the inode could be written. However, when you are saving a new version of an important file, you need to be careful that the new version (and its directory entry) hits the disk before the old one goes away. I know that vi saves files in a safe way, whereas ee and emacs do not. (Emacs introduces only a small race, though.) Also, mv will DTRT only if the source and destination files live on the same filesystem. 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?20030120183442.GA2778>