summaryrefslogtreecommitdiff
path: root/obnam.1.in
diff options
context:
space:
mode:
authorLars Wirzenius <liw@liw.fi>2012-03-10 18:53:38 +0000
committerLars Wirzenius <liw@liw.fi>2012-03-10 18:53:38 +0000
commit088bb52c014bd3d0ecdd434510a22ab726a68155 (patch)
treed6224e9c6e33e3deca137ba861e7abfa72302f58 /obnam.1.in
parentf64d6d4dc745e124f184a2b144add092b41d161a (diff)
downloadobnam-088bb52c014bd3d0ecdd434510a22ab726a68155.tar.gz
Update manual page about locking
Diffstat (limited to 'obnam.1.in')
-rw-r--r--obnam.1.in19
1 files changed, 19 insertions, 0 deletions
diff --git a/obnam.1.in b/obnam.1.in
index 5c393795..180c1455 100644
--- a/obnam.1.in
+++ b/obnam.1.in
@@ -439,6 +439,25 @@ made a successful backup to the new repository.
.PP
If you think this is a silly state of affairs, you're entirely correct.
Please voice your concern about this in the Obnam bug tracker.
+.SS "Multiple clients and locking"
+.B obnam
+supports sharing a repository between multiple clients.
+The clients can share the file contents (chunks),
+so that if client A backs up a large file,
+and client B has the same file,
+then B does not need to upload the large file to the repository a second time.
+For this to work without confusion,
+the clients use a simple locking protocol that allows only one client
+at a time to modify the shared data structures.
+Locks do not prevent read-only access at the same time:
+this allows you to restore while someone else is backing up.
+.PP
+Sometimes a read-only operation happens to access a data structure at the
+same time as it is being modified.
+This can result in a crash.
+It will not result in corrupt data,
+or incorrect restores.
+However, you may need to restart the read-only operation after a crash.
.\"---------------------------------------------------------------------
.SH OPTIONS
.\" ------------------------------------------------------------------