* Re: [Qemu-devel] [Qemu-block] image locking
2017-09-19 15:46 [Qemu-devel] image locking Vladimir Sementsov-Ogievskiy
2017-09-19 15:55 ` Daniel P. Berrange
@ 2017-09-19 16:03 ` Eric Blake
1 sibling, 0 replies; 3+ messages in thread
From: Eric Blake @ 2017-09-19 16:03 UTC (permalink / raw)
To: Vladimir Sementsov-Ogievskiy, Fam Zheng; +Cc: qemu-devel, qemu block
[-- Attachment #1: Type: text/plain, Size: 2413 bytes --]
On 09/19/2017 10:46 AM, Vladimir Sementsov-Ogievskiy wrote:
> Hi Fam!
>
> I have a question about your image locking series:
>
> Can you please explain, why OFD locking is enabled by default and posix
> locking is not? What is wrong with posix locking, what are the problems?
POSIX locking (lockf(3), which wraps fcntl(2)) has a severe flaw,
mandated by POSIX due to historical behavior, regarding the duration of
the lock - within a single process, ALL lock access to the same inode,
regardless of which fd triggered the access, is tied together:
int fd1 = open("/dev/null", O_RDONLY);
int fd2 = open("/dev/null", O_RDONLY);
fcntl(F_SETLK, fd1, ...); // Obtain lock
close(fd2); // oops, lock on fd1 is lost!
BSD locks (flock(2)) do not have this issue, but have a different flaw -
they can only lock the entire file at once. But we need fine-grained
access (we lock different byte ranges in order to convey multiple pieces
of information across processes).
Hence, Linux invented OFD locking as the best of both worlds (the locks
are tied to the inode rather than the process, but allow fine-grained
access), and it is likely that POSIX will eventually standardize it
(http://austingroupbugs.net/view.php?id=768).
More from the Linux 'man fcntl' page:
> The record locks described above are associated with the process
> (unlike the open file description locks described below). This has
> some unfortunate consequences:
>
> * If a process closes any file descriptor referring to a file, then
> all of the process's locks on that file are released, regardless of
> the file descriptor(s) on which the locks were obtained. This is
> bad: it means that a process can lose its locks on a file such as
> /etc/passwd or /etc/mtab when for some reason a library function
> decides to open, read, and close the same file.
>
> * The threads in a process share locks. In other words, a multi‐
> threaded program can't use record locking to ensure that threads
> don't simultaneously access the same region of a file.
>
> Open file description locks solve both of these problems.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread