Difference between revisions of "File locks"
m |
|||
| (2 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | Some app may use file locks for synchronization. Generally they will use flock or | + | 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). |
| − | + | Currently supported lock types are: | |
| − | + | * <code>flock()</code> locks | |
| − | * flock() locks | + | * POSIX (<code>fcntl</code>) locks |
| − | * | ||
| − | |||
| − | |||
| + | In future releases, we plan to also support: | ||
* file leases | * file leases | ||
* OFD locks | * OFD locks | ||
Latest revision as of 10:43, 22 February 2017
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 the --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).
Currently supported lock types are:
flock()locks- POSIX (
fcntl) locks
In future releases, we plan to also support:
- file leases
- OFD locks
- mandatory locks