tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Removing softdep

On 9-Jun-08, at 12:35 PM, David Holland 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?

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.

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

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?

                                        Greg A. Woods; Planix, Inc.

Home | Main Index | Thread Index | Old Index