diff options
author | Lars Wirzenius <liw@liw.fi> | 2012-03-10 18:53:38 +0000 |
---|---|---|
committer | Lars Wirzenius <liw@liw.fi> | 2012-03-10 18:53:38 +0000 |
commit | 088bb52c014bd3d0ecdd434510a22ab726a68155 (patch) | |
tree | d6224e9c6e33e3deca137ba861e7abfa72302f58 /obnam.1.in | |
parent | f64d6d4dc745e124f184a2b144add092b41d161a (diff) | |
download | obnam-088bb52c014bd3d0ecdd434510a22ab726a68155.tar.gz |
Update manual page about locking
Diffstat (limited to 'obnam.1.in')
-rw-r--r-- | obnam.1.in | 19 |
1 files changed, 19 insertions, 0 deletions
@@ -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 .\" ------------------------------------------------------------------ |