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 7F5F9C4167B for ; Wed, 16 Feb 2022 13:18:35 +0000 (UTC) Received: from localhost ([::1]:38786 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nKKCY-0001kY-97 for qemu-devel@archiver.kernel.org; Wed, 16 Feb 2022 08:18:34 -0500 Received: from eggs.gnu.org ([209.51.188.92]:42238) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nKK98-0000Ht-GB for qemu-devel@nongnu.org; Wed, 16 Feb 2022 08:15:02 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:30985) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nKK93-0008GW-6E for qemu-devel@nongnu.org; Wed, 16 Feb 2022 08:15:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1645017296; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Q4hpcN4BbhJULEcIDvbShbG9YPPs+Ctq2rocmrcOmQQ=; b=aR6TaAaq7hGLPWIMKlmKpHITYTNrgj8vgG2G506YP7Itga5uCi+c+xHX+JbpLl0Ed+sbJJ GeiFM+hP/HbccX03u6F9+pzxoQqFQzFkgjRoVOvoA9R8BbH1zm2m8TMO4uiHp5GZGo8TIt mwsH9IgzqhRgnnuu4qwl53G59TvJELI= Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-477-Bcd0k7A9M321vXB7F_Y6lw-1; Wed, 16 Feb 2022 08:14:54 -0500 X-MC-Unique: Bcd0k7A9M321vXB7F_Y6lw-1 Received: by mail-lj1-f198.google.com with SMTP id c31-20020a2ebf1f000000b0022d87a28911so945728ljr.1 for ; Wed, 16 Feb 2022 05:14:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q4hpcN4BbhJULEcIDvbShbG9YPPs+Ctq2rocmrcOmQQ=; b=jtOhnIKkSJQpUhZ2fcPM37u9WQuQ06EFHS7VhQQYXFoy2DCqF/pug7ggK82lDo+i+y IfXF073Wr+MZ4ptI0MFruJ0qG+V0gArstrGmfZi5h0MFMLNfTOhHSLyYuDyNJ3klycpD oqdVtEUkKzCs1zQntZkJFUgb8/na47dme40KRLoFds5QWgJqX5i6/B5MoDwOlKaaxw/B varEr+GD7KfDx0xCqI6KhPWn5S6Qx0VBOUlfy0FCoGUU3o5Z5T+Fe3i4PjiBOXmlNRqL z3Z49KWhbw+QIfPX/VUwPmg/jBIv2lyxIL9OtmA8grnkUxDM5ajbWWJb5p2zRVZifkIP gAcQ== X-Gm-Message-State: AOAM530FCR7jRRd32qCbYz/4z4si8+4G2GRSywKaXdmMBx5hft7w14yJ Jt1oOGtBCapOofTUtK27DgfpgQnWjZG3TMchqYhP88WsRJCLd8gW6Tq9clGQrPPIU28AZjKgfIo gqmLak34J2rBxW3xcLA61QDn0fobHXmA= X-Received: by 2002:a05:6512:c0c:b0:443:7b05:40ef with SMTP id z12-20020a0565120c0c00b004437b0540efmr1947685lfu.325.1645017293135; Wed, 16 Feb 2022 05:14:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJxjVfg7p9xFBSPBNwwriTWN3ma4kFOxidW4mBFyyS1+VEd0EdUCWcRmVT6aD/ECXoW9e0cAJDUurKDZuvDXXE0= X-Received: by 2002:a05:6512:c0c:b0:443:7b05:40ef with SMTP id z12-20020a0565120c0c00b004437b0540efmr1947656lfu.325.1645017292751; Wed, 16 Feb 2022 05:14:52 -0800 (PST) MIME-Version: 1.0 References: <20220215171838.2651387-1-eblake@redhat.com> <20220215232414.g4l4qoqiqyjvnweg@redhat.com> <20220216101254.GI1127@redhat.com> In-Reply-To: <20220216101254.GI1127@redhat.com> From: Nir Soffer Date: Wed, 16 Feb 2022 15:14:36 +0200 Message-ID: Subject: Re: [PATCH v2] nbd/server: Allow MULTI_CONN for shared writable exports To: "Richard W.M. Jones" Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=nsoffer@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="00000000000062623905d8226f7e" Received-SPF: pass client-ip=170.10.129.124; envelope-from=nsoffer@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -28 X-Spam_score: -2.9 X-Spam_bar: -- X-Spam_report: (-2.9 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.083, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kevin Wolf , Vladimir Sementsov-Ogievskiy , qemu-block , QEMU Developers , Markus Armbruster , Hanna Reitz , Eric Blake Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --00000000000062623905d8226f7e Content-Type: text/plain; charset="UTF-8" On Wed, Feb 16, 2022 at 12:13 PM Richard W.M. Jones wrote: > On Tue, Feb 15, 2022 at 05:24:14PM -0600, Eric Blake wrote: > > Oh. The QMP command (which is immediately visible through > > nbd-server-add/block-storage-add to qemu and qemu-storage-daemon) > > gains "multi-conn":"on", but you may be right that qemu-nbd would want > > a command line option (either that, or we accellerate our plans that > > qsd should replace qemu-nbd). > > I really hope there will always be something called "qemu-nbd" > that acts like qemu-nbd. > I share this hope. Most projects I work on are based on qemu-nbd. However in oVirt use case, we want to provide an NBD socket for clients to allow direct access to disks. One of the issues we need to solve for this is having a way to tell if the qemu-nbd is active, so we can terminate idle transfers. The way we do this with the ovirt-imageio server is to query the status of the transfer, and use the idle time (time since last request) and active status (has inflight requests) to detect a stale transfer that should be terminated. An example use case is a process on a remote host that started an image transfer, and killed or crashed in the middle of the transfer without cleaning up properly. To be more specific, every request to the imageio server (read, write, flush, zero, options) updates a timestamp in the transfer state. When we get the status we report the time since that timestamp was updated. Additionally we keep and report the number of inflight requests, so we can tell the case when requests are blocked on inaccessible storage (e.g. non responsive NFS). We don't have a way to do this with qemu-nbd, but I guess that using qemu-storage-daemon when we have qmp access will make such monitoring possible. Nir --00000000000062623905d8226f7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Feb 16, 2022 at 12:13 PM Richard = W.M. Jones <rjone= s@redhat.com> wrote:
On Tue, Feb 15, 2022 at 05:24:14PM -= 0600, Eric Blake wrote:
> Oh. The QMP command (which is immediately visible through
> nbd-server-add/block-storage-add to qemu and qemu-storage-daemon)
> gains "multi-conn":"on", but you may be right that= qemu-nbd would want
> a command line option (either that, or we accellerate our plans that > qsd should replace qemu-nbd).

I really hope there will always be something called "qemu-nbd" that acts like qemu-nbd.

I share this hope. Most projects I work on= are based on qemu-nbd.

However in oVirt use case,= we want to provide an NBD socket for clients to allow direct
acc= ess to disks. One of the issues we need to solve for this is having a way t= o tell if the
qemu-nbd is active, so we can terminate idle transf= ers.

The way we do this with the ovirt-imageio ser= ver is to query the status of the transfer, and
use the idle time= (time since last request) and active status (has inflight requests) to det= ect
a stale transfer that should be terminated. An example use ca= se is a process on a remote
host that started an image transfer, = and killed or crashed in the middle of the transfer
without clean= ing up properly.

To be more specific, every reques= t to the imageio server (read, write, flush, zero, options)
updat= es a timestamp in the transfer state. When we get the status we report the = time since
that timestamp was updated.

A= dditionally=C2=A0we keep and report the number of inflight requests, so we = can tell the case when
requests are blocked on inaccessible stora= ge (e.g. non responsive NFS).

We don't have a = way to do this with qemu-nbd, but I guess that using qemu-storage-daemon
when we have qmp access will make such monitoring possible.

Nir
--00000000000062623905d8226f7e--