From sacadmin Mon Jan 22 14:54:03 2007 Received: from cyber.eng.sun.com (cyber.SFBay.Sun.COM [129.146.228.109]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0MMs3Zf001722; Mon, 22 Jan 2007 14:54:03 -0800 (PST) Received: from cyber.eng.sun.com (localhost [127.0.0.1]) by cyber.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0MMrjPD025286; Mon, 22 Jan 2007 14:53:45 -0800 (PST) Received: (from ahrens@localhost) by cyber.eng.sun.com (8.13.8+Sun/8.13.8/Submit) id l0MMri8w025269; Mon, 22 Jan 2007 14:53:44 -0800 (PST) Date: Mon, 22 Jan 2007 14:53:44 -0800 (PST) From: Matthew Ahrens Message-Id: <200701222253.l0MMri8w025269@cyber.eng.sun.com> To: PSARC@sac.sfbay.sun.com Cc: chris.kirby@sun.com Subject: zfs list -d [PSARC/2007/050 Timeout: 02/01/2007] Status: RO Content-Length: 2557 Subject: PSARC FastTrack [02/01/2007]: zfs list -d Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2007 Sun Microsystems, Inc. 1. Introduction 1.1. Project/Component Working Name: zfs list -d 1.2. Name of Document Author/Supplier: Author: Chris Kirby 1.3 Date of This Document: 22 January, 2007 4. Technical Description This case adds a new flag to zfs(1m). The release binding is patch/micro. SUMMARY: This proposal is to add a "-d" option to the "zfs list" command in order to accept path names in addition to filesystem, volume, and snapshot names. This is CR 6260523. PROBLEM: It would be useful to have a utility to map a ZFS path name to a ZFS dataset name. The original request was to allow Subversion's post-commit hook to create a snapshot of the new repository contents. This requires path name to dataset name translation. The zfs list command is the natural place for this. PROPOSED SOLUTION: The proposed solution is as follows: 1) Add a new "-d" option to zfs list. Command line arguments are then interpreted as path names, either absolute or relative. 2) Allow zfs list (without -d) to take absolute path names as well as the filesystem/volume/snapshot names that it currently accepts. 3) Update the zfs man page as shown below. ISSUES: Should we just force users to specify -d for path names, even if they are providing absolute paths? System Administration Commands zfs(1M) [...] SYNOPSIS [...] zfs list [-rH] [-o prop[,prop] ]... [ -t type[,type]]... [ -s prop [-s prop]]... [ -S prop [-S prop]]... < [filesystem|volume|snapshot] ... > [filesystem|volume|snapshot|path] ... > > zfs list -d [-rH] [-o prop[,prop] ]... [ -t type[,type]]... > [ -s prop [-s prop]]... [ -S prop [-S prop]]... > [directory|file ...] [...] zfs list [-rH] [-o prop[,prop] ]... [ -t type[,type]]... [ -s prop [-s prop]]... [ -S prop [-S prop]]... < [filesystem|volume|snapshot] ... > [filesystem|volume|snapshot|path] ... > > zfs list -d [-rH] [-o prop[,prop] ]... [ -t type[,type]]... > [ -s prop [-s prop]]... [ -S prop [-S prop]]... > [directory|file ...] [...] 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack From sacadmin Tue Jan 23 03:01:19 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NB1IcE014080 for ; Tue, 23 Jan 2007 03:01:18 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0NB1HFs000745 for ; Tue, 23 Jan 2007 03:01:17 -0800 (PST) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0NB1BvW000105 for ; Tue, 23 Jan 2007 11:01:11 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCB00901IJ2MT00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC@sac.sfbay.sun.com; Tue, 23 Jan 2007 11:01:11 +0000 (GMT) Received: from [192.168.73.102] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCB00604ILY4S10@d1-emea-09.sun.com>; Tue, 23 Jan 2007 11:01:11 +0000 (GMT) Date: Tue, 23 Jan 2007 11:01:10 +0000 From: Darren J Moffat Subject: Re: zfs list -d [PSARC/2007/050 Timeout: 02/01/2007] In-reply-to: <200701222253.l0MMri8w025269@cyber.eng.sun.com> Sender: Darren.Moffat@Sun.COM To: Matthew Ahrens Cc: PSARC@sac.sfbay.sun.com, chris.kirby@Sun.COM Message-id: <45B5EAF6.1090504@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200701222253.l0MMri8w025269@cyber.eng.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 1906 Matthew Ahrens wrote: > This proposal is to add a "-d" option to the "zfs list" > command in order to accept path names in addition to > filesystem, volume, and snapshot names. This is CR 6260523. Why -d ? -d suggests delete. I had to think really hard to work out that -d could mean directory. I'd personally prefer -p for 'path' - which is consistent with some other tools. Are non directories allowed here, eg if I specify the full path to a file does this work ? What if I specify the full path of the device that is a ZVOL eg: $ zfs list -d /dev/zvol/dsk/local/oraidx > It would be useful to have a utility to map a ZFS > path name to a ZFS dataset name. The original request > was to allow Subversion's post-commit hook to create > a snapshot of the new repository contents. This requires > path name to dataset name translation. The zfs list > command is the natural place for this. It would also be very useful as Mercurial extension so that you can 'hg clone' using ZFS underneath. > PROPOSED SOLUTION: > > The proposed solution is as follows: > > 1) Add a new "-d" option to zfs list. Command line arguments > are then interpreted as path names, either absolute or > relative. > > 2) Allow zfs list (without -d) to take absolute path names > as well as the filesystem/volume/snapshot names that it > currently accepts. > > 3) Update the zfs man page as shown below. > > ISSUES: > Should we just force users to specify -d for path names, > even if they are providing absolute paths? For consistency yes I think you probably should, but then usability when the path name is identical to the dataset name but with a leading '/' suggests this should be allowed. So I vote with usability. -- Darren J Moffat From sacadmin Tue Jan 23 06:31:59 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NEVxee018868 for ; Tue, 23 Jan 2007 06:31:59 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0NEVw4J005152 for ; Tue, 23 Jan 2007 06:31:58 -0800 (PST) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0NEVwZj014853 for ; Tue, 23 Jan 2007 07:31:58 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCB00301RK0AR00@mail-amer.sun.com> (original mail from chris.kirby@sun.com) for PSARC@sac.sfbay.sun.com; Tue, 23 Jan 2007 07:31:58 -0700 (MST) Received: from [192.168.1.101] ([129.150.34.18]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCB00M01SD84U10@mail-amer.sun.com>; Tue, 23 Jan 2007 07:31:57 -0700 (MST) Date: Tue, 23 Jan 2007 08:31:56 -0600 From: Chris Kirby Subject: Re: zfs list -d [PSARC/2007/050 Timeout: 02/01/2007] In-reply-to: <45B5EAF6.1090504@Sun.COM> Sender: Christopher.Kirby@sun.com To: Darren J Moffat Cc: Matthew Ahrens , PSARC@sac.sfbay.sun.com Message-id: <45B61C5C.9080502@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200701222253.l0MMri8w025269@cyber.eng.sun.com> <45B5EAF6.1090504@Sun.COM> User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) Status: RO Content-Length: 2402 Darren J Moffat wrote: > Matthew Ahrens wrote: > >> This proposal is to add a "-d" option to the "zfs list" >> command in order to accept path names in addition to >> filesystem, volume, and snapshot names. This is CR 6260523. > > > > Why -d ? -d suggests delete. I had to think really hard to work out > that -d could mean directory. > > I'd personally prefer -p for 'path' - which is consistent with some > other tools. -p makes sense, although it's used by "zfs get" to request a parseable output format. We also considered -n (for "name"), but that generally means don't do anything. > > Are non directories allowed here, eg if I specify the full path to > a file does this work ? Yes, any fs object may be specified. > > What if I specify the full path of the device that is a ZVOL eg: > $ zfs list -d /dev/zvol/dsk/local/oraidx At the moment we don't do what df does when given a block dev. For your example, we'd find that path living in the root fs and report on root. > >> It would be useful to have a utility to map a ZFS >> path name to a ZFS dataset name. The original request >> was to allow Subversion's post-commit hook to create >> a snapshot of the new repository contents. This requires >> path name to dataset name translation. The zfs list >> command is the natural place for this. > > > It would also be very useful as Mercurial extension so that you can 'hg > clone' using ZFS underneath. > >> PROPOSED SOLUTION: >> >> The proposed solution is as follows: >> >> 1) Add a new "-d" option to zfs list. Command line arguments >> are then interpreted as path names, either absolute or >> relative. >> >> 2) Allow zfs list (without -d) to take absolute path names >> as well as the filesystem/volume/snapshot names that it >> currently accepts. >> >> 3) Update the zfs man page as shown below. >> >> ISSUES: >> Should we just force users to specify -d for path names, >> even if they are providing absolute paths? > > > For consistency yes I think you probably should, but then usability when > the path name is identical to the dataset name but with a leading '/' > suggests this should be allowed. So I vote with usability. Cool, one vote for usability, thanks Darren. -Chris From sacadmin Tue Jan 23 06:45:40 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NEjd1o019088 for ; Tue, 23 Jan 2007 06:45:40 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0NEjam9025864 for ; Tue, 23 Jan 2007 06:45:36 -0800 (PST) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0NEjU7o004110 for ; Tue, 23 Jan 2007 14:45:30 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCB00701SZ27H00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC@sac.sfbay.sun.com; Tue, 23 Jan 2007 14:45:30 +0000 (GMT) Received: from [192.168.73.102] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCB006U6SZS4T10@d1-emea-09.sun.com>; Tue, 23 Jan 2007 14:45:29 +0000 (GMT) Date: Tue, 23 Jan 2007 14:45:28 +0000 From: Darren J Moffat Subject: Re: zfs list -d [PSARC/2007/050 Timeout: 02/01/2007] In-reply-to: <45B61C5C.9080502@sun.com> Sender: Darren.Moffat@Sun.COM To: Chris Kirby Cc: Matthew Ahrens , PSARC@sac.sfbay.sun.com Message-id: <45B61F88.1020902@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200701222253.l0MMri8w025269@cyber.eng.sun.com> <45B5EAF6.1090504@Sun.COM> <45B61C5C.9080502@sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 1394 Chris Kirby wrote: > Darren J Moffat wrote: >> Matthew Ahrens wrote: >> >>> This proposal is to add a "-d" option to the "zfs list" >>> command in order to accept path names in addition to >>> filesystem, volume, and snapshot names. This is CR 6260523. >> >> >> >> Why -d ? -d suggests delete. I had to think really hard to work out >> that -d could mean directory. >> >> I'd personally prefer -p for 'path' - which is consistent with some >> other tools. > > > -p makes sense, although it's used by "zfs get" to > request a parseable output format. We also considered > -n (for "name"), but that generally means don't do anything. okay -d it is then since overloading -p or -n would be worse. >> Are non directories allowed here, eg if I specify the full path to >> a file does this work ? > > Yes, any fs object may be specified. > > >> >> What if I specify the full path of the device that is a ZVOL eg: >> $ zfs list -d /dev/zvol/dsk/local/oraidx > > > At the moment we don't do what df does when given a block dev. > For your example, we'd find that path living in the root fs > and report on root. That is going to be very confusing. I think it would be better to not support this at all for ZVOLs than report that the filesystem is root. However it might be nice to see what zfs-discuss@opensolaris.org things of this. -- Darren J Moffat From sacadmin Tue Jan 23 09:49:05 2007 Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NHn5Oi025515 for ; Tue, 23 Jan 2007 09:49:05 -0800 (PST) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l0NHn4P09832; Tue, 23 Jan 2007 09:49:04 -0800 (PST) Message-ID: <45B64A90.8080307@sun.com> Date: Tue, 23 Jan 2007 09:49:04 -0800 From: Scott Rotondo User-Agent: Mail/News 1.5.0.4 (X11/20060718) MIME-Version: 1.0 To: PSARC@sac.sfbay.sun.com CC: Matthew Ahrens , chris.kirby@sun.com Subject: Re: zfs list -d [PSARC/2007/050 Timeout: 02/01/2007] References: <200701222253.l0MMri8w025269@cyber.eng.sun.com> <45B5EAF6.1090504@Sun.COM> In-Reply-To: <45B5EAF6.1090504@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1606 > This proposal is to add a "-d" option to the "zfs list" > command in order to accept path names in addition to > filesystem, volume, and snapshot names. This is CR 6260523. > ... > PROPOSED SOLUTION: > > The proposed solution is as follows: > > 1) Add a new "-d" option to zfs list. Command line arguments > are then interpreted as path names, either absolute or > relative. > > 2) Allow zfs list (without -d) to take absolute path names > as well as the filesystem/volume/snapshot names that it > currently accepts. > > 3) Update the zfs man page as shown below. > > ISSUES: > Should we just force users to specify -d for path names, > even if they are providing absolute paths? Correct me if I'm wrong, but isn't this the first situation where a zfs subcommand uses an option to control the interpretation of one of the operands? As you said above, you can automatically distinguish filesystems, volumes, snapshots, and even absolute pathnames. So it appears that -d is only needed to handle relative pathnames. My suggestion would be to require relative pathnames to explicitly include the leading ./ or ../ and retain the feature that operand type is determined automatically. This small restriction on relative pathnames seems like a minor burden in return for a simpler conceptual model of how operands are interpreted. [That's a long-winded version of the pro-usability stance.] If you accept the reasoning above, you don't need the new -d option at all. Scott From sacadmin Tue Jan 23 09:56:28 2007 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NHuSbZ026427 for ; Tue, 23 Jan 2007 09:56:28 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l0NHu1CD010227; Tue, 23 Jan 2007 11:56:01 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l0NHu1IK010226; Tue, 23 Jan 2007 11:56:01 -0600 (CST) Date: Tue, 23 Jan 2007 11:56:01 -0600 From: Nicolas Williams To: Scott Rotondo Cc: PSARC@sac.sfbay.sun.com, Matthew Ahrens , chris.kirby@sun.com Subject: Re: zfs list -d [PSARC/2007/050 Timeout: 02/01/2007] Message-ID: <20070123175600.GF9523@binky.Central.Sun.COM> References: <200701222253.l0MMri8w025269@cyber.eng.sun.com> <45B5EAF6.1090504@Sun.COM> <45B64A90.8080307@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45B64A90.8080307@sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1060 On Tue, Jan 23, 2007 at 09:49:04AM -0800, Scott Rotondo wrote: > Correct me if I'm wrong, but isn't this the first situation where a zfs > subcommand uses an option to control the interpretation of one of the > operands? As you said above, you can automatically distinguish > filesystems, volumes, snapshots, and even absolute pathnames. > > So it appears that -d is only needed to handle relative pathnames. My > suggestion would be to require relative pathnames to explicitly include > the leading ./ or ../ and retain the feature that operand type is > determined automatically. This small restriction on relative pathnames > seems like a minor burden in return for a simpler conceptual model of > how operands are interpreted. [That's a long-winded version of the > pro-usability stance.] > > If you accept the reasoning above, you don't need the new -d option at all. Alternatively provide a sub-command to map paths to fs/snapshot names and another to do the reverse (actually, the reverse can be done with zfs get mountpoint ...). Nico -- From sacadmin Tue Jan 23 11:23:19 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NJNJKs001650 for ; Tue, 23 Jan 2007 11:23:19 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0NJNIjv026946 for ; Tue, 23 Jan 2007 11:23:19 -0800 (PST) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0NJNInF005344 for ; Tue, 23 Jan 2007 12:23:18 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCC00G015D8JQ00@mail-amer.sun.com> (original mail from chris.kirby@sun.com) for PSARC@sac.sfbay.sun.com; Tue, 23 Jan 2007 12:23:18 -0700 (MST) Received: from [10.1.170.19] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCC007KK5UTR7R9@mail-amer.sun.com>; Tue, 23 Jan 2007 12:23:18 -0700 (MST) Date: Tue, 23 Jan 2007 13:23:17 -0600 From: Chris Kirby Subject: Re: zfs list -d [PSARC/2007/050 Timeout: 02/01/2007] In-reply-to: <20070123175600.GF9523@binky.Central.Sun.COM> Sender: Christopher.Kirby@sun.com To: Nicolas Williams Cc: Scott Rotondo , PSARC@sac.sfbay.sun.com, Matthew Ahrens Message-id: <45B660A5.3030901@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200701222253.l0MMri8w025269@cyber.eng.sun.com> <45B5EAF6.1090504@Sun.COM> <45B64A90.8080307@sun.com> <20070123175600.GF9523@binky.Central.Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20040610 Status: RO Content-Length: 1587 Nicolas Williams wrote: >On Tue, Jan 23, 2007 at 09:49:04AM -0800, Scott Rotondo wrote: > > >>Correct me if I'm wrong, but isn't this the first situation where a zfs >>subcommand uses an option to control the interpretation of one of the >>operands? As you said above, you can automatically distinguish >>filesystems, volumes, snapshots, and even absolute pathnames. >> >>So it appears that -d is only needed to handle relative pathnames. My >>suggestion would be to require relative pathnames to explicitly include >>the leading ./ or ../ and retain the feature that operand type is >>determined automatically. This small restriction on relative pathnames >>seems like a minor burden in return for a simpler conceptual model of >>how operands are interpreted. [That's a long-winded version of the >>pro-usability stance.] >> >>If you accept the reasoning above, you don't need the new -d option at all. >> >> > >Alternatively provide a sub-command to map paths to fs/snapshot names >and another to do the reverse (actually, the reverse can be done with >zfs get mountpoint ...). > > That's a reasonable alternative, but since we're really looking for this functionality in zfs list, I'm not sure I want to add all of the extra code/docs to add a new sub-command that a user would then have to backtick onto zfs list. I propose that I implement Scott's solution. I'd prefer not to have either a new option or require ./, but given that we need to allow the user some method to avoid ambiguity in the name space, I'd rather require the ./ on relative paths. -Chris From sacadmin Tue Jan 23 11:29:24 2007 Received: from dm-holland-01.uk.sun.com (dm-holland-01.UK.Sun.COM [129.156.101.192]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NJTNfA002212 for ; Tue, 23 Jan 2007 11:29:24 -0800 (PST) Received: from vaticaan.holland.sun.com (vaticaan.Holland.Sun.COM [129.159.211.1]) by dm-holland-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0NJTHHn021264; Tue, 23 Jan 2007 19:29:17 GMT Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.holland.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0NJTHSs003390; Tue, 23 Jan 2007 20:29:17 +0100 (MET) Message-Id: <200701231929.l0NJTHSs003390@vaticaan.holland.sun.com> From: Casper.Dik@sun.com To: Chris Kirby cc: Nicolas Williams , Scott Rotondo , PSARC@sac.sfbay.sun.com, Matthew Ahrens Subject: Re: zfs list -d [PSARC/2007/050 Timeout: 02/01/2007] In-Reply-To: <45B660A5.3030901@sun.com> References: <200701222253.l0MMri8w025269@cyber.eng.sun.com> <45B5EAF6.1090504@Sun.COM> <45B64A90.8080307@sun.com> <20070123175600.GF9523@binky.Central.Sun.COM> <45B660A5.3030901@sun.com> Date: Tue, 23 Jan 2007 20:29:17 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 490 >I propose that I implement Scott's solution. I'd prefer >not to have either a new option or require ./, but given >that we need to allow the user some method to avoid >ambiguity in the name space, I'd rather require the ./ >on relative paths. The program should be able to disambiguate most things, right? Just look in "/dev/*dsk" and if it isn't there the try to open it as a file? The in-use checking will prevent mishaps and naming a file c0t0d0s0 is kinda strange anyway. Casper From sacadmin Tue Jan 23 11:58:52 2007 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NJwpp4003541 for ; Tue, 23 Jan 2007 11:58:51 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l0NJwQZf010985; Tue, 23 Jan 2007 13:58:26 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l0NJwQN3010984; Tue, 23 Jan 2007 13:58:26 -0600 (CST) Date: Tue, 23 Jan 2007 13:58:26 -0600 From: Nicolas Williams To: Chris Kirby Cc: Scott Rotondo , PSARC@sac.sfbay.sun.com, Matthew Ahrens Subject: Re: zfs list -d [PSARC/2007/050 Timeout: 02/01/2007] Message-ID: <20070123195825.GL9523@binky.Central.Sun.COM> References: <200701222253.l0MMri8w025269@cyber.eng.sun.com> <45B5EAF6.1090504@Sun.COM> <45B64A90.8080307@sun.com> <20070123175600.GF9523@binky.Central.Sun.COM> <45B660A5.3030901@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45B660A5.3030901@sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1512 On Tue, Jan 23, 2007 at 01:23:17PM -0600, Chris Kirby wrote: > Nicolas Williams wrote: > >Alternatively provide a sub-command to map paths to fs/snapshot names > >and another to do the reverse (actually, the reverse can be done with > >zfs get mountpoint ...). > > > That's a reasonable alternative, but since we're really > looking for this functionality in zfs list, I'm not sure > I want to add all of the extra code/docs to add a new > sub-command that a user would then have to backtick onto > zfs list. Having had to write a shell function to provide a path-to-name ZFS lookup I think one would be very useful, even if zfs list -d is useful too. Also, wouldn't this -d option be useful in other sub-commands? Another argument for what you and Scott propose: > I propose that I implement Scott's solution. I'd prefer > not to have either a new option or require ./, but given > that we need to allow the user some method to avoid > ambiguity in the name space, I'd rather require the ./ > on relative paths. Yes, particularly given that one might like to use paths instead of filesystem/snapshot/volume names in other zfs sub-commands. Fortunately pool names must begin with a letter. Hmmm, how is that checked? Because some Unicode characters can look like a period but are distinct from it... Or does zpool simply check for letters in the US-ASCII repertoire? I think it would find to limit pool names to US-ASCII, but note that the same cannot be done for filesystem/snapshot names. Nico -- From sacadmin Tue Jan 23 12:03:45 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NK3jbV003583 for ; Tue, 23 Jan 2007 12:03:45 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0NK3jXI026989 for ; Tue, 23 Jan 2007 12:03:45 -0800 (PST) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0NK3iGl014195 for ; Tue, 23 Jan 2007 13:03:44 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCC00D017D34W00@mail-amer.sun.com> (original mail from chris.kirby@sun.com) for PSARC@sac.sfbay.sun.com; Tue, 23 Jan 2007 13:03:44 -0700 (MST) Received: from [10.1.170.19] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCC006QN7Q5YRV0@mail-amer.sun.com>; Tue, 23 Jan 2007 13:03:42 -0700 (MST) Date: Tue, 23 Jan 2007 14:03:41 -0600 From: Chris Kirby Subject: Re: zfs list -d [PSARC/2007/050 Timeout: 02/01/2007] In-reply-to: <200701231929.l0NJTHSs003390@vaticaan.holland.sun.com> Sender: Christopher.Kirby@sun.com To: Casper.Dik@sun.com Cc: Nicolas Williams , Scott Rotondo , PSARC@sac.sfbay.sun.com, Matthew Ahrens Message-id: <45B66A1D.1080501@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200701222253.l0MMri8w025269@cyber.eng.sun.com> <45B5EAF6.1090504@Sun.COM> <45B64A90.8080307@sun.com> <20070123175600.GF9523@binky.Central.Sun.COM> <45B660A5.3030901@sun.com> <200701231929.l0NJTHSs003390@vaticaan.holland.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20040610 Status: RO Content-Length: 1605 Casper.Dik@Sun.COM wrote: >>I propose that I implement Scott's solution. I'd prefer >>not to have either a new option or require ./, but given >>that we need to allow the user some method to avoid >>ambiguity in the name space, I'd rather require the ./ >>on relative paths. >> > >The program should be able to disambiguate most things, right? > >Just look in "/dev/*dsk" and if it isn't there the try to open >it as a file? The in-use checking will prevent mishaps and naming a file >c0t0d0s0 is kinda strange anyway. > The currently-allowed args to zfs list (fs/volume/snapshot name) won't be found in /dev/*dsk. But I do walk mnttab and check for a device number match. Here's an example of the ambiguity that I'm worried about: Two ZFS filesystems, fs1 and fs2. Both are mounted using ZFS legacy-style mounts, but the admin fat-fingered the commands, and fs1 is mounted at /fs2 and fs2 is mounted at /fs1. So now we have both a dataset named fs1 and a subdir named fs1 in the root directory. From /, if the user asks for "zfs list fs1", which one do we choose? We could state that dataset names take precedence over path names to preserve current semantics, but if they really wanted /fs1, they would have to specify /fs1 or ./fs1, i.e. use something more specific to differentiate between the two. I think Scott was just proposing that we make that mandatory so that once the user gets the cmd syntax right, they'll get the results they want. Using this new functionality probably implies that there has been a visit to the man page, where we can clearly state the requirement. -Chris From sacadmin Tue Jan 23 12:08:57 2007 Received: from dm-holland-02.uk.sun.com (dm-holland-02.UK.Sun.COM [129.156.101.225]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NK8uQA003644 for ; Tue, 23 Jan 2007 12:08:56 -0800 (PST) Received: from vaticaan.holland.sun.com (vaticaan.Holland.Sun.COM [129.159.213.1]) by dm-holland-02.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0NK8oAp022675; Tue, 23 Jan 2007 20:08:50 GMT Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.holland.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0NK8ocr006938; Tue, 23 Jan 2007 21:08:50 +0100 (MET) Message-Id: <200701232008.l0NK8ocr006938@vaticaan.holland.sun.com> From: Casper.Dik@sun.com To: Chris Kirby cc: Nicolas Williams , Scott Rotondo , PSARC@sac.sfbay.sun.com, Matthew Ahrens Subject: Re: zfs list -d [PSARC/2007/050 Timeout: 02/01/2007] In-Reply-To: <45B66A1D.1080501@sun.com> References: <200701222253.l0MMri8w025269@cyber.eng.sun.com> <45B5EAF6.1090504@Sun.COM> <45B64A90.8080307@sun.com> <20070123175600.GF9523@binky.Central.Sun.COM> <45B660A5.3030901@sun.com> <200701231929.l0NJTHSs003390@vaticaan.holland.sun.com> <45B66A1D.1080501@sun.com> Date: Tue, 23 Jan 2007 21:08:50 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 558 >So now we have both a dataset named fs1 and a subdir named >fs1 in the root directory. From /, if the user asks for >"zfs list fs1", which one do we choose? We could state that >dataset names take precedence over path names to preserve >current semantics, but if they really wanted /fs1, they >would have to specify /fs1 or ./fs1, i.e. use something more >specific to differentiate between the two. Well, the software can detect ambiguity so why not make it report that and print the possible interpretations and how the user can disambiguate? Casper From sacadmin Tue Jan 23 12:34:16 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NKYG2j004068 for ; Tue, 23 Jan 2007 12:34:16 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0NKYFww012093 for ; Tue, 23 Jan 2007 12:34:15 -0800 (PST) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0NKYFIO010379 for ; Tue, 23 Jan 2007 13:34:15 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCC00J018XW5200@mail-amer.sun.com> (original mail from chris.kirby@sun.com) for PSARC@sac.sfbay.sun.com; Tue, 23 Jan 2007 13:34:15 -0700 (MST) Received: from [10.1.170.19] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCC000BE9528DS8@mail-amer.sun.com>; Tue, 23 Jan 2007 13:34:15 -0700 (MST) Date: Tue, 23 Jan 2007 14:34:14 -0600 From: Chris Kirby Subject: Re: zfs list -d [PSARC/2007/050 Timeout: 02/01/2007] In-reply-to: <200701232008.l0NK8ocr006938@vaticaan.holland.sun.com> Sender: Christopher.Kirby@sun.com To: Casper.Dik@sun.com Cc: Nicolas Williams , Scott Rotondo , PSARC@sac.sfbay.sun.com, Matthew Ahrens Message-id: <45B67146.5020805@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200701222253.l0MMri8w025269@cyber.eng.sun.com> <45B5EAF6.1090504@Sun.COM> <45B64A90.8080307@sun.com> <20070123175600.GF9523@binky.Central.Sun.COM> <45B660A5.3030901@sun.com> <200701231929.l0NJTHSs003390@vaticaan.holland.sun.com> <45B66A1D.1080501@sun.com> <200701232008.l0NK8ocr006938@vaticaan.holland.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20040610 Status: RO Content-Length: 985 Casper.Dik@Sun.COM wrote: >>So now we have both a dataset named fs1 and a subdir named >>fs1 in the root directory. From /, if the user asks for >>"zfs list fs1", which one do we choose? We could state that >>dataset names take precedence over path names to preserve >>current semantics, but if they really wanted /fs1, they >>would have to specify /fs1 or ./fs1, i.e. use something more >>specific to differentiate between the two. >> >> > >Well, the software can detect ambiguity so why not make it report >that and print the possible interpretations and how the user >can disambiguate? > > I could see the potential for breaking existing scripts. In the normal case, any script running zfs list from the root directory would find a dataset named, e.g. fs1 and a directory named fs1. Previously that script would do the right thing, whereas now we would take an input that is still valid and die with an error about ambiguity. I'm not sure if that's acceptable. -Chris From sacadmin Mon Feb 5 11:00:21 2007 Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l15J0Lun010804 for ; Mon, 5 Feb 2007 11:00:21 -0800 (PST) Received: from [129.146.228.109] (cyber [129.146.228.109]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l15J0I7i028639; Mon, 5 Feb 2007 11:00:21 -0800 (PST) Message-ID: <45C77EAB.8030407@sun.com> Date: Mon, 05 Feb 2007 10:59:55 -0800 From: Matthew Ahrens User-Agent: Thunderbird 1.5.0.8 (X11/20061204) MIME-Version: 1.0 To: PSARC@sac.sfbay.sun.com, Chris Kirby Subject: Re: zfs list -d [PSARC/2007/050 Timeout: 02/01/2007] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 90 Timer has expired with no outstanding issues; I'm closing this case as approved. --matt