You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by cm...@collab.net on 2002/05/08 21:39:31 UTC
dupkeys leading to wasted records.
I happened to notice while debugging Philip's latest bug report that
our strings table appears to be wasting a BDB row for every string
added to the table. That is, now that we have the whole duplicate key
thing going on, the strings table look like this:
--
VERSION=3
format=print
type=btree
duplicates=1
keys=1
HEADER=END
0
0
((trunk 3 3.1) (tags 3 2.1) (branches 3 1.1))
1
1
((trunk 3 3.2) (tags 3 2.1) (branches 3 1.1))
10
10
Tue Feb 16 10:49:07 PST 1999\0a\0a
(...)
DATA=END
--
Note that the first of all the duplicate keys points to an empty row.
I've verified that this has nothing to do with any recent changes to
the filesystem code, and presume it began immediately after enabling
the duplicate key system.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: dupkeys leading to wasted records.
Posted by cm...@collab.net.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Greg Stein <gs...@lyra.org> writes:
> > I'm going to guess this is somehow related to svn_fs__string_clear(). When I
> > switched to the dup keys, I saw some strange calls to that which I couldn't
> > quite discern their purpose. The code does a delete, then inserts a blank
> > record. I'm going to guess that something does a clear, then a set, which
> > ends up with a blank from the clear, then a set which produces the second
> > record.
> >
> > I'd suggest to examine our uses of clear() to see what they're really trying
> > to do.
>
> I can't remember what they're for either, but sounds like a good place
> to start looking...
It appears that all the uses of svn_fs__string_clear() (there are
three) exist when doing one of the following two things:
1. replacing a directory entries list after mods.
2. replacing a node property list after mods.
However, this isn't exactly the root of the problem. As I see it, the
real problem is an assumption throughout the filesystem that you can't
have a `representation' pointing to a non-existent `string'. So, for
example, when we make a new file, we call svn_fs__string_append() with
empty data just to generate a new string key where future contents for
that file will live. Of course, in the old system, that was fine,
because we would just overwrite this empty string with real contents
for the file. In the new system though, this is another example of
a great way to have a wasted DB row.
My suggested solution is two-fold:
1. replace the three calls to svn_fs__rep_contents_clear() with a new
function: svn_fs__rep_contents_delete() (I've coded this locally,
and it takes care of many of the "wasted record" cases).
2. expose the get_and_bump_key() function inside of strings-table.c
(as something like "svn_fs__string_reserve_key()") and allow brand
new reps to simply claim a new string key but without actually
writing anything there.
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: dupkeys leading to wasted records.
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> I'm going to guess this is somehow related to svn_fs__string_clear(). When I
> switched to the dup keys, I saw some strange calls to that which I couldn't
> quite discern their purpose. The code does a delete, then inserts a blank
> record. I'm going to guess that something does a clear, then a set, which
> ends up with a blank from the clear, then a set which produces the second
> record.
>
> I'd suggest to examine our uses of clear() to see what they're really trying
> to do.
I can't remember what they're for either, but sounds like a good place
to start looking...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: dupkeys leading to wasted records.
Posted by Greg Stein <gs...@lyra.org>.
I'm going to guess this is somehow related to svn_fs__string_clear(). When I
switched to the dup keys, I saw some strange calls to that which I couldn't
quite discern their purpose. The code does a delete, then inserts a blank
record. I'm going to guess that something does a clear, then a set, which
ends up with a blank from the clear, then a set which produces the second
record.
I'd suggest to examine our uses of clear() to see what they're really trying
to do.
Cheers,
-g
On Wed, May 08, 2002 at 04:39:31PM -0500, cmpilato@collab.net wrote:
> I happened to notice while debugging Philip's latest bug report that
> our strings table appears to be wasting a BDB row for every string
> added to the table. That is, now that we have the whole duplicate key
> thing going on, the strings table look like this:
>
> --
> VERSION=3
> format=print
> type=btree
> duplicates=1
> keys=1
> HEADER=END
> 0
>
> 0
> ((trunk 3 3.1) (tags 3 2.1) (branches 3 1.1))
> 1
>
> 1
> ((trunk 3 3.2) (tags 3 2.1) (branches 3 1.1))
> 10
>
> 10
> Tue Feb 16 10:49:07 PST 1999\0a\0a
>
> (...)
>
> DATA=END
> --
>
> Note that the first of all the duplicate keys points to an empty row.
> I've verified that this has nothing to do with any recent changes to
> the filesystem code, and presume it began immediately after enabling
> the duplicate key system.
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org