Re: [Issue 3596] 'hotcopy' of packed fsfs repos may corrupt target revprops.db

Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:

> Philip Martin wrote on Tue, 13 Apr 2010 at 13:08 +0100:
>> Summary: FSFS hotcopy doesn't handle SQLite databases properly, this
>> affects the new revprop packing db and the 1.6 rep sharing db.
>
> revprops.db consists of a single table; perhaps we could take advantage of
> this to duplicate it "by hand", until the sqlite API has stabilized?
>
> (IOW, perhaps the hotcopy logic could be tailored to revprops.db, without
> having logic generic enough to be able to duplicate any live sqlite DB)

You mean use SQL statements: SELECT from the source table, iterate
over the rows doing INSERT INTO the destination table. That's
probably less efficient than a plain copy but should be reliable.

The alternative appears to be some sort of callback from the FS layer
to the repo layer to run part of the hotcopy while holding the
exclusive repository lock. That's nasty and makes using SQL
statements look attractive.

>> > The rep sharing cache is just a cache, and can be truncated or
>> > deleted without impact on the correctness of the system.
>>
>
> To delete the DB, ones needs to know that it's corrupted. Are we even
> sure that, if corruption occurs, it will be detected?

No idea.

>> That's a way to fix a corrupt hotcopy but I don't think it prevents
>> the corruption.

-- 
Philip