public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: "Max R. Carrara" <m.carrara@proxmox.com>
To: "Joaquin Varela" <joaquinvarela@neatech.ar>
Cc: pve-devel@lists.proxmox.com
Subject: Re: [PATCH storage v2 0/7] add native ZFS over NVMe/TCP backend
Date: Wed, 21 Oct 2026 10:06:03 +0200	[thread overview]
Message-ID: <DMAD0OSP8Z6N.1KJJVC73FB6AV@proxmox.com> (raw)
In-Reply-To: <20261005002719.1600-1-joaquinvarela@neatech.ar>

On Mon Oct 5, 2026 at 2:27 AM CEST, Joaquin Varela wrote:
> Hi Max,
>
> thank you very much for the detailed review, and sorry that it took a
> few days. I have just sent v3 ("[PATCH storage v3 0/4] add ZFS over
> NVMe/TCP storage plugin"), together with the docs and manager patches.
> It addresses all three points and the helper suggestions: the plugin
> inherits from PVE::Storage::Plugin, LunCmd::NVMET is gone, ZFS/configfs
> parsing and operation planning are local. In patch 1/4 the target runs
> quoted simple commands,
> sometimes joined with '&&', plus one pipe that writes the key, and the
> PVE helpers replace the builtins.
> Instead of dir_glob_regex, which returns only the first match, the
> sysfs walks nest dir_glob_foreach.
>
> Two parts are questions for you, explained in the cover letter: an
> optional patch that guards transaction commands on the target against a
> delayed command of an abandoned operation, which adds target-side
> validation and a small sh guard with the only shell control flow on the
> target, and a longer default
> wait for the shared storage lock. Both are separate patches, so either
> can be dropped without touching the other storage patches (dropping
> the guard also drops one sentence and one paragraph of the docs
> patch). If the size of the series gets in the way, I can split the
> backend patch and split or trim the tests.
>
> The contribution is limited to the storage backend and its integration
> with PVE. It does not implement target high availability, pool takeover
> or target fencing. The optional guard protects control-plane operations
> on a single target too; it is not host or guest-I/O fencing. Multi-head
> target compatibility remains conditional and has not been qualified.
>
> The v3 cover Message-ID is:
> <20261005002609.571-1-joaquinvarela@neatech.ar>
>
> v3 also refuses storages that share an NVMe/TCP listener on the
> target, because after a target restart they could lose their
> controllers. The cover letter has the details.
>
> Kind regards,
> Joaquin Varela

Hi Joaquin!

Thank you very much for refreshing the series! I will do a re-review at
my earliest convenience. 🫡

- Max




      reply	other threads:[~2026-10-21  8:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-02  3:31 [PATCH storage v2 0/7] add native ZFS over NVMe/TCP backend Joaquin Varela
2026-08-02  3:31 ` [PATCH storage v2 1/7] zfs: make LUN provider dispatch overridable Joaquin Varela
2026-08-02  3:31 ` [PATCH storage v2 2/7] zfs: add native NVMe/TCP storage backend Joaquin Varela
2026-08-02  3:31 ` [PATCH storage v2 3/7] zfsnvme: harden node preflight and storage teardown Joaquin Varela
2026-08-02  3:31 ` [PATCH storage v2 4/7] zfsnvme: make all-path loss policy explicit Joaquin Varela
2026-08-02  3:31 ` [PATCH storage v2 5/7] zfsnvme: accept activation hints from storage API Joaquin Varela
2026-08-02  3:31 ` [PATCH storage v2 6/7] zfsnvme: accept short volume activation calls Joaquin Varela
2026-08-02  3:31 ` [PATCH storage v2 7/7] zfsnvme: restore ACLs before publishing target Joaquin Varela
2026-09-28 11:53 ` [PATCH storage v2 0/7] add native ZFS over NVMe/TCP backend Max R. Carrara
2026-10-05  0:27   ` Joaquin Varela
2026-10-21  8:06     ` Max R. Carrara [this message]

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=DMAD0OSP8Z6N.1KJJVC73FB6AV@proxmox.com \
    --to=m.carrara@proxmox.com \
    --cc=joaquinvarela@neatech.ar \
    --cc=pve-devel@lists.proxmox.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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal