On Feb 23, 2006, at 18:35, Kahn, Peter wrote:
> Q1. What tuning options are there for FSFS repositories?
> is there a good guide somewhere?
I'm not aware of any tuning options.
> Q2. What is the best way to monitor a FSFS repository?
I'm not aware of any FSFS-specific things that would need to be
monitored. You can of course write a post-commit hook which sends an
email to your team with the diff of the changes in that revision, so
that your developers can monitor each other's changes, but that has
nothing to do with your choice of BDB or FSFS.
> Q3. What are the gotchas for converting to a FSFS repository?
> - all local developer workspaces will need to be checked-out
> anew
> as switch will not work due to the fact that the old repos and
> the new will be two different repositories
All working copies should continue to function as they did before.
You do not need to check them out again. The new repository will have
the same repository ID as the one from which it was dumped so clients
will see it as exactly the same repository.
> Q4. What are the gotchas for running a FSFS repository?
>
> Q5. What are the best practices for FSFS repository health?
> - Is there some thing I should do on a regular basis
> to handle skip-deltas and delta combination to improve
> performance? [deltify?]
I'm not aware of any routine maintenance that would be necessary. We
haven't done any on our FSFS repo in its 1-year life, except dump and
reload it when moving from Subversion 1.1 to 1.2 to get the faster
delta algorithm. Keeping regular backups is of course a very good
idea, and occasionally testing that those backups are functional is
worth it too.
> Q6. What kinds of corruption do people see with FSFS and how have they
> dealt with it?
> The red bean book say "FSFS's inability to be 'wedged'
> when something goes wrong" but I'm wondering if anyone
> has seen problems?
There is one issue I've heard reported on the list a couple times,
where with the repository on a Linux server, a commit that's larger
than 2GB will get truncated to 2GB, even though the client is
informed that the commit was successful:
http://subversion.tigris.org/issues/show_bug.cgi?id=2453
Looks like this was a problem in APR and was fixed just a few weeks
ago in their repository, and will be in the next version of APR 1.2.
This bug has also come up on the list a few times and sounds pretty bad:
http://subversion.tigris.org/issues/show_bug.cgi?id=2467
Here's the list of open FSFS issues in the bug tracker; may want to
look at them too:
http://subversion.tigris.org/issues/buglist.cgi?
short_desc=fsfs&component=subversion&issue_status=NEW&issue_status=START
ED&issue_status=REOPENED&short_desc_type=substring&cmdtype=doit
> - should a rev file go missing due to file system error or
> operator error what would my options be?
>
> || could I extract the file off of a backup and insert
> || in into the right location to recover it?
Keeping a hot-backup of the repository is probably a good idea, in
addition to dumps of either the whole thing and/or individual
revisions or ranges of revisions incrementally.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 23 19:00:18 2006