From owner-freebsd-current Mon Jan 20 10:34:50 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1A5537B401 for ; Mon, 20 Jan 2003 10:34:48 -0800 (PST) Received: from HAL9000.homeunix.com (12-233-57-224.client.attbi.com [12.233.57.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AC0643F1E for ; Mon, 20 Jan 2003 10:34:47 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id h0KIYh0L003074; Mon, 20 Jan 2003 10:34:43 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id h0KIYhXq003073; Mon, 20 Jan 2003 10:34:43 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Mon, 20 Jan 2003 10:34:43 -0800 From: David Schultz To: Jan Srzednicki Cc: current@FreeBSD.ORG Subject: Re: background fsck did not create lost+found Message-ID: <20030120183442.GA2778@HAL9000.homeunix.com> Mail-Followup-To: Jan Srzednicki , current@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Jan Srzednicki : > 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