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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox