Thanks for all inputs on this. This mail includes an updated version of
the case
document. Here is the summary of the issues that were raised and their
current resolution:
1. Inheritability of temporary mountpoints.
Temporary mountpoints will remain NOT inheritable, as specified in the
original
version of this proposal. In general, inheritability of mountpoints is
a good thing
(it's the 'ZFS way'), but there are several reasons for temporary
mountpoints not to
be inheritable:
* Temporary mounts are not intended to be used routinely. They are
intended
for specific, narrow cases, such as the manipulation of BEs by beadm.
* Code that mounts a dataset temporarily needs to be capable of working
down
the hierarchy and mounting each dataset individually anyway (since the
'zfs mount' command doesn't mount descendant file systems). This code
already knows it's using temporary mounts and can specify the temporary
mount point property at each level (and indeed, this makes each of
those
mounts consistent with each other: each one needs a temporary mount
point).
* Since temporary mounts have the effect of overriding the 'zoned'
property,
it's best that each temporary mount be requested explicitly.
I can argue this further, but won't here. If anyone really wants to
continue to
argue this point, please contact me offline to discuss it. We can
always bring it
back into this forum if warranted.
2. Ability to temporarily mount zfs file systems using mount(1M)
In the interest of making a clear distinction between legacy mounts and
ZFS mounts, this is still prohibited. Legacy mounts have different
constraints and behavior than ZFS mounts. Temporary ZFS mounts
are still ZFS mounts, not legacy mounts. For example, temporary ZFS
mounts cannot be performed on non-empty directories, and legacy
mounts can.
Like the inheritability issue, this is a conservative choice, reflecting
the fact that temporary mounts are not intended for routine use, but
only for specific, temporary conditions (such as the interval during
which a BE is mounted at an alternate location for maintenance
purposes).
3. Interaction between the "zoned" attribute and temporary mounts points
The zones teams has recommended that temporary mounts override
the current constraint on mounting datasets with the "zoned" attribute
set. I have modified the proposal to adopt this recommendation.
4. Interaction with "mountpoint=none"
The current zfs(1M) man page says that "mountpoint=none" prevents
mounting. With this proposal, "mountpoint=none" will allow
temporary mounts. However, "canmount=off" will continue
to prevent all mounts, including temporary mounts
- Lori
I am sponsoring the following fast-track for Lori Alt. It introduces
the ability to mount a ZFS dataset at a mountpoint other than the
current value of the dataset's persistent mountpoint property. The case
requests micro/patch binding.
Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI
This information is Copyright (c) 2010, Oracle and/or its affiliates.
All rights reserved.
1. Introduction
1.1. Project/Component Working Name:
Temporary ZFS mounts
1.2. Name of Document Author/Supplier:
Author: Lori Alt
1.3 Date of This Document:
12 April, 2010
4. Technical Description
File systems such as UFS support the ability to mount a file system
at a mountpoint other than the file system's persistent mountpoint
(which, in the case of UFS, is the mountpoint specified in the
file systems's /etc/vfstab entry). This ability is especially useful
when maintaining boot environments (that is, root file systems), whose
persistent mountpoint is always "/", but cannot actually be mounted at that
location for maintenance purposes, because the root is already occupied.
There are other circumstances when a temporary mount is useful also.
Non-legacy ZFS mounts do not currently support temporary mounts. The
only way to mount a dataset at a temporary location is to modify the
dataset's "mounpoint" property, and then set it back to the original
value after the temporary mount is no longer needed. This is cumbersome,
and can lead to systems left in an incorrect state if the system goes
down before the the mountpoint can be set back to its correct, permanent
value.
4.1. Proposal
A new temporary mount property will be defined for the "zfs mount" command.
Currently, the -o option to "zfs mount" can be used to set temporary
values for the following properties: devices, exec, readonly, setuid,
and xattr. It will now be possible to assign a temporary "mountpoint"
property. The file system will be mounted at the temporary mountpoint
and the persistent "mountpoint" property for the dataset will not change.
The temporary mountpoint must already exist and must be an empty directory.
If the dataset is already mounted (in any way, by zfs mount or legacy mount
or another temporary mount), executing "zfs mount" with the
"-o mountpoint=<mntpt>" option will fail.
4.1.1 Non-Inheritability of Temporary Mountpoints
Temporary mountpoints are not inherited. If a hierarchy of datasets are
to be mounted at a temporary location, each dataset must be explicitly
mounted. So if these datasets exist:
tank/a
tank/a/b
The following commands would be necessary to mount them temporarily
at /alt :
zfs mount -o mountpoint=/alt tank/a
zfs mount -o mountpoint=/alt/b tank/a/b
In order to avoid confusion between temporary and regular ZFS mounts, and to
prevent the creation of intermediate mountpoints (which could cause failures
later), a regular ZFS mount of a dataset will not be permitted if (1) the
dataset inherits its persistent mount point and (2) any dataset higher
up in the inheritance hierachy is temporarily mounted. So, for example,
if we have datasets:
tank/a
tank/a/b
tank/a/b/c
and all of those datasets have the default "inherited" source for their
mountpoint, and tank/a has been temporarily mounted at /mnt, then eitther
of these command
zfs mount tank/a/b
zfs mount tank/a/b/c
will fail, with an error message indicating that a dataset higher up in
the hierachy is temporarily mounted.
4.1.2 Delegation Considerations
The capability to do temporary mounts can be delegated to non-privileged
users with the "zfs allow" command, but the mount will only succeed if the
user has write privileges on the mountpoint.
4.1.3 Interaction of Temporary Mounts and the "zoned" Attribute
Regular ZFS mounts are not permitted on datasets whose "zoned" attribute
has a value of "on". Temporary mounts of such datasets will be permitted,
however. This provides a way for tools such as beadm(1M) to manage
zoned datasets without having to turn off their "zoned" attribute (which
might not be appropriate). The permissions required for this action
can be set in a way that prevents security violations.
4.1.4 Interaction with "canmount" and "mountpoint" Properties
If a dataset's "canmount" property is set to "off", temporary mounts
are prohibited. If the dataset's "mountpoint" property is set to
"none" or any other value other than "legacy", temporary mounts are
permitted.
4.2. Man Page Changes:
*** zfs.man.txt Thu Apr 15 11:01:17 2010
--- zfs.man.new Thu Apr 15 11:10:33 2010
***************
*** 313,321 ****
A file system mountpoint property of none prevents the file
! system from being mounted.
If needed, ZFS file systems can also be managed with tradi-
--- 313,326 ----
+ A file system can be mounted temporarily at a location other
+ than the file systems's persistent mount point by specifying
+ the "-o mountpoint=<value>" option to the 'zfs mount' command.
+ This is only permitted for file systems with non-legacy
+ mount points.
A file system mountpoint property of none prevents the file
! system from being mounted, except by temporary mount.
***************
*** 371,379 ****
After a dataset is delegated to a non-global zone, the zoned
! property is automatically set. A zoned file system cannot be
! mounted in the global zone, since the zone administrator
! might have to set the mount point to an unacceptable value.
*** 371,379 ****
After a dataset is delegated to a non-global zone, the zoned
! property is automatically set. A zoned file system can only
! be mounted in the global zone by use of a temporary mountpoint
! property (see Temporary Mount Point Properties).
*** 1460,1477 ****
readonly ro/rw
setuid setuid/nosetuid
xattr xattr/noxattr
In addition, these options can be set on a per-mount basis
using the -o option, without affecting the property that is
stored on disk. The values specified on the command line
override the values stored in the dataset. The -nosuid
option is an alias for nodevices,nosetuid. These properties
! are reported as "temporary" by the zfs get command. If the
! properties are changed while the dataset is mounted, the new
! setting overrides any temporary settings.
--- 1465,1485 ----
readonly ro/rw
setuid setuid/nosetuid
xattr xattr/noxattr
+ mountpoint mountpoint
In addition, these options can be set on a per-mount basis
using the -o option, without affecting the property that is
stored on disk. The values specified on the command line
override the values stored in the dataset. The -nosuid
option is an alias for nodevices,nosetuid. These properties
! are reported as "temporary" by the zfs get command. For
! properties other than "mountpoint", if the properties are
! changed while the dataset is mounted, the new setting overrides
! any temporary settings. The "mountpoint" property cannot be
! changed while a temporary mountpoint property is in effect
! (that is, while the dataset is mounted at a temporary location).
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
_______________________________________________
opensolaris-arc mailing list
[email protected]
