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
Hi Eric, Eric Schrock wrote:> ... > > 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.Speaking of confusing names, let''s not overload the word "container." Solaris already has something called Containers to achieve application isolation. A Container is a group of processes. Adding "container: a group of storage entities" would create unnecessary confusion, e.g. "Now create a container" "<typing>zoncfg -z..." "No, the *other* kind of container." Thesaurus.com suggests over 50 synonyms for the word ''container.'' Hopefully one of them will be appropriate for ZFS. -------------------------------------------------------------------------- Jeff VICTOR Sun Microsystems jeff.victor @ sun.com OS Ambassador Sr. Technical Specialist Solaris 10 Zones FAQ: http://www.opensolaris.org/os/community/zones/faq --------------------------------------------------------------------------
On Thu, Aug 10, 2006 at 10:23:20AM -0700, Eric Schrock wrote:> 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.Cool, looks good. Do you plan to implement this using the generic (inheritable) property infrastructure (eg. dsl_prop_set/get()), and just ignore the setting if it is inherited? --matt
Yet another reason it was removed. This proposal specifically does not use the word ''container'', nor will the documentation refer to it as such. I was merely providing background (possibly too much) for why this option was originally implemented and then removed. - Eric On Thu, Aug 10, 2006 at 01:32:40PM -0400, Jeff Victor wrote:> Hi Eric, > > > Eric Schrock wrote: > >... > > > >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. > > Speaking of confusing names, let''s not overload the word "container." > Solaris already has something called Containers to achieve application > isolation. A Container is a group of processes. > > Adding "container: a group of storage entities" would create unnecessary > confusion, e.g. "Now create a container" "<typing>zoncfg -z..." "No, the > *other* kind of container." > > Thesaurus.com suggests over 50 synonyms for the word ''container.'' > Hopefully one of them will be appropriate for ZFS. > > -------------------------------------------------------------------------- > Jeff VICTOR Sun Microsystems jeff.victor @ sun.com > OS Ambassador Sr. Technical Specialist > Solaris 10 Zones FAQ: http://www.opensolaris.org/os/community/zones/faq > ---------------------------------------------------------------------------- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
Right now I''m using the generic property mechanism, but have a special case in dsl_prop_get_all() to ignore searching parents for this particular property. I''m not thrilled about it, but I only see two other options: 1. Do not use the generic infrastructure. This requires much more invasive changes that I''d rather avoid. 2. From the kernel''s perspective have it be inheritable, but then fake up the non-inherited state in libzfs. i.e. if the source is not ZFS_SRC_LOCAL, then pretend like it isn''t set at all. If the current hack is too offensive, moving it into libzfs seems like a reasonable option. - Eric On Thu, Aug 10, 2006 at 10:40:49AM -0700, Matthew Ahrens wrote:> On Thu, Aug 10, 2006 at 10:23:20AM -0700, Eric Schrock wrote: > > 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. > > Cool, looks good. Do you plan to implement this using the generic > (inheritable) property infrastructure (eg. dsl_prop_set/get()), and just > ignore the setting if it is inherited? > > --matt-- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
On Thu, Aug 10, 2006 at 10:44:46AM -0700, Eric Schrock wrote:> Right now I''m using the generic property mechanism, but have a special > case in dsl_prop_get_all() to ignore searching parents for this > particular property. I''m not thrilled about it, but I only see two > other options: > > 1. Do not use the generic infrastructure. This requires much more > invasive changes that I''d rather avoid. > > 2. From the kernel''s perspective have it be inheritable, but then fake > up the non-inherited state in libzfs. i.e. if the source is not > ZFS_SRC_LOCAL, then pretend like it isn''t set at all. > > If the current hack is too offensive, moving it into libzfs seems like a > reasonable option.Yeah, I guess I was suggesting (2), but having a check in dsl_prop code might be better. It would probably be better to base it off some value stored in the zfs_prop_t though, rather than hard-coding "canmount" into dsl_prop.c. --matt
Eric Schrock wrote:> 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.I''m assuming since you don''t use that syntax in your examples that there will be a separate proposal/ARC case for the set at create time.> 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.I assume even though it can''t be inherited it can be set at any level in the filesytem hierarchy and isn''t restricted to the "top" ? > 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 > #This is very cool, it wasn''t obvious to me until I read this that this usage style would be possible. I assume this would be possible even with multiple pools eg. # zfs create acctpool/home # zfs set canmount=off acttpool/home # zfs set mountpoint=/export/home acctpool/home # zfs create engpool/dev/home # zfs create engpool/qa/home # zfs set canmount=off engpool/dev/home # zfs set canmount=off engpool/qa/home # zfs set mountpoint=/export/home engpool/dev/home # zfs set mountpoint=/export/home engpool/qa/home # zfs create acctpool/home/bob # zfs create engpool/dev/home/anne # zfs create engpool/qa/home/alice # ls /export/home anne bob alice Right ? The difference between your example and mine is that in mine you can also have different data replication requirements between the accounting and engineering departments and different quota etc between the dev and qa subgroups of engineering. Very cool stuff, now I actually understand the real need for this! -- Darren J Moffat
On Fri, Aug 11, 2006 at 01:50:05AM +0100, Darren J Moffat wrote:> > I''m assuming since you don''t use that syntax in your examples that > there will be a separate proposal/ARC case for the set at create time.Yes. I have a prototype almost done and will send out a similar proposal, probably tomorrow. I''ll try to schedule the ARC cases so that they can refer to one another where appropriate.> I assume even though it can''t be inherited it can be set at any > level in the filesytem hierarchy and isn''t restricted to the "top" ?Yep. I''ll make that clear in the next draft.> This is very cool, it wasn''t obvious to me until I read this that > this usage style would be possible. I assume this would be possible > even with multiple pools eg. > > # zfs create acctpool/home > # zfs set canmount=off acttpool/home > # zfs set mountpoint=/export/home acctpool/home > > # zfs create engpool/dev/home > # zfs create engpool/qa/home > # zfs set canmount=off engpool/dev/home > # zfs set canmount=off engpool/qa/home > # zfs set mountpoint=/export/home engpool/dev/home > # zfs set mountpoint=/export/home engpool/qa/home > > # zfs create acctpool/home/bob > # zfs create engpool/dev/home/anne > # zfs create engpool/qa/home/alice > # ls /export/home > anne bob alice > > Right ? > > The difference between your example and mine is that in mine > you can also have different data replication requirements between the > accounting and engineering departments and different quota etc between > the dev and qa subgroups of engineering.Yep, this is all possible. Of course once you do this, you have to be more careful that you don''t select overlapping names, since it''s only enforceable at mount time ;-) - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
On Aug 10, 2006, at 13:23, Eric Schrock wrote:> # zfs create pool/accounting/bob > # zfs create pool/engineering/anne > # ls /export/home > anne bob > #Is easy to determine where ''anne'' and ''bob'' are really located? What would the output of (say) ''df'' be? I''m just thinking of the case where you want to trace usage, and find where things are really located. If ''anne'' and ''bob'' were ''lofs'' mounts or simple symlinks then, if you would ever need operate on the ''real'' location, you can script it via parsing the output of ''df'' or ''ls'' (for the lofs mount and symlinks cases, respectively). In the above case, if you have hundreds of entries in /export/home (from dozens of pools), how can you determine which pool each directory is located in?
David Magda wrote:> On Aug 10, 2006, at 13:23, Eric Schrock wrote: > >> # zfs create pool/accounting/bob >> # zfs create pool/engineering/anne >> # ls /export/home >> anne bob >> # > > Is easy to determine where ''anne'' and ''bob'' are really located? What > would the output of (say) ''df'' be?Filesystem size used avail capacity Mountpoint pool/accounting/bob 10g 8g 2g 90% export/home/bob pool/engineering/anne 20g 0 20g 100% /export/home/anne> In the above case, if you have hundreds of entries in /export/home (from > dozens of pools), how can you determine which pool each directory is > located in?The Filesystem name tells you that, in df -k that is the first column, the last column tells you the mountpoint. -- Darren J Moffat