On 20/05/2009, at 11:18 AM, Antony Blakey wrote:
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).
And if you required each header to include the write offset of the
previous header, then the probability of misidentification becomes
vanishingly small as the number of headers increases, because you can
check the chain.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
A reasonable man adapts himself to suit his environment. An
unreasonable man persists in attempting to adapt his environment to
suit himself. Therefore, all progress depends on the unreasonable man.
-- George Bernard Shaw
