From owner-freebsd-current Wed Jan 22 11:32:16 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 5B98237B401 for ; Wed, 22 Jan 2003 11:32:15 -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 A36CE43F13 for ; Wed, 22 Jan 2003 11:32:14 -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 h0MJWC0L012581; Wed, 22 Jan 2003 11:32:12 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id h0MJWC3o012580; Wed, 22 Jan 2003 11:32:12 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Wed, 22 Jan 2003 11:32:12 -0800 From: David Schultz To: Garrett Wollman Cc: Jan Srzednicki , current@FreeBSD.ORG Subject: Re: background fsck did not create lost+found Message-ID: <20030122193212.GA12401@HAL9000.homeunix.com> Mail-Followup-To: Garrett Wollman , Jan Srzednicki , current@FreeBSD.ORG References: <20030120183442.GA2778@HAL9000.homeunix.com> <200301221813.h0MIDUTF040121@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301221813.h0MIDUTF040121@khavrinen.lcs.mit.edu> 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 Garrett Wollman : > < said: > > > Would that be a big problem to allow some fsck option not to erase all > > these softupdates-pending inodes, but to put them in lost+found as usual? > > It certainly couldn't be done with the background fsck, because > background fsck works on a snapshot and not the running filesystem; > thus, it cannot make any allocations -- it can only deallocate things. Actually, that should work just fine. When background fsck notices an unreferenced inode in the snapshot, it could create a file in the underlying filesystem. The easy way to do this is to copy the data with the standard open(2)/write(2)/close(2) interfaces. After the copy, the original data blocks are deallocated as usual. A more efficient implementation might require a special kernel interface that creates a directory entry, given an inode number and path. Unfortunately, I think it is possible that the unreferenced inode has not been initialized, even though it is allocated in the inode bitmap, so you could potentially get random junk. Such a feature sounds reasonable, although I'm not sure how useful it would really be. If you have software that introduces a race window where you can lose data because it does updates incorrectly, hacking the operating system to make the race window slightly smaller is not the best solution. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message