You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A variety of tools exist that manage (sub-)trees of the dataset hierarchy:
Virtual machines (Proxmox, libvirt zpool driver, various bhyve wrappers)
Containerization (Jail managers on FreeBSD, Docker zfs graph driver)
Auto-snapshotters (sanoid, zrepl)
Replication & backup tools (syncoid, zrepl)
(please comment below, and I'll extend this list)
All these tools have in common: they build abstractions on top of ZFS datasets.
Some tools do not expect users to interact with the ZFS datasets directly, i.e., through the zfs command.
Further, if the tool creates lots of datasets, the zfs CLI user experience is made worse by cluttering the output.
An excellent example of this is the Docker zfs graph driver:
on systems that use it (e.g., Ubuntu with /var/lib/docker on ZFS), the use of zfs list | grep -v docker is not unheard of.
Proposal
Introduce a new concept to ZFS, called dataset manager:
User experience:
Add a new ZFS property dataset_manager for filesystems, volumes, and snapshots.
dataset_manager always applies to an entire sub-tree of the dataset hierarchy. For example, if tank/var/lib/docker has dataset_manager=docker, then all children of tank/var/lib/docker have the same dataset_manager property set.
TBD: how to deal with jail managers / Linux namespaces.
Read-only CLI commands that do not target a specific dataset become sensitive to dataset_manager by default:
A bare zfs list only shows the top dataset_manager dataset, but none of its children.
zfs list -r tank/var would also not list the dataset
But zfs list -r tank/var/docker would list the entire hierarchy.
Similar rules apply to zfs get and zfs holds.
Mutating CLI commands that operate on datasets with dataset_manager != none fail with an error.
Setting the environment variable ZFS_CURRENT_DATASET_MANAGER causes
read-only commands to ignore the above rules for datasets with a matching dataset_manager property,
mutating commands to succeed if they operate on a dataset with a matching dataset_manager property, and
mutating commands to implicitly set the dataset_manager property on new datasets they create.
Channel programs are insensitive to dataset_manager.
Example UX
# administrator need to set the property explicitly
$ zfs create -o dataset_manager=docker tank/var/lib/docker
# start the tool that manages a dataset sub-hierarchy
$ export ZFS_CURRENT_DATASET_MANAGER=docker
## docker just runs normal commands
$ zfs create tank/var/lib/docker/8551e44f95bf75de129e5e9844e6eba4fe5a8ccd1033ea81f2b64ebee600c303
$ unset ZFS_CURRENT_DATASET_MANAGER
# administrator lists datasets
# datasets with hidden children have a "+" suffix, which is a forbidden character in dataset names
$ zfs list -o name
tank
tank/var
tank/var/lib
tank/var/lib/docker+
tank/var/run
$ ZFS_CURRENT_DATASET_MANAGER=docker zfs list
tank
tank/var
tank/var/lib
tank/var/lib/docker
tank/var/lib/docker/8551e44f95bf75de129e5e9844e6eba4fe5a8ccd1033ea81f2b64ebee600c303
tank/var/run
Request for Comments
I'm interested in what the general community sentiment is about ...
the general idea of making it possible to hide sub-trees of the dataset hierarchy by default, and
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
A variety of tools exist that manage (sub-)trees of the dataset hierarchy:
zfs
graph driver)All these tools have in common: they build abstractions on top of ZFS datasets.
Some tools do not expect users to interact with the ZFS datasets directly, i.e., through the
zfs
command.Further, if the tool creates lots of datasets, the
zfs
CLI user experience is made worse by cluttering the output.An excellent example of this is the Docker
zfs
graph driver:on systems that use it (e.g., Ubuntu with /var/lib/docker on ZFS), the use of
zfs list | grep -v docker
is not unheard of.Proposal
Introduce a new concept to ZFS, called dataset manager:
User experience:
dataset_manager
for filesystems, volumes, and snapshots.dataset_manager
always applies to an entire sub-tree of the dataset hierarchy. For example, iftank/var/lib/docker
hasdataset_manager=docker
, then all children oftank/var/lib/docker
have the samedataset_manager
property set.dataset_manager
by default:zfs list
only shows the topdataset_manager
dataset, but none of its children.zfs list -r tank/var
would also not list the datasetzfs list -r tank/var/docker
would list the entire hierarchy.zfs get
andzfs holds
.dataset_manager != none
fail with an error.ZFS_CURRENT_DATASET_MANAGER
causesdataset_manager
property,dataset_manager
property, anddataset_manager
property on new datasets they create.dataset_manager
.Example UX
Request for Comments
I'm interested in what the general community sentiment is about ...
Beta Was this translation helpful? Give feedback.
All reactions