From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-block <qemu-block@nongnu.org>,
Markus Armbruster <armbru@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Max Reitz <mreitz@redhat.com>, Nir Soffer <nsoffer@redhat.com>,
den@openvz.org, Eric Blake <eblake@redhat.com>
Subject: Re: [PATCH v2] docs: document file-posix locking protocol
Date: Thu, 15 Jul 2021 18:19:05 +0100 [thread overview]
Message-ID: <YPBuCaSzQBQjIeD3@redhat.com> (raw)
In-Reply-To: <a18fd577-7f23-2e4f-0833-1ac13310313d@virtuozzo.com>
On Thu, Jul 15, 2021 at 08:13:40PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> 03.07.2021 17:50, Nir Soffer wrote:
> > On Sat, Jul 3, 2021 at 4:51 PM Vladimir Sementsov-Ogievskiy
> > <vsementsov@virtuozzo.com> wrote:
>
> [..]
>
> > > +
> > > +Important notice: Qemu may fallback to POSIX file locks only if OFD locks
> > > +unavailable. Other programs should behave similarly: use POSIX file locks
> > > +only if OFD locks unavailable and if you are OK with drawbacks of POSIX
> > > +file locks (for example, they are lost on close() of any file descriptor
> > > +for that file).
> >
> > Worth an example.
>
> Hmm.. Copying here the whole #ifdef and probing logic around these locks from Qemu is too much..
>
> I can't imagine what small and short could be added here.
>
> Actually I think, OFD is old enough so we shouldn't care
> too much about older kernels without it. Let's just rewrite
> paragraph to something like this:
Yes, that's a good point. From a Linux POV, I think our platform
support matrix means we can assume existance of OFD locking
unconditionally. The kernel impl transparently applies to all
filesystems too.
So we could likely change the code such that Linux always uses
OFD and non-Linux uses traditional POSIX locks.
> Related question, are POSIX locks somehow compatible with OFD
> locks? If one program use OFD and the other use POSIX locks on
> the same file.. Will it work or not?
Yes, the kernel level implementation uses the same locking primitives
internally. The only difference between the two is how they're invoked
from userspace, and the semantics around lock release when closing
files. So it is fully compatible with applications mixing the two
APIs for fcntl POSIX and OFD locking
The flock() syscall is however completely independant locking
from the fcntl based locking.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2021-07-15 17:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-03 13:50 [PATCH v2] docs: document file-posix locking protocol Vladimir Sementsov-Ogievskiy
2021-07-03 14:50 ` Nir Soffer
2021-07-05 7:55 ` Vladimir Sementsov-Ogievskiy
2021-07-05 8:26 ` Denis V. Lunev
2021-07-15 17:13 ` Vladimir Sementsov-Ogievskiy
2021-07-15 17:19 ` Daniel P. Berrangé [this message]
2021-07-15 20:00 ` Vladimir Sementsov-Ogievskiy
2021-07-16 16:21 ` Vladimir Sementsov-Ogievskiy
2021-07-16 18:47 ` Vladimir Sementsov-Ogievskiy
2021-07-16 20:35 ` Vladimir Sementsov-Ogievskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YPBuCaSzQBQjIeD3@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=den@openvz.org \
--cc=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=nsoffer@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).