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
