On Mon, Oct 12, 2009 at 19:28, Branko Čibej <brane_at_xbc.nu> wrote:
> David Glasser wrote:
>> For what it's worth, the current schema for the rep-sharing DB is
>> completely incompatible with "remove data from server" obliterate
>
> You mean in the sense that you can't reasonably in real-time remove
> entries from the datbase, right? I can imagine having separate, offline
> process that would scan the whole repository for a particular
> representation hash and do the actual on-disk data removal and rep-cache
> cleanup. But it would require a write lock on the repository.
Isn't there some notion of the "total size" of the repository?
Couldn't you record that value, scan that amount of the repository,
then repeat if the repository grew during the scan. When it appears
stable, take a write lock and examine the size again; if changed,
release the lock and go back to scanning the incremental data. If the
size is the same, then perform the obliterate surgery.
That would place all the scanning outside of the write lock.
I'm not sure what parts of the repository are mutable and would need
further consideration, but it's probably doable.
Also note that *another* obliterate could be wiping out stuff while
the scanning is taking place. But I believe there will be some
obliterate "counter" or somesuch, and if that changes during the
scanning process, then I believe you just restart the process from
scratch. And keep restarting until that counter is unchanged after the
write lock is acquired.
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2406867
Received on 2009-10-13 23:14:35 CEST