You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2008/10/25 22:10:43 UTC
Comparison testing: { FSFS, BDB } x { 1.5.4, trunk }
I did a little bit of simple comparison testing between FSFS and BDB in
1.5.4 and trunk. My testing involved loading a dumpfile of 5000 revisions
(taken from our own repository), then doing some single-revision dumps at a
few time-slices across the loaded repository.
Here are the highlights (percentages are ballpark estimates).
In trunk, FSFS:
is significantly slower (30%) for writes operations. I have no idea why.
is a bit faster for reads (20%).
showed no meaningful disk usage changes. But I'm pretty sure this is
an artifact of the testing dataset, which isn't as up-to-date-branch-heavy
as more recent revision ranges in our source tree are.
In trunk, Berkeley DB:
is significantly faster (50%) for write operations. This is almost
certainly because post-commit deltification is doing a single
deltification instead of touching a chain of files.
is significantly slower (300%) for read operations. Distance to
nearest fulltext?
showed significant improvement in disk usage (20% savings) in trunk.
For the same reasons that FSFS didn't show much improvement here, I
must assume rep-sharing wasn't the real win here. More likely the
minimization of fulltexts (one per line of history) is the win here.
In all things except disk usage (now in trunk), FSFS remains a clear winner
over BDB in this testing.
Attached are the script I used and a spreadsheet with the actual findings.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Comparison testing: { FSFS, BDB } x { 1.5.4, trunk }
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
David Glasser wrote:
> On Sat, Oct 25, 2008 at 11:45 PM, David Glasser
> <gl...@davidglasser.net> wrote:
>> On Sat, Oct 25, 2008 at 3:10 PM, C. Michael Pilato <cm...@collab.net> wrote:
>>> I did a little bit of simple comparison testing between FSFS and BDB in
>>> 1.5.4 and trunk. My testing involved loading a dumpfile of 5000 revisions
>>> (taken from our own repository), then doing some single-revision dumps at a
>>> few time-slices across the loaded repository.
>>>
>>> Here are the highlights (percentages are ballpark estimates).
>>>
>>> In trunk, FSFS:
>>>
>>> is significantly slower (30%) for writes operations. I have no idea why.
>> As discussed in the other thread, the obvious thing to assume would be
>> that all the reads and rights of the rep cache DB are slowing you
>> down... try disabling that (just take out all the calls into
>> rep-cache.h from fs-fs.c) and try again?
>
> Have you had a chance to try this? I can give you the appropriate
> patch if you'd like.
I had a chance to try this earlier today, but don't have the numbers handy right
now. I only did FSFS experiments, but the basic gist was that trunk without
rep-sharing was faster, but not quite as fast as 1.5.x.
I'm working on a patch which allows rep-sharing to be configurable, via
fsfs.conf. This should make playing with these results a bit easier.
-Hyrum
Re: Comparison testing: { FSFS, BDB } x { 1.5.4, trunk }
Posted by David Glasser <gl...@davidglasser.net>.
On Sat, Oct 25, 2008 at 11:45 PM, David Glasser
<gl...@davidglasser.net> wrote:
> On Sat, Oct 25, 2008 at 3:10 PM, C. Michael Pilato <cm...@collab.net> wrote:
>> I did a little bit of simple comparison testing between FSFS and BDB in
>> 1.5.4 and trunk. My testing involved loading a dumpfile of 5000 revisions
>> (taken from our own repository), then doing some single-revision dumps at a
>> few time-slices across the loaded repository.
>>
>> Here are the highlights (percentages are ballpark estimates).
>>
>> In trunk, FSFS:
>>
>> is significantly slower (30%) for writes operations. I have no idea why.
>
> As discussed in the other thread, the obvious thing to assume would be
> that all the reads and rights of the rep cache DB are slowing you
> down... try disabling that (just take out all the calls into
> rep-cache.h from fs-fs.c) and try again?
Have you had a chance to try this? I can give you the appropriate
patch if you'd like.
--dave
>> is a bit faster for reads (20%).
>>
>> showed no meaningful disk usage changes. But I'm pretty sure this is
>> an artifact of the testing dataset, which isn't as up-to-date-branch-heavy
>> as more recent revision ranges in our source tree are.
>>
>> In trunk, Berkeley DB:
>>
>> is significantly faster (50%) for write operations. This is almost
>> certainly because post-commit deltification is doing a single
>> deltification instead of touching a chain of files.
>>
>> is significantly slower (300%) for read operations. Distance to
>> nearest fulltext?
>>
>> showed significant improvement in disk usage (20% savings) in trunk.
>> For the same reasons that FSFS didn't show much improvement here, I
>> must assume rep-sharing wasn't the real win here. More likely the
>> minimization of fulltexts (one per line of history) is the win here.
>>
>> In all things except disk usage (now in trunk), FSFS remains a clear winner
>> over BDB in this testing.
>>
>> Attached are the script I used and a spreadsheet with the actual findings.
>>
>> --
>> C. Michael Pilato <cm...@collab.net>
>> CollabNet <> www.collab.net <> Distributed Development On Demand
>>
>> #!/bin/sh
>>
>> for svnadmin in \
>> /home/cmpilato/projects/subversion/subversion/svnadmin/svnadmin \
>> /home/cmpilato/projects/subversion-1.5.x/subversion/svnadmin/svnadmin ; do
>> for fstype in fsfs bdb; do
>> echo "### ${svnadmin} ${fstype}"
>> for i in 1 2 3; do
>> rm -rf repos
>> ${svnadmin} create --fs-type ${fstype} repos
>> echo "--- Dumpfile load"
>> time -p ${svnadmin} load -q repos < dumpfile
>> done
>> echo "### --- Repository size"
>> du -sk repos
>> for rev in 10 2500 5000; do
>> for i in 1 2 3; do
>> echo "--- Revision dump (r${rev})"
>> time -p ${svnadmin} dump -q repos -r ${rev} > /dev/null
>> done
>> done
>> done
>> done
>>
>>
>
>
>
> --
> David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
>
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Comparison testing: { FSFS, BDB } x { 1.5.4, trunk }
Posted by David Glasser <gl...@davidglasser.net>.
On Sat, Oct 25, 2008 at 3:10 PM, C. Michael Pilato <cm...@collab.net> wrote:
> I did a little bit of simple comparison testing between FSFS and BDB in
> 1.5.4 and trunk. My testing involved loading a dumpfile of 5000 revisions
> (taken from our own repository), then doing some single-revision dumps at a
> few time-slices across the loaded repository.
>
> Here are the highlights (percentages are ballpark estimates).
>
> In trunk, FSFS:
>
> is significantly slower (30%) for writes operations. I have no idea why.
As discussed in the other thread, the obvious thing to assume would be
that all the reads and rights of the rep cache DB are slowing you
down... try disabling that (just take out all the calls into
rep-cache.h from fs-fs.c) and try again?
--dave
> is a bit faster for reads (20%).
>
> showed no meaningful disk usage changes. But I'm pretty sure this is
> an artifact of the testing dataset, which isn't as up-to-date-branch-heavy
> as more recent revision ranges in our source tree are.
>
> In trunk, Berkeley DB:
>
> is significantly faster (50%) for write operations. This is almost
> certainly because post-commit deltification is doing a single
> deltification instead of touching a chain of files.
>
> is significantly slower (300%) for read operations. Distance to
> nearest fulltext?
>
> showed significant improvement in disk usage (20% savings) in trunk.
> For the same reasons that FSFS didn't show much improvement here, I
> must assume rep-sharing wasn't the real win here. More likely the
> minimization of fulltexts (one per line of history) is the win here.
>
> In all things except disk usage (now in trunk), FSFS remains a clear winner
> over BDB in this testing.
>
> Attached are the script I used and a spreadsheet with the actual findings.
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
> #!/bin/sh
>
> for svnadmin in \
> /home/cmpilato/projects/subversion/subversion/svnadmin/svnadmin \
> /home/cmpilato/projects/subversion-1.5.x/subversion/svnadmin/svnadmin ; do
> for fstype in fsfs bdb; do
> echo "### ${svnadmin} ${fstype}"
> for i in 1 2 3; do
> rm -rf repos
> ${svnadmin} create --fs-type ${fstype} repos
> echo "--- Dumpfile load"
> time -p ${svnadmin} load -q repos < dumpfile
> done
> echo "### --- Repository size"
> du -sk repos
> for rev in 10 2500 5000; do
> for i in 1 2 3; do
> echo "--- Revision dump (r${rev})"
> time -p ${svnadmin} dump -q repos -r ${rev} > /dev/null
> done
> done
> done
> done
>
>
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Comparison testing: { FSFS, BDB } x { 1.5.4, trunk }
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
C. Michael Pilato wrote:
> David Glasser wrote:
>> So I'm confused. The editor still only talks in md5s, right? Does
>> that mean that our current "migrate stuff from md5 to sha1" strategy
>> is (as long as the editor is unrevved) means that we're dropping most
>> md5s in updates/commits?
>
> I don't think it's that clean cut, but yes, there is a disconnect in the
> system of integrity-checks if we do this route. That's why for BDB my
> strategy is "calculate and store both MD5 and SHA1 from now on", and return
> (without needed for recalculation at this point, since everything wants MD5)
> what was asked for.
Following such a strategy for FSFS shouldn't be difficult, nor would it entail
any serious space repercussions.
(Finding the time to do it, on the other hand...)
-Hyrum
Re: Comparison testing: { FSFS, BDB } x { 1.5.4, trunk }
Posted by "C. Michael Pilato" <cm...@collab.net>.
David Glasser wrote:
> So I'm confused. The editor still only talks in md5s, right? Does
> that mean that our current "migrate stuff from md5 to sha1" strategy
> is (as long as the editor is unrevved) means that we're dropping most
> md5s in updates/commits?
I don't think it's that clean cut, but yes, there is a disconnect in the
system of integrity-checks if we do this route. That's why for BDB my
strategy is "calculate and store both MD5 and SHA1 from now on", and return
(without needed for recalculation at this point, since everything wants MD5)
what was asked for.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Comparison testing: { FSFS, BDB } x { 1.5.4, trunk }
Posted by David Glasser <gl...@davidglasser.net>.
On Thu, Oct 30, 2008 at 6:59 PM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> C. Michael Pilato wrote:
>> Hyrum K. Wright wrote:
>>> C. Michael Pilato wrote:
>>>> C. Michael Pilato wrote:
>>>>> I did a little bit of simple comparison testing between FSFS and BDB in
>>>>> 1.5.4 and trunk. My testing involved loading a dumpfile of 5000 revisions
>>>>> (taken from our own repository), then doing some single-revision dumps at a
>>>>> few time-slices across the loaded repository.
>>>>>
>>>>> Here are the highlights (percentages are ballpark estimates).
>>>>>
>>>>> In trunk, FSFS:
>>>>>
>>>>> is significantly slower (30%) for writes operations. I have no idea why.
>>>>>
>>>>> is a bit faster for reads (20%).
>>>>>
>>>>> showed no meaningful disk usage changes. But I'm pretty sure this is
>>>>> an artifact of the testing dataset, which isn't as up-to-date-branch-heavy
>>>>> as more recent revision ranges in our source tree are.
>>>>>
>>>>> In trunk, Berkeley DB:
>>>>>
>>>>> is significantly faster (50%) for write operations. This is almost
>>>>> certainly because post-commit deltification is doing a single
>>>>> deltification instead of touching a chain of files.
>>>>>
>>>>> is significantly slower (300%) for read operations. Distance to
>>>>> nearest fulltext?
>>>>>
>>>>> showed significant improvement in disk usage (20% savings) in trunk.
>>>>> For the same reasons that FSFS didn't show much improvement here, I
>>>>> must assume rep-sharing wasn't the real win here. More likely the
>>>>> minimization of fulltexts (one per line of history) is the win here.
>>>>>
>>>>> In all things except disk usage (now in trunk), FSFS remains a clear winner
>>>>> over BDB in this testing.
>>>>>
>>>>> Attached are the script I used and a spreadsheet with the actual findings.
>>>> I've got an uncommitted patch which causes Berkeley DB to store *both* MD5
>>>> and SHA1 checksums, and to be able to cough up the one required by callers.
>>>> I re-ran the numbers with this patch, and have attached an updated
>>>> spreadsheet. What I find is that the space and performance cost for
>>>> calculating and storing both checksums is minimal (atop what the trunk code
>>>> was already doing). But the read costs dropped by half! I suspect this is
>>>> because svn_fs_file_md5_checksum() forces a walk over the file contents if
>>>> the MD5 checksum isn't readily available in the database, which is the case
>>>> in the current trunk code.
>>> Where do we still use svn_fs_file_md5_checksum() explicitly? I thought most of
>>> those calls had been switched to svn_fs_file_checksum(), which can have the same
>>> behavior you describe, but isn't forced to.
>>
>> Turns out the calls I was thinking of *are* using svn_fs_file_checksum().
>> But they also pass TRUE for force. (These are in libsvn_repos/dump.c.) Six
>> of one, a half-dozen of the other...
>
> That's what I figured. I *think* that's the only place we force a checksum
> calculation, and that's because we want the md5 to be there for older clients if
> somebody's doing a dump-load from 1.6 to pre-1.6. Otherwise, we could just put
> whatever checksum we had, sha1 or md5, and then let the loader put the same kind
> of checksum in the target repo. That would also save a few of our "ignore this
> checksum 'cause it ain't the right kind" conditionals.
So I'm confused. The editor still only talks in md5s, right? Does
that mean that our current "migrate stuff from md5 to sha1" strategy
is (as long as the editor is unrevved) means that we're dropping most
md5s in updates/commits?
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Comparison testing: { FSFS, BDB } x { 1.5.4, trunk }
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
C. Michael Pilato wrote:
> Hyrum K. Wright wrote:
>> C. Michael Pilato wrote:
>>> C. Michael Pilato wrote:
>>>> I did a little bit of simple comparison testing between FSFS and BDB in
>>>> 1.5.4 and trunk. My testing involved loading a dumpfile of 5000 revisions
>>>> (taken from our own repository), then doing some single-revision dumps at a
>>>> few time-slices across the loaded repository.
>>>>
>>>> Here are the highlights (percentages are ballpark estimates).
>>>>
>>>> In trunk, FSFS:
>>>>
>>>> is significantly slower (30%) for writes operations. I have no idea why.
>>>>
>>>> is a bit faster for reads (20%).
>>>>
>>>> showed no meaningful disk usage changes. But I'm pretty sure this is
>>>> an artifact of the testing dataset, which isn't as up-to-date-branch-heavy
>>>> as more recent revision ranges in our source tree are.
>>>>
>>>> In trunk, Berkeley DB:
>>>>
>>>> is significantly faster (50%) for write operations. This is almost
>>>> certainly because post-commit deltification is doing a single
>>>> deltification instead of touching a chain of files.
>>>>
>>>> is significantly slower (300%) for read operations. Distance to
>>>> nearest fulltext?
>>>>
>>>> showed significant improvement in disk usage (20% savings) in trunk.
>>>> For the same reasons that FSFS didn't show much improvement here, I
>>>> must assume rep-sharing wasn't the real win here. More likely the
>>>> minimization of fulltexts (one per line of history) is the win here.
>>>>
>>>> In all things except disk usage (now in trunk), FSFS remains a clear winner
>>>> over BDB in this testing.
>>>>
>>>> Attached are the script I used and a spreadsheet with the actual findings.
>>> I've got an uncommitted patch which causes Berkeley DB to store *both* MD5
>>> and SHA1 checksums, and to be able to cough up the one required by callers.
>>> I re-ran the numbers with this patch, and have attached an updated
>>> spreadsheet. What I find is that the space and performance cost for
>>> calculating and storing both checksums is minimal (atop what the trunk code
>>> was already doing). But the read costs dropped by half! I suspect this is
>>> because svn_fs_file_md5_checksum() forces a walk over the file contents if
>>> the MD5 checksum isn't readily available in the database, which is the case
>>> in the current trunk code.
>> Where do we still use svn_fs_file_md5_checksum() explicitly? I thought most of
>> those calls had been switched to svn_fs_file_checksum(), which can have the same
>> behavior you describe, but isn't forced to.
>
> Turns out the calls I was thinking of *are* using svn_fs_file_checksum().
> But they also pass TRUE for force. (These are in libsvn_repos/dump.c.) Six
> of one, a half-dozen of the other...
That's what I figured. I *think* that's the only place we force a checksum
calculation, and that's because we want the md5 to be there for older clients if
somebody's doing a dump-load from 1.6 to pre-1.6. Otherwise, we could just put
whatever checksum we had, sha1 or md5, and then let the loader put the same kind
of checksum in the target repo. That would also save a few of our "ignore this
checksum 'cause it ain't the right kind" conditionals.
-Hyrum
Re: Comparison testing: { FSFS, BDB } x { 1.5.4, trunk }
Posted by "C. Michael Pilato" <cm...@collab.net>.
Hyrum K. Wright wrote:
> C. Michael Pilato wrote:
>> C. Michael Pilato wrote:
>>> I did a little bit of simple comparison testing between FSFS and BDB in
>>> 1.5.4 and trunk. My testing involved loading a dumpfile of 5000 revisions
>>> (taken from our own repository), then doing some single-revision dumps at a
>>> few time-slices across the loaded repository.
>>>
>>> Here are the highlights (percentages are ballpark estimates).
>>>
>>> In trunk, FSFS:
>>>
>>> is significantly slower (30%) for writes operations. I have no idea why.
>>>
>>> is a bit faster for reads (20%).
>>>
>>> showed no meaningful disk usage changes. But I'm pretty sure this is
>>> an artifact of the testing dataset, which isn't as up-to-date-branch-heavy
>>> as more recent revision ranges in our source tree are.
>>>
>>> In trunk, Berkeley DB:
>>>
>>> is significantly faster (50%) for write operations. This is almost
>>> certainly because post-commit deltification is doing a single
>>> deltification instead of touching a chain of files.
>>>
>>> is significantly slower (300%) for read operations. Distance to
>>> nearest fulltext?
>>>
>>> showed significant improvement in disk usage (20% savings) in trunk.
>>> For the same reasons that FSFS didn't show much improvement here, I
>>> must assume rep-sharing wasn't the real win here. More likely the
>>> minimization of fulltexts (one per line of history) is the win here.
>>>
>>> In all things except disk usage (now in trunk), FSFS remains a clear winner
>>> over BDB in this testing.
>>>
>>> Attached are the script I used and a spreadsheet with the actual findings.
>> I've got an uncommitted patch which causes Berkeley DB to store *both* MD5
>> and SHA1 checksums, and to be able to cough up the one required by callers.
>> I re-ran the numbers with this patch, and have attached an updated
>> spreadsheet. What I find is that the space and performance cost for
>> calculating and storing both checksums is minimal (atop what the trunk code
>> was already doing). But the read costs dropped by half! I suspect this is
>> because svn_fs_file_md5_checksum() forces a walk over the file contents if
>> the MD5 checksum isn't readily available in the database, which is the case
>> in the current trunk code.
>
> Where do we still use svn_fs_file_md5_checksum() explicitly? I thought most of
> those calls had been switched to svn_fs_file_checksum(), which can have the same
> behavior you describe, but isn't forced to.
Turns out the calls I was thinking of *are* using svn_fs_file_checksum().
But they also pass TRUE for force. (These are in libsvn_repos/dump.c.) Six
of one, a half-dozen of the other...
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Comparison testing: { FSFS, BDB } x { 1.5.4, trunk }
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
C. Michael Pilato wrote:
> C. Michael Pilato wrote:
>> I did a little bit of simple comparison testing between FSFS and BDB in
>> 1.5.4 and trunk. My testing involved loading a dumpfile of 5000 revisions
>> (taken from our own repository), then doing some single-revision dumps at a
>> few time-slices across the loaded repository.
>>
>> Here are the highlights (percentages are ballpark estimates).
>>
>> In trunk, FSFS:
>>
>> is significantly slower (30%) for writes operations. I have no idea why.
>>
>> is a bit faster for reads (20%).
>>
>> showed no meaningful disk usage changes. But I'm pretty sure this is
>> an artifact of the testing dataset, which isn't as up-to-date-branch-heavy
>> as more recent revision ranges in our source tree are.
>>
>> In trunk, Berkeley DB:
>>
>> is significantly faster (50%) for write operations. This is almost
>> certainly because post-commit deltification is doing a single
>> deltification instead of touching a chain of files.
>>
>> is significantly slower (300%) for read operations. Distance to
>> nearest fulltext?
>>
>> showed significant improvement in disk usage (20% savings) in trunk.
>> For the same reasons that FSFS didn't show much improvement here, I
>> must assume rep-sharing wasn't the real win here. More likely the
>> minimization of fulltexts (one per line of history) is the win here.
>>
>> In all things except disk usage (now in trunk), FSFS remains a clear winner
>> over BDB in this testing.
>>
>> Attached are the script I used and a spreadsheet with the actual findings.
>
> I've got an uncommitted patch which causes Berkeley DB to store *both* MD5
> and SHA1 checksums, and to be able to cough up the one required by callers.
> I re-ran the numbers with this patch, and have attached an updated
> spreadsheet. What I find is that the space and performance cost for
> calculating and storing both checksums is minimal (atop what the trunk code
> was already doing). But the read costs dropped by half! I suspect this is
> because svn_fs_file_md5_checksum() forces a walk over the file contents if
> the MD5 checksum isn't readily available in the database, which is the case
> in the current trunk code.
Where do we still use svn_fs_file_md5_checksum() explicitly? I thought most of
those calls had been switched to svn_fs_file_checksum(), which can have the same
behavior you describe, but isn't forced to.
-Hyrum
Re: Comparison testing: { FSFS, BDB } x { 1.5.4, trunk }
Posted by "C. Michael Pilato" <cm...@collab.net>.
C. Michael Pilato wrote:
> I did a little bit of simple comparison testing between FSFS and BDB in
> 1.5.4 and trunk. My testing involved loading a dumpfile of 5000 revisions
> (taken from our own repository), then doing some single-revision dumps at a
> few time-slices across the loaded repository.
>
> Here are the highlights (percentages are ballpark estimates).
>
> In trunk, FSFS:
>
> is significantly slower (30%) for writes operations. I have no idea why.
>
> is a bit faster for reads (20%).
>
> showed no meaningful disk usage changes. But I'm pretty sure this is
> an artifact of the testing dataset, which isn't as up-to-date-branch-heavy
> as more recent revision ranges in our source tree are.
>
> In trunk, Berkeley DB:
>
> is significantly faster (50%) for write operations. This is almost
> certainly because post-commit deltification is doing a single
> deltification instead of touching a chain of files.
>
> is significantly slower (300%) for read operations. Distance to
> nearest fulltext?
>
> showed significant improvement in disk usage (20% savings) in trunk.
> For the same reasons that FSFS didn't show much improvement here, I
> must assume rep-sharing wasn't the real win here. More likely the
> minimization of fulltexts (one per line of history) is the win here.
>
> In all things except disk usage (now in trunk), FSFS remains a clear winner
> over BDB in this testing.
>
> Attached are the script I used and a spreadsheet with the actual findings.
I've got an uncommitted patch which causes Berkeley DB to store *both* MD5
and SHA1 checksums, and to be able to cough up the one required by callers.
I re-ran the numbers with this patch, and have attached an updated
spreadsheet. What I find is that the space and performance cost for
calculating and storing both checksums is minimal (atop what the trunk code
was already doing). But the read costs dropped by half! I suspect this is
because svn_fs_file_md5_checksum() forces a walk over the file contents if
the MD5 checksum isn't readily available in the database, which is the case
in the current trunk code.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand