Date: Wed, 22 Jan 2003 11:32:12 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Garrett Wollman <wollman@lcs.mit.edu> Cc: Jan Srzednicki <winfried@student.agh.edu.pl>, current@FreeBSD.ORG Subject: Re: background fsck did not create lost+found Message-ID: <20030122193212.GA12401@HAL9000.homeunix.com> In-Reply-To: <200301221813.h0MIDUTF040121@khavrinen.lcs.mit.edu> References: <20030120183442.GA2778@HAL9000.homeunix.com> <Pine.GSO.4.44.0301221112210.22474-100000@student.uci.agh.edu.pl> <200301221813.h0MIDUTF040121@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Garrett Wollman <wollman@lcs.mit.edu>: > <<On Wed, 22 Jan 2003 11:14:47 +0100 (CET), Jan Srzednicki <winfried@student.agh.edu.pl> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030122193212.GA12401>