Note: This ticket contains both a defect report and a feature request. At least the former should be addressed. === Defect report === Scenario: - 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 Result: - 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 label). 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. Result: - 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 original. 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
One further thought: On the file server, there are zvols like hal.1/vdisks/903 hal.1/vdisks/904 These are all sliced and partitioned with s4a, s4b, s4d, resulting in device entries like /dev/zvol/hal.1/vdisks/903 /dev/zvol/hal.1/vdisks/903s4 /dev/zvol/hal.1/vdisks/903s4a /dev/zvol/hal.1/vdisks/903s4b /dev/zvol/hal.1/vdisks/903s4d <then all the devices corresponding to snapshots> ... These partitions then have either a UFS or a glabel label, resulting in entries in /dev/ufs and /dev/label. It would be better to move these labels to where the slices/partitions appear, like /dev/zvol/hal.1/vdisks/ufs/disk903s4a (UFS label) /dev/zvol/hal.1/vdisks/ufs/disk903s4d /dev/zvol/hal.1/vdisks/label/disk903s4b (glabel label) In this way there would not be conflicts when the same label name appears in multiple zvols. Also, it is similar to the logic applied to "normal" labels, i.e., those not coming from sliced/partitioned zvols. As said before, labels for snapshots should not be created at all. -- Martin