Re: Removing softdep

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Jun 09, 2008 at 02:11:36PM -0400, Greg A. Woods; Planix, Inc. wrote:
>> As I already mentioned once, regular ffs doesn't maintain referential
>> integrity. Block pointers are written synchronously; the data they
>> point to isn't. After a crash, those block pointers point to whatever
>> random trash was already on the disk. This results in silent file
>> corruption, and also sometimes disclosure of sensitive information.
>
> That's true of all the older Unix filesystems too, isn't it?

I'm not sure, but I suspect so. The pre-ffs filesystem certainly
didn't have all that much to recommend it, nor did much of anything
else from that era.

> The bigger your buffer cache, the more data you lose in a crash, but the 
> filesystem metadata integrity is preserved thus making filesystem recovery 
> possible without a full restore.  You only have to restore the data you 
> lost from the buffer cache.  You do have to identify the affected files 
> though of course.  If I remember correctly that's the only commitment to 
> integrity that any Unix(tm) filesystem has ever mde.

Veritas? Of course, that was third-party...

> Now if I understand correctly the current FFS journalling code we're 
> discussing is only journalling the metadata.

That is my understanding also.

> So, does this journalling option make it easier/possible to identify the 
> files affected by lost buffer cache?  I.e. is it fully transaction based 
> such that a journal entry is written first when the block pointers are 
> updated and then another journal entry is written after all of the 
> associated data blocks are finally committed?  If so, do the existing 
> recovery and repair tools already find and somehow mark all the corrupted 
> files reliably?

If you're going to go that far you can also just invalidate or roll
back the bogus block pointers so that in most cases there won't be any
corruption at all. Which is certainly possible, but as I understand
things the wapbl code does not currently do this.

-- 
David A. Holland
dholland%netbsd.org@localhost