On Mon, Oct 12, 2009 at 5:59 PM, Greg Stein <gstein_at_gmail.com> wrote:
> 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.
Yes, something like that should work. "youngest rev" would be a
reasonable "total size" here.
For simplicity perhaps just have a separate obliterate write lock and
not allow concurrent obliterates.
--dave
--
glasser_at_davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2407183
Received on 2009-10-13 23:47:58 CEST