[prev in list] [next in list] [prev in thread] [next in thread]
List: subversion-dev
Subject: Re: new svnfsfs tool
From: Stefan Fuhrmann <stefan.fuhrmann () wandisco ! com>
Date: 2014-05-19 6:56:57
Message-ID: CA+t0gk1VPrgLDHEETqzZiG9MpKH5erX9=KROMO7yKTdnXMgTLg () mail ! gmail ! com
[Download RAW message or body]
On Sat, May 17, 2014 at 10:10 AM, Branko =C4=8Cibej <brane@wandisco.com> wr=
ote:
> On 16.05.2014 19:56, Stefan Sperling wrote:
>
> On Thu, May 15, 2014 at 10:48:37AM -0000, stefan2@apache.org wrote:
>
> Author: stefan2
> Date: Thu May 15 10:48:37 2014
> New Revision: 1594860
>
> URL: http://svn.apache.org/r1594860
> Log:
> Introduce FSFS expert tool 'svnfsfs'. It is intended to grow various
> FSFS-specific commands in the future - like recreating repcache.db etc.
>
> For now, it provides two commands to read (dump) and write (load)
> format 7 index information. With these, corrupted repositories can
> be manipulated / fixed by hand or script.
>
> The former fsfs-stats tool becomes a sub-command as well.
>
> Wouldn't it make sense to integrate such functionality in svnadmin?
>
>
> If the tool is strictly for fiddling with internals of FSFS repositories
> that cannot meaningfully apply to other backends, then no, probably not .=
..
> we really don't want to have backend-specific commands in svnadmin.
>
I agree.
But I also see Stefan's implicit point of having fewer tools
and doing things consistently over e.g. all backends. My
rationale is as follows: Is there a reasonable way to define
FS vtable functions that will provide the necessary data in
a mostly generic way?
For the "recreate rep-cache.db" mentioned in the log message,
it would certainly be possible to add an '--rebuild-caches' option.
This is fairly generic and should therefore go into svnadmin,
unless we needed some more specific option or UI interaction.
OTOH, it would be very hard to define a generic read/write
interface for backend-specific index data. So, dump-index
and load-index are better of in a separate tool that directly
calls into the FSFS lib.
The 'stats' sub-command is a borderline case. Lots of the
grouping etc. may work for FSX as well. However, the container-
based structure of FSX may require a different data structure
(1 additional level of indirection?) and it is too early to design
what the interface should look like. So, for now it's fine to have
it in the extra tool (at least dropping fsfs-stats in the process)
but later the code may be moved behind the FS API.
As for svn-bench, yes it would be conceivable to add a '--null'
option to the standard client UI. But there are a few issues
with that approach. First, we may not support all other options
of the respective command when in '--null' mode. That's not
terribly bad but there would be more to test or we may get
the occasional bug report.
Secondly, svn-bench is intended to be a minimalistic protocol
driver. It takes various shortcuts and even duplicates and
modifies code from the client lib (and possibly others) to
bypass client-side bottlenecks.
So again, having one tool instead of two would be nice but
the overall coding, testing and maintenance effort may then
bit higher than with the current setup.
-- Stefan^2.
[Attachment #3 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, May 17, 2014 \
at 10:10 AM, Branko Čibej <span dir="ltr"><<a href="mailto:brane@wandisco.com" \
target="_blank">brane@wandisco.com</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>On 16.05.2014 19:56, Stefan Sperling
wrote:<br>
</div>
<blockquote type="cite">
<pre>On Thu, May 15, 2014 at 10:48:37AM -0000, <a \
href="mailto:stefan2@apache.org" target="_blank">stefan2@apache.org</a> wrote: </pre>
<blockquote type="cite">
<pre>Author: stefan2
Date: Thu May 15 10:48:37 2014
New Revision: 1594860
URL: <a href="http://svn.apache.org/r1594860" \
target="_blank">http://svn.apache.org/r1594860</a> Log:
Introduce FSFS expert tool 'svnfsfs'. It is intended to grow various
FSFS-specific commands in the future - like recreating repcache.db etc.
For now, it provides two commands to read (dump) and write (load)
format 7 index information. With these, corrupted repositories can
be manipulated / fixed by hand or script.
The former fsfs-stats tool becomes a sub-command as well.
</pre>
</blockquote>
<pre>Wouldn't it make sense to integrate such functionality in svnadmin?
</pre>
</blockquote>
<br>
If the tool is strictly for fiddling with internals of FSFS
repositories that cannot meaningfully apply to other backends, then
no, probably not ... we really don't want to have backend-specific
commands in svnadmin.<br></div></blockquote><br></div>I agree.<br><br></div><div \
class="gmail_extra">But I also see Stefan's implicit point of having fewer \
tools<br></div><div class="gmail_extra">and doing things consistently over e.g. all \
backends. My<br> rationale is as follows: Is there a reasonable way to \
define<br></div><div class="gmail_extra">FS vtable functions that will provide the \
necessary data in<br></div><div class="gmail_extra">a mostly generic \
way?<br><br></div> <div class="gmail_extra">For the "recreate rep-cache.db" \
mentioned in the log message,<br></div><div class="gmail_extra">it would certainly be \
possible to add an '--rebuild-caches' option.<br></div><div \
class="gmail_extra"> This is fairly generic and should therefore go into \
svnadmin,<br></div><div class="gmail_extra">unless we needed some more specific \
option or UI interaction.<br><br></div><div class="gmail_extra">OTOH, it would be \
very hard to define a generic read/write<br> </div><div class="gmail_extra">interface \
for backend-specific index data. So, dump-index<br>and load-index are better of in a \
separate tool that directly<br>calls into the FSFS lib.<br><br></div><div \
class="gmail_extra">The 'stats' sub-command is a borderline case. Lots of \
the<br> </div><div class="gmail_extra">grouping etc. may work for FSX as well. \
However, the container-<br></div><div class="gmail_extra">based structure of FSX may \
require a different data structure<br></div><div class="gmail_extra"> (1 additional \
level of indirection?) and it is too early to design<br></div><div \
class="gmail_extra">what the interface should look like. So, for now it's fine to \
have<br>it in the extra tool (at least dropping fsfs-stats in the process)<br> \
</div><div class="gmail_extra">but later the code may be moved behind the FS \
API.<br><br></div><div class="gmail_extra">As for svn-bench, yes it would be \
conceivable to add a '--null'<br></div><div class="gmail_extra"> option to \
the standard client UI. But there are a few issues<br>with that approach. First, we \
may not support all other options<br></div><div class="gmail_extra">of the respective \
command when in '--null' mode. That's not<br> </div><div \
class="gmail_extra">terribly bad but there would be more to test or we may get<br>the \
occasional bug report.<br><br></div><div class="gmail_extra">Secondly, svn-bench is \
intended to be a minimalistic protocol<br> driver. It takes various shortcuts and \
even duplicates and<br>modifies code from the client lib (and possibly others) \
to<br>bypass client-side bottlenecks.<br></div><div \
class="gmail_extra"><br></div><div class="gmail_extra"> So again, having one tool \
instead of two would be nice but<br>the overall coding, testing and maintenance \
effort may then<br></div><div class="gmail_extra">bit higher than with the current \
setup.<br><br></div><div class="gmail_extra">
-- Stefan^2.<br></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic