Re: Any FSFS rep-sharing experts out there?

On Mon, Oct 5, 2009 at 12:52 PM, Branko Cibej <brane_at_xbc.nu> wrote:

> But anyway the question is irrelevant. If we manage to lock up the
> server for tens of seconds because of a slightly larger-than-usual
> commit, we need to fix it. This is pretty much on my plate right now,
> but I'll ask around for help on understanding FSFS details.

Have you made any progress on this? It would seem worthwhile to get
this fix into 1.6.6 if possible.

I do not want to sidetrack you, but I did have a couple questions (for anyone).

1) Why do we need to open this database when reading the repository?
Such as for a checkout? My understanding is that the only time the
cache is needed is when we are writing to the database. We want to
see if there is an existing representation for the same hash. So why
should we care if this database is locked when someone is doing a
checkout?

2) I assume we are holding the database open while the transaction is
being committed for atomicity, but do we really need it here?
Couldn't we just write the new rows to the table after the commit
succeeds? If the rows are not written it just means that a future new
rep would the same cache would not share it. In the grand scheme of
things, that seems minor compared to the current behavior.

If we solved #1, it would seem like #2 would not be an issue.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2404941