Author: danielsh
Date: Mon Oct 22 01:20:05 2012
New Revision: 1400746
URL: http://svn.apache.org/viewvc?rev=1400746&view=rev
Log:
* notes/fsfs: Document another problem with rsync'ing FSFS filesystems.
Suggested by: breser
Modified:
subversion/trunk/notes/fsfs
Modified: subversion/trunk/notes/fsfs
URL:
http://svn.apache.org/viewvc/subversion/trunk/notes/fsfs?rev=1400746&r1=1400745&r2=1400746&view=diff
==============================================================================
--- subversion/trunk/notes/fsfs (original)
+++ subversion/trunk/notes/fsfs Mon Oct 22 01:20:05 2012
@@ -234,6 +234,16 @@ repository. The backed-up "current" fil
new revision which wasn't copied, or which was only partially
populated when it was copied.
+[ Update: as of 1.6, FSFS uses an optional SQLite DB, rep-cache.db, when
+rep-sharing is enabled. SQLite provides no guarantee that copying live
+databases will result in copies that are uncorrupt, or that are corrupt but
+will raise an error when accessed. 'svnadmin hotcopy' avoids the problem by
+establishing an appropriate SQLite lock (see svn_sqlite__hotcopy()). User
+code should either use an atomic filesystem snapshot (as with zfs/LVM),
+refrain from copying rep-cache.db, or stop all access to that file before
+copying it (either by disabling commits or by establishing a lock a la
+svn_sqlite__hotcopy()). ]
+
The "svnadmin hotcopy" command avoids this problem by copying the
"current" file before copying the revision files. But a backup using
the hotcopy command isn't as efficient as a straight incremental
