[Bug 262710] glabel labels should not be created for snapshots of zvols

From: <bugzilla-noreply_at_freebsd.org>
Date: Mon, 21 Mar 2022 19:29:53 UTC

            Bug ID: 262710
           Summary: glabel labels should not be created for snapshots of
           Product: Base System
           Version: 12.3-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: d8zNeCFG@aon.at

Note: This ticket contains both a defect report and a feature request. At least
the former should be addressed.

=== Defect report ===

- FreeBSD 12.3 latest patches
- Many zvols which serve as virtual disks for virtual machines, some of these
running FreeBSD
- The vdisks are exported via iSCSI to various virtualization technologies such
as bhyve, VirtualBox, Hyper-V, etc. They appear there as /dev/daX, /dev/adaX,
/dev/vtblkX, etc.
- The vdisks are sliced/partitioned for FreeBSD in the "old-fashioned" way: s4a
for /, s4b for swap, s4d for /usr.
- In order to enable seamless booting of FreeBSD under these various
virtualization technologies, the partitions carrying UFS filesystems get a UFS
filesystem label, and the swap partitions get a glabel label.
- Therefore, in a typical FreeBSD VM, in /etc/fstab there are lines such as

/dev/ufs/disk904s4a     /       ufs     rw      7 1
/dev/label/disk904s4b   none    swap    sw      0 0
/dev/ufs/disk904s4d     /usr    ufs     rw      7 2

- The labeled slices/partitions in the zvols (also) appear directly in the
filesystem server's /dev/ufs and /dev/label. This is expected and desirable
because sometimes operations are done directly from the filesystem server
(e.g., mounting a UFS filesystem for inspection when it is not in use by a VM).

Scenario (continued):
- For backup purposes, daily snapshots of all zvols are taken.
- Due to an oversight, one day the zvol/slice/partition in which the labeled
geom disk904s4b resides is cleared (using dd if=/dev/zero...)

Result (continued):
- On the filesystem server, /dev/label/disk904s4b still exists. Investigating
with "glabel list" shows that it corresponds to a randomly selected snapshot of
the zvol carring the vdisk 904 (a snapshot taken before the clearing of the

Expected result (defect report):
- Leaves for UFS, glabel, etc. labels should not be created from the
slices/partitions of snapshot zvols.

=== Feature request ===

Scenario (continued):
- For backup purposes, the snapshots are replicated (using zfs send/zfs
receive) to another zpool connected to the same filesystem server. The backup
zpool is connected (imported) only during the time the backup is taken.

- On the filesystem server, when the backup zpool is imported, the labeled
nodes of its zvols supplant the ones of the original zpool in /dev/ufs and
/dev/label (because they carry the identical label names).
- This causes i/o to these devices to reach the backup zvol instead of the

Expected result (feature request):
- It should be possible to disable, at least on the level of zpools and
preferably on the level of zvols, the creation of labels.

Thank you for your patience for reading till here. ;-)

-- Martin

You are receiving this mail because:
You are the assignee for the bug.