Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
This case was approved in today's meeting. -tim ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
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. Will the "zoned" property also assume a temporary value of "off", when this is used? No. the "zoned" property will be unchanged by temporarily mounting a dataset. Lori ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
Lori Alt schrieb: Thanks for all inputs on this. This mail includes an updated version of the case document. 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. Will the "zoned" property also assume a temporary value of "off", when this is used? - Jörg -- Joerg Barfurth phone: +49 40 23646662 / x2 Software Engineermailto:joerg.barfu...@sun.com Desktop Technology http://blogs.sun.com/joergb/ Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbHhttp://www.sun.com/software/vdi/ ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
I'm happy with the updated proposal. Even though some of the things I asked about are not implemented I understand why and I agree with the rationale. So the case gets my +1 as specified. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
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 moun
Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
On Tue, Apr 13, 2010 at 01:42:14PM -0600, Lori Alt wrote: > > >>>if a dataset is configured with zoned=on, can the dataset be temporarily > >>>mounted in the global zone? > >>Excellent question. I'm going to guess that the correct behavior > >>should be "no". Ed, what do you think the answer should be? > >> > >it'd actually be really nice if the answer was yes, in which case i > >think that this functionality would also address the following bug: > > 6882285 need a mechanism force mounts zfs filesystems > > > > Temporary mounts can be made to work this way. Do we need any > security on this other than (1) permissions to do mounts on this > dataset, and (2) permission to write to the target directory? > Because regular zfs mounts don't allow this, even if the > process/user attempting it has the above permissions. In other > words, should temporary mounts have an implied "force" behavior? > for a user to do this without the temporary mountpoint capability, the user would need the ability to "set" the zoned and mountpoint attributes. so we're basically changing the required delegated zfs authorization from "set" to "mount". from a security perspective i don't think this makes much of a difference since i really don't see any reason why the gz should be delegating ANY zfs authorizations for datasets that contain a zone root filesystem. (although perhaps i'm just not thinking creatively enough.) i think allowing temporary mounts to have a force behavior is ok. it's not like the user is accidentally setting mountpoint, which results in a persistent setting. really, it seems to me this functionality is being designed to support things like BE management, which is exactly the same place that we need force support. so if we don't have force be implicit here, we'll have to design an additional mechanism that allows us to create force temporary mounts. ed ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
if a dataset is configured with zoned=on, can the dataset be temporarily mounted in the global zone? Excellent question. I'm going to guess that the correct behavior should be "no". Ed, what do you think the answer should be? it'd actually be really nice if the answer was yes, in which case i think that this functionality would also address the following bug: 6882285 need a mechanism force mounts zfs filesystems Temporary mounts can be made to work this way. Do we need any security on this other than (1) permissions to do mounts on this dataset, and (2) permission to write to the target directory?Because regular zfs mounts don't allow this, even if the process/user attempting it has the above permissions. In other words, should temporary mounts have an implied "force" behavior? and one more question that just occured to me. today, certain zfs operations require unmounting and remounting filesystems (see 6472202) and zfs does this automatically. presumably temporarily mounted filesystems will work with these operations. (ie, zfs will unmount and remount these filesystems automatically at the same temporary location.) Yes, the file systems will be remounted in the same temporary location. And thanks for pointing this out, because I failed to consider this. Lori ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
On Mon, Apr 12, 2010 at 11:31:40PM -0600, Lori Alt wrote: > Edward Pilatowicz wrote: > >hey lori, > > > >thanks for doing this. i have a few questions. > > > >if i have a zfs dataset (say tank/a) that is mounted via a temporary > >mountpoint at /a, then what will the output of the following command be: > > zfs get mounpoint tank/a > > > >will "zfs unmount -a" unmount temporarily mounted filesystems? > yes > >i assume that a temporarily mounted dataset can be unmounted by any of > >the following commands: > > umount > > zfs unmount > > zfs unmount > > yes > >if a dataset is configured with canmount=off, can the dataset be > >temporarily mounted? > no > >if a dataset is configured with mountpoint=none, can the dataset be > >temporarily mounted? > no. The man page for zfs says "A file system mountpoint property of > none prevents the file system from being mounted." > > But I can see that this one is arguable. It really depends on what > we think the purpose of mountpoint=none is. Is it to prevent > mounting, ever? Or ... what? (Actually, I'm not sure what it IS > good for. Canmount=off has the effect of preventing a dataset from > being mounted). So I'm going to suggest that a mountpoint of none > should NOT prevent a dataset from being temporarily mounted. > agreed. the entire point of this case is to be able to override the mountpoint setting. so supporting temporary mounting of filesystems with mountpoint=none makes sense to me. > >if a dataset is configured with zoned=on, can the dataset be temporarily > >mounted in the global zone? > Excellent question. I'm going to guess that the correct behavior > should be "no". Ed, what do you think the answer should be? > it'd actually be really nice if the answer was yes, in which case i think that this functionality would also address the following bug: 6882285 need a mechanism force mounts zfs filesystems and one more question that just occured to me. today, certain zfs operations require unmounting and remounting filesystems (see 6472202) and zfs does this automatically. presumably temporarily mounted filesystems will work with these operations. (ie, zfs will unmount and remount these filesystems automatically at the same temporary location.) ed ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
On 13/04/2010 13:09, Kyle McDonald wrote: I have to disagree. The name 'legacy' implies that you foresee a day when /etc/vfstab disappears, or at least is no longer used. would you also get rid of the 'mount' command? That's impossible. While 'neat' putting things like 'mount' and 'share' as built-ins to ZFS is really backwards, and non-productuve since they only manage ZFS filesystems. If mount, /etc/vfstab, share, /etc/dfs/dfstab, and sharemgr can manage everything, including ZFS, why as an admin would I also want to spend time learning, or using, or have to remember how to use 'zfs mount', 'zfs set', and 'zfs share' also? What advantages do the ZFS commands get me? For Filesystems types that mount can figure out on it's own, why should a user or admin have to know that this filesystem is ZFS and should use one mount command, while all others use 'mount'? Please move this to zfs-dic...@opensolaris.org. The decision on how ZFS works and the subcommands was made more than 5 years ago and revisiting that is not this ARC case. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
On 4/13/2010 1:41 AM, Lori Alt wrote: > Kyle McDonald wrote: >> On 4/12/2010 3:01 PM, Lori Alt wrote: >> >>> On 04/12/10 11:50 AM, Darren J Moffat wrote: >>> On 12/04/2010 18:38, Tim Haley wrote: > 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. > Does this also allow the following to work without changing to legacy mountpoint: # mount -F zfs tank/a /mnt >>> I was sticking to the notion that legacy mounts work with the "legacy" >>> mountpoint only. So this would not be supported. This was an attempt >>> to be conservative about temporary mount support in an attempt to >>> limit its use to narrow circumstances, where the mechanism and its >>> constraints are well-understood. >>> >>> For example, ZFS legacy mounts can be performed on non-empty >>> directories. ZFS native mounts (and I consider a temporary mount to >>> be a native ZFS mount) cannot be performed on non-empty directories. >>> I didn't want to mix up the code paths between the legacy mount path >>> and the ZFS mount path and I didn't want the two types of mounts to >>> get confused, since they have different constraints. >>> >>> >> I'd really like this to work. >> >> For me currently 'legacy' really means "mounted through /etc/vfstab". I >> prefer if this was even more true, in that any ZFS filesystem could be >> mounted manually wherever you like using this traditional syntax (should >> the user even need to know that a filesystem is ZFS?) with out jumping >> through aditional hoops. >> > > I take your point, but I think "legacy" means more than "mounted > through /etc/vfstab". Also, a change that makes temporary zfs mounts > easier to use and more commonly used isn't necessarily a feature in my > mind. We really don't WANT temporary mounts to be used casually and > commonly. The zfs mount mechanism that already exists should > continue to be the normal and most commonly-used way to mount zfs file > systems. I have to disagree. The name 'legacy' implies that you foresee a day when /etc/vfstab disappears, or at least is no longer used. would you also get rid of the 'mount' command? That's impossible. While 'neat' putting things like 'mount' and 'share' as built-ins to ZFS is really backwards, and non-productuve since they only manage ZFS filesystems. If mount, /etc/vfstab, share, /etc/dfs/dfstab, and sharemgr can manage everything, including ZFS, why as an admin would I also want to spend time learning, or using, or have to remember how to use 'zfs mount', 'zfs set', and 'zfs share' also? What advantages do the ZFS commands get me? For Filesystems types that mount can figure out on it's own, why should a user or admin have to know that this filesystem is ZFS and should use one mount command, while all others use 'mount'? What do I lose by continuing to use the 'legacy' commands? At the moment I can only see things I lose by using the ZFS commands - In addition to the losing the convience of using a single command to manage all filesystems on a level playing field, I lose the ability to control the order in which my filesystems are mounted and shared. ZFS is not the only Filesystem that needs to be mounted automatically at boot time. And I don't see it being the only one anytime soon. CD's/DVD's/BD's at least will be around virtually forever, and many people like me will need to mount (through lofi) those at boot time too. I'm currently forced to use 'legacy' on a few of my ZFS filesystems. They contain many ISO's which /etc/vfstab needs to be able to mount at boot. To do this (since ZFS's mounts aren't integrated with vfstab processing) I need to use 'legacy' mounting and mount the ZFS filesystem first in vfstab. That's fine really. but if I'm going to do those few, why not do them all in /etc/vfstab? I need to do this with more ZFS filesystems also since I want to mount these ISO's as subdirectories of my ZFS filesystems. For this reason I'm considering making all my ZFS filesystems 'legacy' in order to centralize management in one single place for everything. Ditto with sharing things. I need to share all thes ISO mountpoints. I can only do that with 'sharemgr'. In sharemgr I can easily group and manage related shares. If I use ZFS's share options, then all the FS's end up in the 'zfs' sharemanger group, and I no longer can organize them the way I need to work with them. For this reason, and just so that I can manage everything with one tool, I share all my filesystems ZFS or not, with sharemger, and I
Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
As a result of the questions and comments received, I believe that the following changes should be made to the original temporary mount proposal: 1) The temporary mount point should be inherited. That is, if there are datasets tank/a and tank/a/b, the following steps would mount them both at a temporary mount point: # zfs mount -o mountpoint=/altmnt tank/a # zfs mount tank/a/b The following mounted file systems will result: /altmnt /altmnt/b 2) It will be possible to temporarily mount a dataset with "mountpoint=none". However, it will not be possible to temporarily mount a dataset with "canmount=off". I will add clarification to the case document regarding all the other questions that came up (making it clear, for example, that datasets with the 'zoned' property can't be temporarily mounted in the global zone). Lori ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
Kyle McDonald wrote: On 4/12/2010 3:01 PM, Lori Alt wrote: On 04/12/10 11:50 AM, Darren J Moffat wrote: On 12/04/2010 18:38, Tim Haley wrote: 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. Does this also allow the following to work without changing to legacy mountpoint: # mount -F zfs tank/a /mnt I was sticking to the notion that legacy mounts work with the "legacy" mountpoint only. So this would not be supported. This was an attempt to be conservative about temporary mount support in an attempt to limit its use to narrow circumstances, where the mechanism and its constraints are well-understood. For example, ZFS legacy mounts can be performed on non-empty directories. ZFS native mounts (and I consider a temporary mount to be a native ZFS mount) cannot be performed on non-empty directories. I didn't want to mix up the code paths between the legacy mount path and the ZFS mount path and I didn't want the two types of mounts to get confused, since they have different constraints. I'd really like this to work. For me currently 'legacy' really means "mounted through /etc/vfstab". I prefer if this was even more true, in that any ZFS filesystem could be mounted manually wherever you like using this traditional syntax (should the user even need to know that a filesystem is ZFS?) with out jumping through aditional hoops. I take your point, but I think "legacy" means more than "mounted through /etc/vfstab". Also, a change that makes temporary zfs mounts easier to use and more commonly used isn't necessarily a feature in my mind. We really don't WANT temporary mounts to be used casually and commonly. The zfs mount mechanism that already exists should continue to be the normal and most commonly-used way to mount zfs file systems. Temporary mounts really should be used for short-term, focused purposes, like updating a BE other than the active one. That, plus the fact that I still think we want to avoid blurring the line between ZFS mounts and temporary mounts, makes me we should stick with the clear distinction that temporary mounts are NOT legacy mounts and so the legacy mounting mechanism will not be supported. Lori ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
Edward Pilatowicz wrote: hey lori, thanks for doing this. i have a few questions. if i have a zfs dataset (say tank/a) that is mounted via a temporary mountpoint at /a, then what will the output of the following command be: zfs get mounpoint tank/a will "zfs unmount -a" unmount temporarily mounted filesystems? yes i assume that a temporarily mounted dataset can be unmounted by any of the following commands: umount zfs unmount zfs unmount yes if a dataset is configured with canmount=off, can the dataset be temporarily mounted? no if a dataset is configured with mountpoint=none, can the dataset be temporarily mounted? no. The man page for zfs says "A file system mountpoint property of none prevents the file system from being mounted." But I can see that this one is arguable. It really depends on what we think the purpose of mountpoint=none is. Is it to prevent mounting, ever? Or ... what? (Actually, I'm not sure what it IS good for. Canmount=off has the effect of preventing a dataset from being mounted). So I'm going to suggest that a mountpoint of none should NOT prevent a dataset from being temporarily mounted. if a dataset is configured with zoned=on, can the dataset be temporarily mounted in the global zone? Excellent question. I'm going to guess that the correct behavior should be "no". Ed, what do you think the answer should be? Lori ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
On Mon, Apr 12, 2010 at 03:46:14PM -0700, Bart Smaalders wrote: > Personally, I'm of the opinion that / should be a single dataset. I'd be happier with that as the rule than no rule at all. But I'd like to be able to set noatime for all static content, but not necessarily other content. ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
On 04/12/10 13:27, Nicolas Williams wrote: On Mon, Apr 12, 2010 at 11:38:25AM -0600, Tim Haley wrote: 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: The concern I have, and which I expressed off-list, but maybe is sufficiently architetural to mention here, is this: if beadm were to rely on this feature, then beadm would have to know to mount every dataset that makes up the BE being mounted. That seems like a lot to ask of beadm, and if beadm does not implement that, then splitting of / into separate datasets will be harder to pull off. That said, clearly / should not be split along certain lines, such as any that would break pkg hardlink actions. What those lines are is not this case; whether ZFS makes it harder to get allowable / splits to work is. Nico Personally, I'm of the opinion that / should be a single dataset. - Bart -- Bart Smaalders Solaris Kernel Performance bart.smaald...@oracle.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
On Mon, Apr 12, 2010 at 11:38:25AM -0600, Tim Haley wrote: > 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: The concern I have, and which I expressed off-list, but maybe is sufficiently architetural to mention here, is this: if beadm were to rely on this feature, then beadm would have to know to mount every dataset that makes up the BE being mounted. That seems like a lot to ask of beadm, and if beadm does not implement that, then splitting of / into separate datasets will be harder to pull off. That said, clearly / should not be split along certain lines, such as any that would break pkg hardlink actions. What those lines are is not this case; whether ZFS makes it harder to get allowable / splits to work is. Nico -- ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
On 4/12/2010 3:01 PM, Lori Alt wrote: > On 04/12/10 11:50 AM, Darren J Moffat wrote: >> On 12/04/2010 18:38, Tim Haley wrote: >>> 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. >> >> Does this also allow the following to work without changing to legacy >> mountpoint: >> >> # mount -F zfs tank/a /mnt >> > I was sticking to the notion that legacy mounts work with the "legacy" > mountpoint only. So this would not be supported. This was an attempt > to be conservative about temporary mount support in an attempt to > limit its use to narrow circumstances, where the mechanism and its > constraints are well-understood. > > For example, ZFS legacy mounts can be performed on non-empty > directories. ZFS native mounts (and I consider a temporary mount to > be a native ZFS mount) cannot be performed on non-empty directories. > I didn't want to mix up the code paths between the legacy mount path > and the ZFS mount path and I didn't want the two types of mounts to > get confused, since they have different constraints. > I'd really like this to work. For me currently 'legacy' really means "mounted through /etc/vfstab". I prefer if this was even more true, in that any ZFS filesystem could be mounted manually wherever you like using this traditional syntax (should the user even need to know that a filesystem is ZFS?) with out jumping through aditional hoops. The addition of the temporary mount functionality (assuming I understand it,) seems to open the door to allowing this. It seems a shame not to take advantage of it. -Kyle > Lori > > ___ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
hey lori, thanks for doing this. i have a few questions. if i have a zfs dataset (say tank/a) that is mounted via a temporary mountpoint at /a, then what will the output of the following command be: zfs get mounpoint tank/a will "zfs unmount -a" unmount temporarily mounted filesystems? i assume that a temporarily mounted dataset can be unmounted by any of the following commands: umount zfs unmount zfs unmount if a dataset is configured with canmount=off, can the dataset be temporarily mounted? if a dataset is configured with mountpoint=none, can the dataset be temporarily mounted? if a dataset is configured with zoned=on, can the dataset be temporarily mounted in the global zone? ed On Mon, Apr 12, 2010 at 11:38:25AM -0600, Tim Haley wrote: > 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. > ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
On 04/12/10 11:50 AM, Darren J Moffat wrote: On 12/04/2010 18:38, Tim Haley wrote: 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. Does this also allow the following to work without changing to legacy mountpoint: # mount -F zfs tank/a /mnt I was sticking to the notion that legacy mounts work with the "legacy" mountpoint only. So this would not be supported. This was an attempt to be conservative about temporary mount support in an attempt to limit its use to narrow circumstances, where the mechanism and its constraints are well-understood. For example, ZFS legacy mounts can be performed on non-empty directories. ZFS native mounts (and I consider a temporary mount to be a native ZFS mount) cannot be performed on non-empty directories. I didn't want to mix up the code paths between the legacy mount path and the ZFS mount path and I didn't want the two types of mounts to get confused, since they have different constraints. Lori ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
On Apr 12, 2010, at 10:38 AM, Tim Haley wrote: ... 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. Will it be possible to override the requirement that the mount point directory be empty by supplying -O as part of the command line? For consistency with other mount commands, I think such an override should be allowed. -- Glenn ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010]
On 12/04/2010 18:38, Tim Haley wrote: 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. Does this also allow the following to work without changing to legacy mountpoint: # mount -F zfs tank/a /mnt -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
