From rsb@sac.sfbay.sun.com Fri Jun 6 12:46:03 2008 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 m56Jk2BP002625 for ; Fri, 6 Jun 2008 12:46:02 -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.2) with ESMTP id m56JjwM7024928; Fri, 6 Jun 2008 13:46:02 -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 <0K220020D48P7A00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 06 Jun 2008 12:46:01 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K220048G48OF6C0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 06 Jun 2008 12:46:00 -0700 (PDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m56Jk091022662; Fri, 06 Jun 2008 12:46:00 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m56JjxUM002620; Fri, 06 Jun 2008 12:45:59 -0700 (PDT) Received: (from rsb@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m56JjwPl002616; Fri, 06 Jun 2008 14:45:58 -0500 (CDT) Date: Fri, 06 Jun 2008 14:45:58 -0500 (CDT) From: Rich.Brown@sun.com Subject: VSW_CANLOFI [PSARC/2008/366 Self Review] To: PSARC-ext@sun.com Cc: fs-interest@sun.com Message-id: <200806061945.m56JjwPl002616@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2167 I'm sponsoring this case for John Levon. It's an obvious solution with precedent. I believe this qualifies for self-review, but if anyone disagrees, let me know and I'll promote it to a fast track. The requested binding is PATCH, which matches the binding of the original case (PSARC/2008/290 lofi mount, approved 6 May 2008). Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: VSW_CANLOFI 1.2. Name of Document Author/Supplier: Author: John Levon 1.3 Date of This Document: 06 June, 2008 4. Technical Description This case seeks patch binding. After further review of the changes for: PSARC/2008/290 lofi mount (approved 6 May 2008) The team has identified a cleaner way of determining of a file system type supports lofi mounts. This is done by setting a new flag, VSW_CANLOFI, in the file systems vfsdef_t structure. This structure is examined at modload time and the vfsdev_t's flags are transferred to the file system type's vfssw_t table entry. This follows the precedent set by VSW_STATS and VSW_XID. The team considered using the VFS Feature facility (PSARC 2007/227) but the Feature facility is set up for a file system at mount time. Support for lofi mounts must be determined before the mount occurs. Consequently, the next best alternative was the solution proposed here. VSW_CANLOFI, when set on a filesystem type, indicates that it understands lofi mounts and the generic VFS layer should attempt to create lofi nodes for the mount special, if that is a file. The generic VFS code checks for this value: if it's not set for the filesystem type being mounted, then no attempt to configure a lofi mount is made. The new flag is Consolidation Private. Note that unbundled file system developers will be informed of this change via the unbundled-fs-developers@sun.com as well as a planned FS TOI for Solaris Nevada (TBD). 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From Jeff.Bonwick@sun.com Thu Jun 12 16:25:01 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5CNP1aF014608 for ; Thu, 12 Jun 2008 16:25:01 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5CNOu1C002653; Fri, 13 Jun 2008 00:24:58 +0100 (BST) 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 <0K2D0030DIDKD600@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Jun 2008 16:24:56 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D002AEIDKSB00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Jun 2008 16:24:56 -0700 (PDT) Received: from zion.sfbay.sun.com (localhost [127.0.0.1]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m5CNOtZZ026366; Thu, 12 Jun 2008 23:24:55 +0000 (GMT) Received: (from bonwick@localhost) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m5CNOtZD026365; Thu, 12 Jun 2008 16:24:55 -0700 (PDT) Date: Thu, 12 Jun 2008 16:24:54 -0700 From: Jeff Bonwick Subject: PSARC/2008/366 VSW_CANLOFI and ZFS In-reply-to: <200806120114.m5C1Eq9h438655@elpaso.sfbay.sun.com> To: John Levon Cc: PSARC-ext@sun.com, zfs-team@sun.com Message-id: <20080612232454.GA25172@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: <200806120114.m5C1Eq9h438655@elpaso.sfbay.sun.com> X-Authentication-warning: zion.sfbay.sun.com: bonwick set sender to Jeff.Bonwick@sun.com using -f User-Agent: Mutt/1.5.14 (2007-02-12) Status: RO Content-Length: 2376 John, I saw this putback fly by and was curious why ZFS wasn't touched, so I looked into both this case and its predecessor, PSARC/2008/290. I see now why ZFS is different, but I think it's quite possible to make this work. For folks who haven't followed this, a brief description: when you have an iso file, it's really convenient to be able to just mount it. But you can't mount a file, so before this putback it was a two-step process: # lofiadm -a /my/iso # creates /dev/lofi/1 # mount -F hsfs /dev/lofi/1 /mnt # access /my/iso via /mnt With this wadlet, you can now omit the lofiadm step and just say: # mount -F hsfs /my/iso /mnt Similarly with unmount -- you don't have to remember to lofiadm -d. All well and good. But this doesn't work with ZFS because you can't just pass a raw device to zfs_mount(). However, I see no reason we couldn't make this work. If you specify a file or device to zfs_mount(), as indicated by a leading slash in the "special" field, we could attempt to import to an alternate root at the specified mountpoint. Upon last unmount (there may be multiple filesystems in the pool), we would automatically export the pool. We will need read-only pool support to make read-only ZFS media work this way, but of course that's already on our list. What do you think, folks -- does this seem useful? Can you see any reason why it's not as simple as I've described? Jeff On Wed, Jun 11, 2008 at 06:14:53PM -0700, John Levon wrote: > Event: putback-to > Parent workspace: /ws/onnv-gate > (elpaso:/ws/onnv-gate) > Child workspace: /net/hatchback/export/build/johnlev/onnv-lomount > (hatchback:/export/build/johnlev/onnv-lomount) > User: johnlev > > Comment: > PSARC 2008/366 VSW_CANLOFI > 6709611 PSARC 2008/366 VSW_CANLOFI > > Files: > update: usr/src/uts/common/fs/hsfs/hsfs_vfsops.c > update: usr/src/uts/common/fs/pcfs/pc_vfsops.c > update: usr/src/uts/common/fs/udfs/udf_vfsops.c > update: usr/src/uts/common/fs/ufs/ufs_vfsops.c > update: usr/src/uts/common/fs/vfs.c > update: usr/src/uts/common/gssapi/gssd_clnt_stubs.c > update: usr/src/uts/common/os/modctl.c > update: usr/src/uts/common/sys/modctl.h > update: usr/src/uts/common/sys/vfs.h > update: usr/src/uts/sun4u/serengeti/io/ssm.c > > Examined files: 10 > > Contents Summary: > 10 update > From johnlev@barman.uk.sun.com Fri Jun 13 07:15:47 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DEFk3Q009102 for ; Fri, 13 Jun 2008 07:15:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5DEFZSa024168; Fri, 13 Jun 2008 15:15:44 +0100 (BST) 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 <0K2E00C0FNM6Y200@brm-avmta-1.central.sun.com>; Fri, 13 Jun 2008 08:15:42 -0600 (MDT) Received: from dm-uk-01.uk.sun.com ([129.156.101.115]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E005JNNM413B0@brm-avmta-1.central.sun.com>; Fri, 13 Jun 2008 08:15:41 -0600 (MDT) Received: from barman.uk.sun.com (barman.UK.Sun.COM [129.156.132.12]) by dm-uk-01.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5DEFd4Q020269; Fri, 13 Jun 2008 15:15:40 +0100 (BST) Received: from johnlev by barman.uk.sun.com with local (Exim 4.42) id 1K7A5G-0007as-0b; Fri, 13 Jun 2008 15:16:54 +0100 X-URL: http://jurassic.eng/~johnlev/ Date: Fri, 13 Jun 2008 15:16:53 +0100 From: John Levon Subject: Re: PSARC/2008/366 VSW_CANLOFI and ZFS In-reply-to: <20080612232454.GA25172@eng.sun.com> Sender: John Levon To: Jeff Bonwick Cc: John Levon , PSARC-ext@sun.com, zfs-team@sun.com Message-id: <20080613141653.GA29008@barman.uk.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: <200806120114.m5C1Eq9h438655@elpaso.sfbay.sun.com> <20080612232454.GA25172@eng.sun.com> User-Agent: Mutt/1.5.6i Status: RO Content-Length: 1233 On Thu, Jun 12, 2008 at 04:24:54PM -0700, Jeff Bonwick wrote: > I saw this putback fly by and was curious why ZFS wasn't touched, My original basis for this was that the interesting use case was already supported in ZFS style: zpool import -d /net/zday/some/path/to/zpool/images/ > However, I see no reason we couldn't make this work. If you specify > a file or device to zfs_mount(), as indicated by a leading slash in > the "special" field, we could attempt to import to an alternate root > at the specified mountpoint. Upon last unmount (there may be multiple > filesystems in the pool), we would automatically export the pool. This sounds like it's covering three things: - the ability to import a pool given a fully-specified path, not just a directory - the ability to import a pool to a different mount directory - temporary pools All of these features seem like useful ones to me. However, I can't help but feel that it's much more natural to support this in zpool: zpool import [-t] [pool path] [top-level mount point] Where -t means that the last unmount also exports the pool. Perhaps we could make mount(1m) do this as well, though I doubt this would actually use the lofi interface itself? regards john