From: Ciro Iriarte <cyruspy@gmail.com>
To: pve-devel@lists.proxmox.com
Subject: Re: [RFC storage, qemu-server] optional multi-volume / consistency-group snapshot hook
Date: Sun, 19 Jul 2026 07:17:58 -0700 (PDT) [thread overview]
Message-ID: <6a5cdc96.13be6df8.22eac4.57d6@mx.google.com> (raw)
In-Reply-To: <6a5cd5ca.8e75e0cb.f69c7.89e4@mx.google.com>
I under-sold this in the mail this morning. I said the `cg` tag maps onto the two
backends I can test, Ceph and a VSP array. ZFS is a third.
I had assumed ZFS atomicity meant `zfs snapshot -r` over a subtree, which would
only give you a group if the volumes happened to share a parent. That is wrong.
`zfs snapshot` takes a list, and they land in one transaction group wherever the
datasets sit:
# zfs snapshot rpool/cgA@cg1 rpool/cgB@cg1
# zfs get -Hp -o value createtxg rpool/cgA@cg1 rpool/cgB@cg1
7830984
7830984
Same createtxg, so the same instant, for an arbitrary set rather than a subtree.
Checked it end to end on zvols, since that is what a VM disk is on zfspool. Two
64M zvols with distinct random content, snapshotted in one command, both then
overwritten, then cloned from the snapshots:
pre-snapshot A=1f5d99cb... B=ca4d6039...
post-write A=b9165b06... B=98949c0d...
clone of @cg1 A=1f5d99cb... B=ca4d6039...
Both clones came back with the pre-snapshot content. So the group snapshot caught
both volumes before the writes, and cloning from its members works -- the same
grouping serves snapshots and clones.
That answers the scope question I asked in the first mail. This is not a
two-backend feature for Ceph and vendor arrays: zfspool can do it with a command it
already runs, and zfspool is far more common in the field than either. So the tag
would be doing real work for in-tree storage, not just for out-of-tree plugins
like mine.
The ones that cannot, so nobody has to check: LVM thick and thin have no multi-LV
atomic snapshot primitive in dm, so `lvcreate -s` per LV gives different instants
unless the caller freezes around them. btrfs snapshots are per-subvolume and PVE
uses one subvolume per disk, so no arbitrary grouping there either.
Thanks,
Ciro
parent reply other threads:[~2026-07-19 14:18 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <6a5cd5ca.8e75e0cb.f69c7.89e4@mx.google.com>]
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=6a5cdc96.13be6df8.22eac4.57d6@mx.google.com \
--to=cyruspy@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.