Re: [PATCH v1 0/3] block: Add 'posix' option for file locking

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Mar 27, 2026 at 12:25:41PM +0100, Silvan Kaiser wrote:
> On FUSE, OFD locks are indeed indistinguishable from POSIX locks for the
> underlying fs, which is part of the problem — the filesystem can't ensure
> the correct handling.

QEMU will currently request an OFD lock, which will silently degrade
to be POSIX lock semantics on FUSE. QEMU is fine with POSIX lock
semantics in general, we merely prefer OFD if possible.

This patch adding a "posix" option will cause QEMU to request a POSIX
lock, which will have the same semantics we already get.

How is adding this 'posix' option a benefit ?

> The practical issue we're hitting is stale locks not being cleaned up
> across service restarts (e.g. Kolla/Cinder container restarts), which can
> block volume access.

How does this patch help solve that ?

> There's also a detection caveat: QEMU probes OFD capability against
> /dev/null, which reliably reflects kernel support but says nothing about
> the locking semantics of a remote filesystem actually serving the images.
> Combined with varying OFD support across different versions of various
> remote file systems, an explicit POSIX flag would give operators a
> straightforward way to ensure consistent, predictable behaviour in setups
> where OFD lock semantics cannot be relied upon.

The distinction between OFD & POSIX only matter at a client process
level, it shouldn't affect remote use. OFD locks just fix the crazy
POSIX semantics where closing any FD pointing to the file in QEMU
would release the locks, even if thy were held on a different FD in
QEMU.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|