[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: hotbackup & FSFS repos

From: Paul Koning <pkoning_at_equallogic.com>
Date: 2006-01-18 20:19:08 CET

>>>>> "Jacob" == Jacob Atzen <jacob@aub.dk> writes:

 Jacob> On Wed, Jan 18, 2006 at 09:47:28AM -0500, Paul Koning wrote:
>> >>>>> "matador" == matador <matador1910-lists@yahoo.com> writes:
 matador> i dont need to bother with hotbackups with FSFS repos,
 matador> correct? only use that with berkeley db-based repos?
>> I wonder. The doc doesn't say that, and hotcopy certainly works
>> just fine with FSFS.
>> It sure would be nice to have a supported "cold copy" procedure.
>> So far I have a lot of rumor on how to construct one but no
>> guidance from the most knowledgeable people...

 Jacob> Your wish has been granted:

 Jacob> <http://svn.collab.net/repos/svn/trunk/notes/fsfs>

Thanks, that's helpful. It doesn't answer the specific question I
mentioned, though it answers several others.

Summarizing what I learned:

1. If an FSFS repository is logically read-only, it is also read-only
   at the file system level.

2. "svnadmin hotcopy" does "the right thing" for FSFS.

3. If I use simple file system copy, and changes are being made, then
   that will NOT do the right thing, for two reasons.

   a. Any pending transactions will have their transaction files
      copied and those will not be cleaned up.

   b. If a commit is happening during the copy, I can end up with
      a missing file problem ("current" points to data that isn't
      in the copy). That is described as "easily repaired" but
      no procedure is given for repairing it, and "svnadmin recover"
      in particular doesn't do that.

So my conclusion is that I can do "cold copy" by these steps:

1. Set the config file for the repository to indicate that no one has
   write access.

2. Wait for all pending writes to complete. But how???

3. Use file system copy tools to copy the repository.

4. Change the config file back to allow write access.

Now for #2...

I'm only using svnserve, in inetd mode. So it seems logical to expect
that svnserve isn't running persistently. But that expectation is
false: I can see two copies on my system, one of which has been up for
10 days. I can change xinetd.d/subversion to stop the activation of
new svnserve instances. Then all I need is to tell the old ones to go
away when done. The manpage doesn't say how. If normal Unix rules
applied, sending it a SIGTERM might work, or it might cause abnormal
termination of pending work. If the latter, then one would expect
that SIGHUP might be the "exit when done" signal.

A quick look at the code doesn't show any of this, though... So I'm
still digging...


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 18 23:15:20 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.