couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <>
Subject Re: Tail Append Headers
Date Wed, 20 May 2009 01:48:01 GMT

On 20/05/2009, at 12:50 AM, Damien Katz wrote:

> Also, if performance generally turns out to be all around slower,  
> we'll have to discuss if the pure tail append change is actually  
> worth it. Maybe we can tail append headers with the old design too,  
> but they are only ever used when the front header is bad. The only  
> problem is, without implementing the current design, I don't know of  
> a workable way to find an valid header vs something that happens to  
> look like a couchdb file header, such as a couchdb file attached  
> inside a document in a live db, or an intentional attack.

Maybe you could do this by ensuring that:

a) headers are only on a certain boundary, even a small boundary such  
as 128 bytes, but other writes ignore alignment; and
b) headers include a private (unexposed) UUID of the database (stored  
in an immutable file prefix); and
c) headers include the write offset; and
d) headers include magic (although maybe the private UUID is enough).

e.g <magic><private UUID><write offset>

Point a reduces the search space - maybe that's not necessary given  
it's a serious failure if you have to use it; and
Points b and c make an intentional attack virtually impossible.
Points a and c makes the recursive embedding issue incredible unlikely.

It's certainly a probabilistic approach, but at some point the  
probability of collision because much less than the probability of  
disk corruption.

Antony Blakey
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

The truth does not change according to our ability to stomach it.
   -- Flannery O'Connor

View raw message