This is a draft proposal to address this RFE:
6366244 'nomount' option for container-like functionality
Any feedback from the community would be welcome. In particular, I
struggled with the name of the option. The original 'nomount' name
suffered from the double-negative problem ('nomount=off' could be
confusing). I also considered 'mountable', but we already have
'mountpoint' and 'mounted' as properties.
Also, I am working on 6367103, which would allow for this option (and
any others) to be set at create time, so you don't have the weird
situation where the filesystem is temporarily mounted.
- Eric
A. INTRODUCTION
When ZFS[1] was in development, it exported the idea of
'containers' - datasets with no associated filesystem data. This
allowed them to be used solely as an adminstrative control point for
managing properties.
There were several downsides to this mechanism. The first was that it
was confusing to have the 'mountpoint' property set, but have the
directory actually belong to the underlying filesystem (typically UFS).
For example, if 'pool/export' had its mountpoint set to '/export', then
doing a 'mkdir' would actually create a UFS directory, not a ZFS
directory in 'pool/export'.
Second, it forced the CLI to distinguish between a container and a
filesystem. At first this was accomplished with a trailing slash on the
name, and later introducing the 'ctr' type. Both were confusing to
users for different reasons.
Finally, once a container was created, it could never be a filesystem,
and vice-versa. This meant that if the administrator originally had
'pool/export' as a filesystem, and later decided you wanted per-user
filesystems, the administrator couldn't simply create 'pool/export/foo'
without resorting to a complicated dance of renames and explicit
mountpoints.
However, the container mechanism did have some value, as it allowed
disjoint filesystems to leverage inherited mountpoints within the same
directory. This has been raised on zfs-discuss[2][3] and resulted in
the following RFE:
6366244 'nomount' option for container-like functionality
This functionality allows the user to have 'containers', while
leveraging the benefits of inherited ZFS mountpoints.
B. DESCRIPTION
A new option will be added, 'canmount', which specifies whether the
given filesystem can be mounted with 'zfs mount'. This is a boolean
property, and is not inherited. When set, the filesystem cannot be
mounted with 'zfs mount', and 'zfs mount -a' will ignore it when
iterating over filesystems. The dataset will still have filesystem
data, but by virtue of never being mounted it will never be accessible
to the user. For example:
# zfs create pool/accounting
# zfs set canmount=off pool/accounting
# zfs set mountpoint=/export/home pool/accounting
# zfs create pool/engineering
# zfs set canmount=off pool/engineering
# zfs set mountpoint=/export/home pool/engineering
# zfs create pool/accounting/bob
# zfs create pool/engineering/anne
# ls /export/home
anne bob
#
In this example, 'anne' and 'bob' are sharing the same inherited
mountpoint, but the administrator can change settings (quota,
reservation, etc) on the logical 'accounting' and 'engineering'
datasets. Chaning this property on for a mounted filesystem will
unmount it and its children which inherit the mountpoint, and then
re-mount children with the new setting in effect. It is expected that
this operation will be rare, as most of the time it will be set when the
filesystem is created.
C. MANPAGE CHANGES
TBD
D. REFERENCES
[1] PSARC 2002/240 ZFS (Zettabyte Filesystem)
[2] http://www.opensolaris.org/jive/thread.jspa?messageID=26531枣
[3] http://www.opensolaris.org/jive/thread.jspa?threadID=3702
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
