Changes

174 bytes added ,  10:43, 22 February 2017
m
no edit summary
Line 1: Line 1: −
Some app may use file locks for synchronization. Generally they will use flock or posix file locks, which were achieved by flock or fcntl system calls. For dump/restore, it is hard to be handled perfectly, because we can't guarantee all potential users are dumped for a specific file lock. Right now, we assume that all file lock users are taken into dump, and we should use the --file-locks option on both dump and restore stages if our app may use any file locks. Remember that file locks dump/restore is only safe for container dumping in theory.
+
Some app may use file locks for synchronization. Generally they will use flock or POSIX file locks, which were achieved by <code>flock</code> or <code>fcntl</code> system calls. For dump/restore, it is hard to be handled perfectly, because we can't guarantee all potential users are dumped for a specific file lock. Right now, we assume that all file lock users are taken into dump, and the {{Opt|--file-locks}} option should be used on both dump and restore stages if our app may use any file locks. Remember that file locks dump/restore can only be absolutely safe for container dumping (as a container, naturally, contains all the file locks users).
   −
Supported lock types are
+
Currently supported lock types are:
 
+
* <code>flock()</code> locks
* flock() locks
+
* POSIX (<code>fcntl</code>) locks
* posix (fcntl) locks
  −
 
  −
In plans
      +
In future releases, we plan to also support:
 
* file leases
 
* file leases
 
* OFD locks
 
* OFD locks