From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2DCF810ED65C for ; Fri, 27 Mar 2026 11:42:07 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1w65Yx-0005Pq-Q3; Fri, 27 Mar 2026 07:41:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1w65Yn-0005PH-UB for qemu-devel@nongnu.org; Fri, 27 Mar 2026 07:41:07 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1w65Yk-0007D5-Iq for qemu-devel@nongnu.org; Fri, 27 Mar 2026 07:41:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1774611661; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=d2abvhO4lwnFpJqSctaxIc1ivGIABeHqj/k3gAbmXQM=; b=Kfr06iMIGQdfuWYHjIGc4JtlLrqJ2NiyP4gCdw/8skwi4s9f2OthKuKRl2H5yH5Kl3+bLg miCLxQ8SD7WxMhzJJVKZt+ODdgHGxGMc81UJtGuTw1EA1jAVfisTgZkIH/Z094/vkaW+3b Apr58GYBuLZ8zvIb97OvBzLXawCQo6Q= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-320-FU7T0eChM52L9zawaCDC1Q-1; Fri, 27 Mar 2026 07:40:59 -0400 X-MC-Unique: FU7T0eChM52L9zawaCDC1Q-1 X-Mimecast-MFC-AGG-ID: FU7T0eChM52L9zawaCDC1Q_1774611658 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 61B1118005B0; Fri, 27 Mar 2026 11:40:58 +0000 (UTC) Received: from redhat.com (unknown [10.44.33.112]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 7046E1800576; Fri, 27 Mar 2026 11:40:55 +0000 (UTC) Date: Fri, 27 Mar 2026 11:40:51 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Silvan Kaiser Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, kwolf@redhat.com, hreitz@redhat.com, pierrick.bouvier@linaro.org, eblake@redhat.com, armbru@redhat.com Subject: Re: [PATCH v1 0/3] block: Add 'posix' option for file locking Message-ID: References: <20260326091948.194529-1-silvan@quobyte.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.2.14 (2025-02-20) X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Received-SPF: pass client-ip=170.10.133.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org 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 :|