From tim.haley@oracle.com Mon Apr 12 10:40:06 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3CHe6O0022499 for ; Mon, 12 Apr 2010 10:40:06 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3CHe30m000633; Mon, 12 Apr 2010 11:40:06 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0R0052XYETIS00@nwk-avmta-2.sfbay.sun.com>; Mon, 12 Apr 2010 10:40:05 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0R001N3YERZH90@nwk-avmta-2.sfbay.sun.com>; Mon, 12 Apr 2010 10:40:04 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3CHe2lW021560; Mon, 12 Apr 2010 17:40:02 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3CGFpEU011083; Mon, 12 Apr 2010 17:39:55 +0000 (GMT) Received: from abhmt009.oracle.com by acsmt354.oracle.com with ESMTP id 154079141271093906; Mon, 12 Apr 2010 10:38:26 -0700 Received: from [172.20.25.27] (/10.85.25.27) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Apr 2010 10:38:25 -0700 Date: Mon, 12 Apr 2010 11:38:25 -0600 From: Tim Haley Subject: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010] To: PSARC-ext@sun.com, ZFS Team , one-pager-list@sac.sfbay.sun.com, one-pager-log@sac.sfbay.sun.com, sac-bar@sac.sfbay.sun.com Message-id: <4BC35A91.2060508@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BC35AF2.0028:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 5099 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=" option will fail. 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 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.2. Man Page Changes: *** zfs.1m.orig Fri Apr 9 16:10:09 2010 --- zfs.1m.modified Fri Apr 9 16:13:21 2010 *************** Temporary Mount Point Properties When a file system is mounted, either through mount(1M) for legacy mounts or the zfs mount command for normal file sys- tems, its mount options are set according to its properties. The correlation between properties and mount options is as follows: PROPERTY MOUNT OPTION devices devices/nodevices exec exec/noexec 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 *************** *** 17,22 **** 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. --- 18,26 ---- 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 From Darren.Moffat@oracle.com Mon Apr 12 10:50:54 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3CHos3M022578 for ; Mon, 12 Apr 2010 10:50:54 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3CHorSG016080; Mon, 12 Apr 2010 10:50:54 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0R00C0JYWTQL00@brm-avmta-1.central.sun.com>; Mon, 12 Apr 2010 11:50:53 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0R003BMYWSWA50@brm-avmta-1.central.sun.com>; Mon, 12 Apr 2010 11:50:53 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3CHoqil002056; Mon, 12 Apr 2010 17:50:52 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3BKX2E4012132; Mon, 12 Apr 2010 17:50:51 +0000 (GMT) Received: from abhmt001.oracle.com by acsmt355.oracle.com with ESMTP id 154113531271094630; Mon, 12 Apr 2010 10:50:30 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Apr 2010 10:50:29 -0700 Date: Mon, 12 Apr 2010 18:50:27 +0100 From: Darren J Moffat Subject: Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010] In-reply-to: <4BC35A91.2060508@oracle.com> To: Tim Haley Cc: PSARC-ext@sun.com, ZFS Team Message-id: <4BC35D63.80308@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BC35D7B.013F:SCFMA4539814,ss=1,fgs=0 References: <4BC35A91.2060508@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 632 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 From glenn.skinner@covad.net Mon Apr 12 11:46:12 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3CIkBFu023813 for ; Mon, 12 Apr 2010 11:46:11 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3CIkAFe010748 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 12 Apr 2010 13:46:11 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0S0090J1GYFA00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 12 Apr 2010 11:46:10 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0S008491GXBK20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 12 Apr 2010 11:46:09 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3CIjDi1016789 for ; Mon, 12 Apr 2010 18:46:09 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay42i.sun.com with ESMTP id BT-MMP-4048624; Mon, 12 Apr 2010 18:46:09 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-84441963; Mon, 12 Apr 2010 18:46:08 +0000 (Z) Received: from mail156c8.megamailservers.com ([209.235.129.66] [209.235.129.66]) by relay4i.sun.com with ESMTP id BT-MMP-29637534; Mon, 12 Apr 2010 18:46:08 +0000 (Z) Received: from [192.168.1.106] (h-64-105-36-23.snvacaid.static.covad.net [64.105.36.23]) by mail156c8.megamailservers.com (8.13.6/8.13.1) with ESMTP id o3CIk2pD001698; Mon, 12 Apr 2010 14:46:03 -0400 Date: Mon, 12 Apr 2010 11:46:00 -0700 From: Glenn Skinner Subject: Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010] In-reply-to: <4BC35A91.2060508@oracle.com> To: Tim Haley Cc: PSARC-ext@sun.com, ZFS Team Message-id: <7DCFCA91-A44B-4AA4-830E-155C76839E75@covad.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.936) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-POP-User: gcskinner@covad.net X-Antispam: No, score=0.0/5.0, scanned in 0.188sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BC35A91.2060508@oracle.com> Status: RO Content-Length: 848 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 From lori.alt@oracle.com Mon Apr 12 12:06:34 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3CJ6Y2N024832 for ; Mon, 12 Apr 2010 12:06:34 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3CJ6Xjn009376; Mon, 12 Apr 2010 12:06:34 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0S00K092EXBN00@brm-avmta-1.central.sun.com>; Mon, 12 Apr 2010 13:06:33 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0S0034G2EXWS90@brm-avmta-1.central.sun.com>; Mon, 12 Apr 2010 13:06:33 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3CJ6WVQ025412; Mon, 12 Apr 2010 19:06:33 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3CHs4vU015451; Mon, 12 Apr 2010 19:06:28 +0000 (GMT) Received: from abhmt013.oracle.com by acsmt354.oracle.com with ESMTP id 168055141271099113; Mon, 12 Apr 2010 12:05:13 -0700 Received: from [172.20.25.227] (/10.85.25.227) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Apr 2010 12:02:30 -0700 Date: Mon, 12 Apr 2010 13:01:13 -0600 From: Lori Alt Subject: Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010] In-reply-to: <4BC35D63.80308@Oracle.COM> To: Darren J Moffat Cc: Tim Haley , PSARC-ext@sun.com, ZFS Team Message-id: <4BC36DF9.7040602@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BC36F35.00D3:SCFMA4539814,ss=1,fgs=0 References: <4BC35A91.2060508@oracle.com> <4BC35D63.80308@Oracle.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 Status: RO Content-Length: 1397 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 From edward.pilatowicz@oracle.com Mon Apr 12 13:07:37 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3CK7bFP026512 for ; Mon, 12 Apr 2010 13:07:37 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3CK7aWB014644; Mon, 12 Apr 2010 13:07:37 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0S0030558OK800@brm-avmta-1.central.sun.com>; Mon, 12 Apr 2010 14:07:36 -0600 (MDT) Received: from jurassic.Eng.Sun.COM ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0S003J258OW2D0@brm-avmta-1.central.sun.com>; Mon, 12 Apr 2010 14:07:36 -0600 (MDT) Received: from jurassic.Eng.Sun.COM (localhost [127.0.0.1]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o3CK7aBI333918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Apr 2010 13:07:36 -0700 (PDT) Received: (from edp@localhost) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4/Submit) id o3CK7aQe333917; Mon, 12 Apr 2010 13:07:36 -0700 (PDT) Date: Mon, 12 Apr 2010 13:07:36 -0700 From: Edward Pilatowicz Subject: Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010] In-reply-to: <4BC35A91.2060508@oracle.com> To: Tim Haley Cc: PSARC-ext@sun.com, ZFS Team , one-pager-list@sac.sfbay.sun.com, one-pager-log@sac.sfbay.sun.com, sac-bar@sac.sfbay.sun.com Message-id: <20100412200735.GD311332@jurassic.Eng.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4BC35A91.2060508@oracle.com> X-Authentication-warning: jurassic.Eng.Sun.COM: edp set sender to edward.pilatowicz@oracle.com using -f User-Agent: Mutt/1.5.20 (2009-06-14) Status: RO Content-Length: 1049 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. > From kmcdonald@egenera.com Mon Apr 12 13:12:27 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3CKCRHm026589 for ; Mon, 12 Apr 2010 13:12:27 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3CKCRA0053881 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 12 Apr 2010 14:12:27 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0S004055GR2I00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 12 Apr 2010 14:12:27 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0S003NP5GQW6E0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 12 Apr 2010 14:12:26 -0600 (MDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3CK81P9010978 for ; Mon, 12 Apr 2010 20:12:25 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay41i.sun.com with ESMTP id BT-MMP-4107322; Mon, 12 Apr 2010 20:12:23 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-84381717; Mon, 12 Apr 2010 20:12:23 +0000 (Z) Received: from webaccess.egenera.com ([63.139.209.15] [63.139.209.15]) by relay4i.sun.com with ESMTP id BT-MMP-24657305; Mon, 12 Apr 2010 20:12:23 +0000 (Z) Received: from webaccess.corp.egenera.com ([10.10.2.15]) by webaccess.egenera.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Apr 2010 16:12:22 -0400 Received: from [10.50.0.182] ([10.50.0.182]) by webaccess.corp.egenera.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Apr 2010 16:12:19 -0400 Date: Mon, 12 Apr 2010 16:12:13 -0400 From: Kyle McDonald Subject: Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010] In-reply-to: <4BC36DF9.7040602@oracle.com> To: Lori Alt Cc: Darren J Moffat , PSARC-ext@sun.com, ZFS Team Message-id: <4BC37E9D.7060409@egenera.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Enigmail-Version: 1.0.1 X-Antispam: No, score=0.0/5.0, scanned in 0.067sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BC35A91.2060508@oracle.com> <4BC35D63.80308@Oracle.COM> <4BC36DF9.7040602@oracle.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 X-OriginalArrivalTime: 12 Apr 2010 20:12:22.0264 (UTC) FILETIME=[75EB5F80:01CADA7C] Status: RO Content-Length: 2104 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 From Nicolas.Williams@oracle.com Mon Apr 12 13:27:52 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3CKRped026687 for ; Mon, 12 Apr 2010 13:27:51 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3CKRpYc016405; Mon, 12 Apr 2010 15:27:51 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0S00F0166FN100@nwk-avmta-2.sfbay.sun.com>; Mon, 12 Apr 2010 13:27:51 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0S0085466EBMF0@nwk-avmta-2.sfbay.sun.com>; Mon, 12 Apr 2010 13:27:50 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3CKRoPe004125; Mon, 12 Apr 2010 20:27:50 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3CJCvgJ024434; Mon, 12 Apr 2010 20:27:47 +0000 (GMT) Received: from abhmt012.oracle.com by acsmt355.oracle.com with ESMTP id 168337691271104048; Mon, 12 Apr 2010 13:27:28 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Apr 2010 13:27:10 -0700 Date: Mon, 12 Apr 2010 15:27:05 -0500 From: Nicolas Williams Subject: Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010] In-reply-to: <4BC35A91.2060508@oracle.com> To: Tim Haley Cc: PSARC-ext@sun.com, ZFS Team , one-pager-list@sac.sfbay.sun.com, one-pager-log@sac.sfbay.sun.com, sac-bar@sac.sfbay.sun.com Message-id: <20100412202704.GZ10389@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BC38245.015A:SCFMA4539814,ss=1,fgs=0 References: <4BC35A91.2060508@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 872 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 -- From lori.alt@oracle.com Mon Apr 12 22:33:05 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3D5X56U005746 for ; Mon, 12 Apr 2010 22:33:05 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3D5X3BC041232; Mon, 12 Apr 2010 23:33:04 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0S00J07VEANG00@brm-avmta-1.central.sun.com>; Mon, 12 Apr 2010 23:32:34 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0S00CRDVE95P30@brm-avmta-1.central.sun.com>; Mon, 12 Apr 2010 23:32:33 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3D5WWFD013248; Tue, 13 Apr 2010 05:32:33 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3D5WVo4005775; Tue, 13 Apr 2010 05:32:31 +0000 (GMT) Received: from abhmt019.oracle.com by acsmt354.oracle.com with ESMTP id 155458061271136708; Mon, 12 Apr 2010 22:31:48 -0700 Received: from Lori-Alts-Computer.local (/129.150.220.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Apr 2010 22:31:47 -0700 Date: Mon, 12 Apr 2010 23:31:40 -0600 From: Lori Alt Subject: Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010] In-reply-to: <20100412200735.GD311332@jurassic.Eng.Sun.COM> To: Edward Pilatowicz Cc: Tim Haley , PSARC-ext@sun.com, ZFS Team , one-pager-list@sac.sfbay.sun.com, one-pager-log@sac.sfbay.sun.com, sac-bar@sac.sfbay.sun.com Message-id: <4BC401BC.1060508@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BC401F0.0090:SCFMA4539814,ss=1,fgs=0 References: <4BC35A91.2060508@oracle.com> <20100412200735.GD311332@jurassic.Eng.Sun.COM> User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) Status: RO Content-Length: 1490 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 From lori.alt@oracle.com Mon Apr 12 22:43:01 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3D5h1OQ005841 for ; Mon, 12 Apr 2010 22:43:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3D5h087008668; Tue, 13 Apr 2010 00:43:01 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0S0070RVVO2U00@nwk-avmta-2.sfbay.sun.com>; Mon, 12 Apr 2010 22:43:00 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0S000ZWVVN7R30@nwk-avmta-2.sfbay.sun.com>; Mon, 12 Apr 2010 22:43:00 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3D5gxvh021240; Tue, 13 Apr 2010 05:42:59 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3CJ6ANR023044; Tue, 13 Apr 2010 05:42:57 +0000 (GMT) Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 155475801271137273; Mon, 12 Apr 2010 22:41:13 -0700 Received: from Lori-Alts-Computer.local (/129.150.220.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Apr 2010 22:41:12 -0700 Date: Mon, 12 Apr 2010 23:41:12 -0600 From: Lori Alt Subject: Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010] In-reply-to: <4BC37E9D.7060409@egenera.com> To: Kyle McDonald Cc: Darren J Moffat , PSARC-ext@sun.com, ZFS Team Message-id: <4BC403F8.9060509@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BC40461.0118:SCFMA4539814,ss=1,fgs=0 References: <4BC35A91.2060508@oracle.com> <4BC35D63.80308@Oracle.COM> <4BC36DF9.7040602@oracle.com> <4BC37E9D.7060409@egenera.com> User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) Status: RO Content-Length: 2756 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 From lori.alt@oracle.com Mon Apr 12 23:28:55 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3D6Ssjj006709 for ; Mon, 12 Apr 2010 23:28:55 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3D6SpFt014491; Tue, 13 Apr 2010 00:28:53 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0S00909Y04WB00@nwk-avmta-2.sfbay.sun.com>; Mon, 12 Apr 2010 23:28:52 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0S0009BY047J70@nwk-avmta-2.sfbay.sun.com>; Mon, 12 Apr 2010 23:28:52 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3D6SqmZ026223; Tue, 13 Apr 2010 06:28:52 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3D3ps8q031088; Tue, 13 Apr 2010 06:28:49 +0000 (GMT) Received: from abhmt015.oracle.com by acsmt353.oracle.com with ESMTP id 169495221271140025; Mon, 12 Apr 2010 23:27:05 -0700 Received: from Lori-Alts-Computer.local (/129.150.220.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Apr 2010 23:27:05 -0700 Date: Tue, 13 Apr 2010 00:27:04 -0600 From: Lori Alt Subject: Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010] In-reply-to: <4BC403F8.9060509@oracle.com> To: Kyle McDonald Cc: Darren J Moffat , PSARC-ext@sun.com, ZFS Team Message-id: <4BC40EB8.8050701@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BC40F21.0172:SCFMA4539814,ss=1,fgs=0 References: <4BC35A91.2060508@oracle.com> <4BC35D63.80308@Oracle.COM> <4BC36DF9.7040602@oracle.com> <4BC37E9D.7060409@egenera.com> <4BC403F8.9060509@oracle.com> User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) Status: RO Content-Length: 846 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 From kmcdonald@egenera.com Tue Apr 13 05:11:30 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3DCBU42029934 for ; Tue, 13 Apr 2010 05:11:30 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3DCBT3G005746 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 13 Apr 2010 05:11:30 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0T00E07DV5W000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Apr 2010 06:11:29 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0T00F9LDV5D3C0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Apr 2010 06:11:29 -0600 (MDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3DBhXFw021448 for ; Tue, 13 Apr 2010 12:11:28 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay15i.sun.com with ESMTP id BT-MMP-4100928; Tue, 13 Apr 2010 12:11:28 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-405366; Tue, 13 Apr 2010 12:11:28 +0000 (Z) Received: from webaccess.egenera.com ([63.139.209.15] [63.139.209.15]) by relay1i.sun.com with ESMTP id BT-MMP-23368884; Tue, 13 Apr 2010 12:11:27 +0000 (Z) Received: from webaccess.corp.egenera.com ([10.10.2.15]) by webaccess.egenera.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Apr 2010 08:10:02 -0400 Received: from [10.50.0.178] ([10.50.0.178]) by webaccess.corp.egenera.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Apr 2010 08:10:00 -0400 Date: Tue, 13 Apr 2010 08:09:52 -0400 From: Kyle McDonald Subject: Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010] In-reply-to: <4BC403F8.9060509@oracle.com> To: Lori Alt Cc: Darren J Moffat , PSARC-ext@sun.com, ZFS Team Message-id: <4BC45F10.7050607@egenera.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Enigmail-Version: 1.0.1 X-Antispam: No, score=-0.7/5.0, scanned in 0.109sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BC35A91.2060508@oracle.com> <4BC35D63.80308@Oracle.COM> <4BC36DF9.7040602@oracle.com> <4BC37E9D.7060409@egenera.com> <4BC403F8.9060509@oracle.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 X-OriginalArrivalTime: 13 Apr 2010 12:10:01.0594 (UTC) FILETIME=[3E5955A0:01CADB02] Status: RO Content-Length: 6288 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'll never use ZFS's share command. I guess I just don't understand, why you'd want to not take the chance to make a well known UNIX command like mount "just work" (least surprise) for ZFS filesystems like it does for everything else. Heck if you did you could also (since /etc/vfstab processing runs first, and it runs using mount) eliminate the need for setting mountpoint=legacy, since anythign I configure in /etc/vfstab would be mounted at boot using mount and would "just work". I love ZFS. I think all the great new things it's adding to Solaris are awesome. But I don't understand the urge to build into it parallels to all the existing UNIX commands that everyone knows, instead of making those commands just workk seamlessly with ZFS. Especially when there are no obvious user visible benefits, and in fact several user visible detriments to doing so. -Kyle > 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 > From Darren.Moffat@oracle.com Tue Apr 13 07:14:12 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3DEEBMb001641 for ; Tue, 13 Apr 2010 07:14:11 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3DEEA1e007759; Tue, 13 Apr 2010 09:14:11 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0T00A4FJJMX200@nwk-avmta-1.sfbay.Sun.COM>; Tue, 13 Apr 2010 07:14:10 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0T00HMLJJK3TA0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 13 Apr 2010 07:14:09 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3DEE8vw013909; Tue, 13 Apr 2010 14:14:08 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3BMn0Ct021854; Tue, 13 Apr 2010 14:14:05 +0000 (GMT) Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 156630011271168035; Tue, 13 Apr 2010 07:13:55 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Apr 2010 07:13:53 -0700 Date: Tue, 13 Apr 2010 15:13:49 +0100 From: Darren J Moffat Subject: Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010] In-reply-to: <4BC45F10.7050607@egenera.com> To: Kyle McDonald Cc: Lori Alt , PSARC-ext@sun.com, ZFS Team Message-id: <4BC47C1D.9030605@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BC47C2D.0163:SCFMA4539814,ss=1,fgs=0 References: <4BC35A91.2060508@oracle.com> <4BC35D63.80308@Oracle.COM> <4BC36DF9.7040602@oracle.com> <4BC37E9D.7060409@egenera.com> <4BC403F8.9060509@oracle.com> <4BC45F10.7050607@egenera.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 1098 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-dicuss@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 From edward.pilatowicz@oracle.com Tue Apr 13 12:14:19 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3DJEJ82007672 for ; Tue, 13 Apr 2010 12:14:19 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3DJEImo002280; Tue, 13 Apr 2010 14:14:18 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0T00H0BXFUAC00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 13 Apr 2010 12:14:18 -0700 (PDT) Received: from jurassic.Eng.Sun.COM ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0T00ATNXFTJMC0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 13 Apr 2010 12:14:17 -0700 (PDT) Received: from jurassic.Eng.Sun.COM (localhost [127.0.0.1]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o3DJEGnP453126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Apr 2010 12:14:16 -0700 (PDT) Received: (from edp@localhost) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4/Submit) id o3DJEGmY453125; Tue, 13 Apr 2010 12:14:16 -0700 (PDT) Date: Tue, 13 Apr 2010 12:14:16 -0700 From: Edward Pilatowicz Subject: Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010] In-reply-to: <4BC401BC.1060508@oracle.com> To: Lori Alt Cc: Tim Haley , PSARC-ext@sun.com, ZFS Team , one-pager-list@sac.sfbay.sun.com, one-pager-log@sac.sfbay.sun.com, sac-bar@sac.sfbay.sun.com Message-id: <20100413191416.GA445930@jurassic.Eng.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4BC35A91.2060508@oracle.com> <20100412200735.GD311332@jurassic.Eng.Sun.COM> <4BC401BC.1060508@oracle.com> X-Authentication-warning: jurassic.Eng.Sun.COM: edp set sender to edward.pilatowicz@oracle.com using -f User-Agent: Mutt/1.5.20 (2009-06-14) Status: RO Content-Length: 2288 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 From lori.alt@oracle.com Tue Apr 13 12:45:25 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3DJjPsW011183 for ; Tue, 13 Apr 2010 12:45:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3DJjOTr029470; Tue, 13 Apr 2010 12:45:24 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0T00D09YVOP300@brm-avmta-1.central.sun.com>; Tue, 13 Apr 2010 13:45:24 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0T00HZKYVNHGB0@brm-avmta-1.central.sun.com>; Tue, 13 Apr 2010 13:45:23 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3DJjEX9018834; Tue, 13 Apr 2010 19:45:15 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3DJH9oS005020; Tue, 13 Apr 2010 19:45:12 +0000 (GMT) Received: from abhmt013.oracle.com by acsmt354.oracle.com with ESMTP id 171945801271187813; Tue, 13 Apr 2010 12:43:33 -0700 Received: from [172.20.25.227] (/10.85.25.227) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Apr 2010 12:43:32 -0700 Date: Tue, 13 Apr 2010 13:42:14 -0600 From: Lori Alt Subject: Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010] In-reply-to: <20100413191416.GA445930@jurassic.Eng.Sun.COM> To: Edward Pilatowicz Cc: Tim Haley , PSARC-ext@sun.com, ZFS Team , one-pager-list@sac.sfbay.sun.com, one-pager-log@sac.sfbay.sun.com, sac-bar@sac.sfbay.sun.com Message-id: <4BC4C916.400@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BC4C9CA.0054:SCFMA4539814,ss=1,fgs=0 References: <4BC35A91.2060508@oracle.com> <20100412200735.GD311332@jurassic.Eng.Sun.COM> <4BC401BC.1060508@oracle.com> <20100413191416.GA445930@jurassic.Eng.Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 Status: RO Content-Length: 1378 >>> 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 From edward.pilatowicz@oracle.com Tue Apr 13 15:01:47 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3DM1lAI025956 for ; Tue, 13 Apr 2010 15:01:47 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3DM1hHs011659; Tue, 13 Apr 2010 15:01:47 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0U0040356YV500@brm-avmta-1.central.sun.com>; Tue, 13 Apr 2010 16:01:46 -0600 (MDT) Received: from jurassic.Eng.Sun.COM ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0U00KE756X6V70@brm-avmta-1.central.sun.com>; Tue, 13 Apr 2010 16:01:46 -0600 (MDT) Received: from jurassic.Eng.Sun.COM (localhost [127.0.0.1]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o3DM1jIM468304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Apr 2010 15:01:45 -0700 (PDT) Received: (from edp@localhost) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4/Submit) id o3DM1jFX468303; Tue, 13 Apr 2010 15:01:45 -0700 (PDT) Date: Tue, 13 Apr 2010 15:01:44 -0700 From: Edward Pilatowicz Subject: Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010] In-reply-to: <4BC4C916.400@oracle.com> To: Lori Alt Cc: Tim Haley , PSARC-ext@sun.com, ZFS Team , one-pager-list@sac.sfbay.sun.com, one-pager-log@sac.sfbay.sun.com, sac-bar@sac.sfbay.sun.com Message-id: <20100413220144.GC445930@jurassic.Eng.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4BC35A91.2060508@oracle.com> <20100412200735.GD311332@jurassic.Eng.Sun.COM> <4BC401BC.1060508@oracle.com> <20100413191416.GA445930@jurassic.Eng.Sun.COM> <4BC4C916.400@oracle.com> X-Authentication-warning: jurassic.Eng.Sun.COM: edp set sender to edward.pilatowicz@oracle.com using -f User-Agent: Mutt/1.5.20 (2009-06-14) Status: RO Content-Length: 1892 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 From lori.alt@oracle.com Thu Apr 15 11:01:24 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3FI1OBE011977 for ; Thu, 15 Apr 2010 11:01:24 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3FI1Hm9022348; Thu, 15 Apr 2010 13:01:23 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0X00K3PJEAR800@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Apr 2010 11:01:22 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0X00598JE9MXD0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Apr 2010 11:01:21 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3FI1Ggg016307; Thu, 15 Apr 2010 18:01:16 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3FH1bIf004277; Thu, 15 Apr 2010 18:01:13 +0000 (GMT) Received: from abhmt010.oracle.com by acsmt354.oracle.com with ESMTP id 179064151271354454; Thu, 15 Apr 2010 11:00:54 -0700 Received: from [172.20.25.227] (/10.85.25.227) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Apr 2010 11:00:53 -0700 Date: Thu, 15 Apr 2010 11:59:33 -0600 From: Lori Alt Subject: Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010] In-reply-to: <20100413220144.GC445930@jurassic.Eng.Sun.COM> To: PSARC-ext@sun.com Cc: Tim Haley , ZFS Team , one-pager-list@sac.sfbay.sun.com, one-pager-log@sac.sfbay.sun.com, sac-bar@sac.sfbay.sun.com Message-id: <4BC75405.5050401@oracle.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_WORgXG4Upt499N6na8t1sg)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BC7546B.00B3:SCFMA4539814,ss=1,fgs=0 References: <4BC35A91.2060508@oracle.com> <20100412200735.GD311332@jurassic.Eng.Sun.COM> <4BC401BC.1060508@oracle.com> <20100413191416.GA445930@jurassic.Eng.Sun.COM> <4BC4C916.400@oracle.com> <20100413220144.GC445930@jurassic.Eng.Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 Status: RO Content-Length: 10863 This is a multi-part message in MIME format. --Boundary_(ID_WORgXG4Upt499N6na8t1sg) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT 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 --Boundary_(ID_WORgXG4Upt499N6na8t1sg) Content-type: text/plain; name=temporary_mounts.v2 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=temporary_mounts.v2 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=" 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=" 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 --Boundary_(ID_WORgXG4Upt499N6na8t1sg)-- From Darren.Moffat@oracle.com Fri Apr 16 01:40:19 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3G8eJcJ029174 for ; Fri, 16 Apr 2010 01:40:19 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3G8eHlg006459; Fri, 16 Apr 2010 01:40:18 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0Y0090PO36ER00@brm-avmta-1.central.sun.com>; Fri, 16 Apr 2010 02:40:18 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0Y0054EO35N720@brm-avmta-1.central.sun.com>; Fri, 16 Apr 2010 02:40:17 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3G8eG4C022333; Fri, 16 Apr 2010 08:40:17 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3G6guCK013408; Fri, 16 Apr 2010 08:40:15 +0000 (GMT) Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 181199251271407212; Fri, 16 Apr 2010 01:40:12 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Apr 2010 01:40:12 -0700 Date: Fri, 16 Apr 2010 09:40:09 +0100 From: Darren J Moffat Subject: Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010] In-reply-to: <4BC75405.5050401@oracle.com> To: Lori Alt Cc: PSARC-ext@sun.com, Tim Haley , ZFS Team Message-id: <4BC82269.6080606@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BC82270.0029:SCFMA4539814,ss=1,fgs=0 References: <4BC35A91.2060508@oracle.com> <20100412200735.GD311332@jurassic.Eng.Sun.COM> <4BC401BC.1060508@oracle.com> <20100413191416.GA445930@jurassic.Eng.Sun.COM> <4BC4C916.400@oracle.com> <20100413220144.GC445930@jurassic.Eng.Sun.COM> <4BC75405.5050401@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 212 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 From Joerg.Barfurth@sun.com Fri Apr 16 09:06:57 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3GG6vWZ016326 for ; Fri, 16 Apr 2010 09:06:57 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3GG6ulQ046818; Fri, 16 Apr 2010 10:06:56 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0Z00D2D8RKM500@nwk-avmta-1.sfbay.Sun.COM>; Fri, 16 Apr 2010 09:06:56 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0Z00B5S8RH6ID0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 16 Apr 2010 09:06:54 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3GG6rhG008036; Fri, 16 Apr 2010 16:06:53 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L0Z005008LO4000@fe-emea-09.sun.com>; Fri, 16 Apr 2010 17:06:50 +0100 (BST) Received: from [10.16.46.243] ([unknown] [10.16.46.243]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L0Z00GCE8R70AA0@fe-emea-09.sun.com>; Fri, 16 Apr 2010 17:06:43 +0100 (BST) Date: Fri, 16 Apr 2010 18:06:43 +0200 From: Joerg Barfurth Subject: Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010] In-reply-to: <4BC75405.5050401@oracle.com> Sender: Joerg.Barfurth@sun.com To: Lori Alt Cc: PSARC-ext@sun.com, ZFS Team , sac-bar@sac.sfbay.sun.com Message-id: <4BC88B13.1010903@sun.com> Organization: Sun Microsystem - Desktop MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <4BC35A91.2060508@oracle.com> <20100412200735.GD311332@jurassic.Eng.Sun.COM> <4BC401BC.1060508@oracle.com> <20100413191416.GA445930@jurassic.Eng.Sun.COM> <4BC4C916.400@oracle.com> <20100413220144.GC445930@jurassic.Eng.Sun.COM> <4BC75405.5050401@oracle.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 794 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 / x66662 Software Engineer mailto:joerg.barfurth@sun.com Desktop Technology http://blogs.sun.com/joergb/ Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/vdi/ From lori.alt@oracle.com Fri Apr 16 09:25:08 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3GGP7do016445 for ; Fri, 16 Apr 2010 09:25:08 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3GGP5xW061129; Fri, 16 Apr 2010 10:25:06 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0Z00H0N9LTGT00@nwk-avmta-2.sfbay.sun.com>; Fri, 16 Apr 2010 09:25:05 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0Z00EFX9LSHZ20@nwk-avmta-2.sfbay.sun.com>; Fri, 16 Apr 2010 09:25:04 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3GGP3dW028507; Fri, 16 Apr 2010 16:25:03 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3GGP1GY029616; Fri, 16 Apr 2010 16:25:01 +0000 (GMT) Received: from abhmt012.oracle.com by acsmt355.oracle.com with ESMTP id 182531241271435006; Fri, 16 Apr 2010 09:23:26 -0700 Received: from [172.20.25.227] (/10.85.25.227) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Apr 2010 09:23:25 -0700 Date: Fri, 16 Apr 2010 10:22:04 -0600 From: Lori Alt Subject: Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010] In-reply-to: <4BC88B13.1010903@sun.com> To: Joerg Barfurth Cc: PSARC-ext@sun.com, ZFS Team , sac-bar@sac.sfbay.sun.com Message-id: <4BC88EAC.7090403@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BC88F5F.0077:SCFMA4539814,ss=1,fgs=0 References: <4BC35A91.2060508@oracle.com> <20100412200735.GD311332@jurassic.Eng.Sun.COM> <4BC401BC.1060508@oracle.com> <20100413191416.GA445930@jurassic.Eng.Sun.COM> <4BC4C916.400@oracle.com> <20100413220144.GC445930@jurassic.Eng.Sun.COM> <4BC75405.5050401@oracle.com> <4BC88B13.1010903@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 Status: RO Content-Length: 486 >> 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 From tim.haley@oracle.com Wed Apr 21 13:11:23 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3LKBNN7020301 for ; Wed, 21 Apr 2010 13:11:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3LKBMku009117; Wed, 21 Apr 2010 13:11:23 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1800L17TEY5W00@brm-avmta-1.central.sun.com>; Wed, 21 Apr 2010 14:11:22 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L18004DXTEY7CD0@brm-avmta-1.central.sun.com>; Wed, 21 Apr 2010 14:11:22 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3LKBLjb016164; Wed, 21 Apr 2010 20:11:21 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3LJqD6g001813; Wed, 21 Apr 2010 20:11:20 +0000 (GMT) Received: from abhmt013.oracle.com by acsmt353.oracle.com with ESMTP id 196776481271880652; Wed, 21 Apr 2010 13:10:52 -0700 Received: from Giles.local (/10.7.250.184) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Apr 2010 13:10:52 -0700 Date: Wed, 21 Apr 2010 14:10:51 -0600 From: Tim Haley Subject: Re: Temporary ZFS mounts [PSARC/2010/126 FastTrack timeout 04/19/2010] In-reply-to: <4BC35A91.2060508@oracle.com> To: PSARC-ext@sun.com, ZFS Team Message-id: <4BCF5BCB.4020103@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BCF5BE9.0068:SCFMA4539814,ss=1,fgs=0 References: <4BC35A91.2060508@oracle.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 Status: RO Content-Length: 50 This case was approved in today's meeting. -tim