Thus spake Garrett Wollman <[EMAIL PROTECTED]>: > <<On Wed, 22 Jan 2003 11:14:47 +0100 (CET), Jan Srzednicki ><[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
