From sacadmin Tue Jul 17 14:08:56 2007 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 l6HL8uJ9000952; Tue, 17 Jul 2007 14:08:56 -0700 (PDT) Received: (from calum@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l6HL8u47000948; Tue, 17 Jul 2007 14:08:56 -0700 (PDT) Date: Tue, 17 Jul 2007 14:08:56 -0700 (PDT) From: Calum Mackay Message-Id: <200707172108.l6HL8u47000948@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Cc: Calum.Mackay@Sun.COM Subject: NFSv4 Mirror-mounts [PSARC/2007/416 FastTrack timeout 07/25/2007] Status: RO Content-Length: 552 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: NFSv4 Mirror-mounts 1.2. Name of Document Author/Supplier: Author: Calum Mackay 1.3 Date of This Document: 17 July, 2007 4. Technical Description See the case directory for more detail 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 Calum.Mackay@sun.com Tue Jul 17 14:31:15 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l6HLVEKn001665 for ; Tue, 17 Jul 2007 14:31:15 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l6HLT9J3012958 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 18 Jul 2007 05:29:12 +0800 (SGT) 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 <0JLC00J05ECMGJ00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 17 Jul 2007 14:29:10 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLC00EA9ECLKJ20@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 17 Jul 2007 14:29:10 -0700 (PDT) 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 l6HLT9QL015934 for ; Tue, 17 Jul 2007 21:29:09 +0000 (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 <0JLC00J01EB0TH00@d1-emea-09.sun.com> (original mail from Calum.Mackay@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 17 Jul 2007 22:29:09 +0100 (BST) Received: from [192.168.254.1] ([62.24.230.83]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLC001I6ECJ0G9I@d1-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 17 Jul 2007 22:29:09 +0100 (BST) Date: Tue, 17 Jul 2007 22:29:06 +0100 From: Calum Mackay Subject: 2007/416 NFSv4 Mirror-mounts Sender: Calum.Mackay@sun.com To: PSARC-ext@sun.com Message-id: <469D34A2.9090603@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 3.0a1pre (X11/20070627) Status: RO Content-Length: 4792 I'm sponsoring the following fast-track for myself. The case seeks Patch binding, for possible inclusion in an Update release, and the interfaces described are Committed. I have set the timer to next Wednesday, 25th July. cheers, calum. NFSv4 Mirror-mounts This fast-track describes "mirror-mounts", a part of the NFSv4 protocol (RFC3530) that was not included in the initial Solaris NFSv4 delivery. Mirror-mounts enable an NFSv4 client to traverse shared filesystem mount points in the server's NFSv4 namespace. The main advantages over the traditional automounter-based approach are that namespace changes on the server are immediately visible to all clients, and there is no longer the overhead associated with administering automount maps. With mirror-mounts, new shared filesystems will be discovered instantly, when the client accesses them, and automatically mounted. Mirror-mounts are purely client-side NFSv4 behaviour, and require no new functionality, observability, nor control, on the part of the NFSv4 server. User visibility of mirror-mounted mount points The sole visible difference between a mirror-mounted NFSv4 filesystem, and a manual mount, or automount, on the NFS client, is that nfsstat(1M) "-m" output will include an additional field "mirrormount" to note that the mount is a mirror-mount. Automatic unmounting Mirror-mounted filesystems will be automatically unmounted if idle, after a certain period of inactivity. The period will be that used by the automounter for the same purpose, i.e. as set by the AUTOMOUNT_TIMEOUT property in /etc/default/autofs (proposed to become the sharectl(1M) "autofs timeout" property, see PSARC 2007/393), and will not be separately controllable. Recursive manual hierarchical unmounting If an NFS filesystem is manually unmounted, then any mirror-mounted filesystems contained within it will also be unmounted, if idle. If there is an active mirror-mounted filesystem within, the manual unmount will fail, as though that original filesystem were busy. A forced unmount will, however, be propagated through to all enclosed mirror-mounted filesystems. Interaction with the automounter Where there is an existing automount trigger point setup for a particular server filesystem, it will take precedence over mirror-mounting, i.e. a mirror-mount will not occur for that filesystem. If a filesystem boundary is encountered within an automounted filesystem, a mirror-mount will still occur for it. When the automounter unmounts the parent filesystem, any mirror-mounted filesystems within it will also be automatically unmounted, if idle. If there is an active mirror-mounted filesystem, the automatic unmount will not occur (which preserves current automount behaviour). Reference Mount Point Crossing. NFSv4 Protocol, RFC3530 Section 7.7. http://www.ietf.org/rfc/rfc3530.txt Background - Existing NFSv4 server namespace browsing In the absence of any client automount map, the existing NFSv4 server implementation in Solaris still presents the entire server namespace to the client, i.e server mount-points (in effect) are visible to the client before the client has mounted them, even if the server mount-points themselves are on a server filesystem that is not shared: NFSv4-server # share - /dum rw=pawns "" - /dee rw=pawns "" # note that the server does not share "/", yet we may mount it NFSv4-client # mount NFSv4-server:/ /mnt NFSv4-client # ls -l /mnt total 4 drwxr-xr-x 3 alice pawns 512 Oct 18 15:01 dee drwxr-xr-x 37 root sys 1024 Oct 18 14:50 dum This continues to provide the useful browsing feature, previously available via the automounter, without imposing the overhead of a mount, which may be important in the presence of many server filesystems e.g. when using ZFS. Note that the attributes of the filesystems are presented correctly, even thought the client has not yet mounted them, unlike the automounter's browse feature. However, the contents of the server's filesystems cannot be seen: NFSv4-server # ls -al /dee total 20 drwxr-xr-x 3 alice pawns 512 Oct 18 15:01 . drwxr-xr-x 31 root root 1024 Oct 18 15:01 .. drwx------ 2 alice pawns 8192 Oct 18 14:53 lost+found -rw-r--r-- 1 alice pawns 0 Oct 18 14:58 this_file_is_in_slash_dee NFSv4-client # ls -al /mnt/dee total 4 drwxr-xr-x 3 alice pawns 512 Oct 18 15:01 . drwxr-xr-x 31 root root 1024 Oct 18 15:01 .. The proposed mirror-mount functionality would cause a real NFSv4 mount to occur when the client crosses into the new filesystem by accessing /mnt/dee. From sommerfeld@sun.com Tue Jul 17 15:14:03 2007 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 l6HME3B3003476 for ; Tue, 17 Jul 2007 15:14:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6HMC1qw018385; Tue, 17 Jul 2007 15:12:02 -0700 (PDT) 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 <0JLC00003GBBN300@nwk-avmta-1.sfbay.Sun.COM>; Tue, 17 Jul 2007 15:11:35 -0700 (PDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLC00EGDGBAKA40@nwk-avmta-1.sfbay.Sun.COM>; Tue, 17 Jul 2007 15:11:34 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6HMBXTT004509; Tue, 17 Jul 2007 18:11:33 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6HMBWc1028728; Tue, 17 Jul 2007 18:11:33 -0400 (EDT) Date: Tue, 17 Jul 2007 18:11:32 -0400 From: Bill Sommerfeld Subject: Re: 2007/416 NFSv4 Mirror-mounts In-reply-to: <469D34A2.9090603@sun.com> To: Calum Mackay Cc: PSARC-ext@sun.com Message-id: <1184710292.26997.22.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <469D34A2.9090603@sun.com> Status: RO Content-Length: 706 Is there a server-side change associated with this project or is it entirely a client-side feature? On Tue, 2007-07-17 at 22:29 +0100, Calum Mackay wrote: > Recursive manual hierarchical unmounting > > If an NFS filesystem is manually unmounted, then any mirror-mounted > filesystems contained within it will also be unmounted, if idle. If > there is an active mirror-mounted filesystem within, the manual unmount > will fail, as though that original filesystem were busy. A forced > unmount will, however, be propagated through to all enclosed > mirror-mounted filesystems. this seems odd to me -- is there some reason the unforced unmount can't always recurse into the enclosed mirror mountpoints? From Calum.Mackay@Sun.COM Tue Jul 17 17:01:03 2007 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 l6I012Y4006558 for ; Tue, 17 Jul 2007 17:01:03 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6HNwrWf010480; Wed, 18 Jul 2007 00:59:00 +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 <0JLC00B0BLAAK400@nwk-avmta-1.sfbay.Sun.COM>; Tue, 17 Jul 2007 16:58:58 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLC00E4NLA8KJ80@nwk-avmta-1.sfbay.Sun.COM>; Tue, 17 Jul 2007 16:58:57 -0700 (PDT) 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 l6HNwtGw022623; Tue, 17 Jul 2007 23:58:55 +0000 (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 <0JLC00H01L7MO500@d1-emea-09.sun.com> (original mail from Calum.Mackay@Sun.COM); Wed, 18 Jul 2007 00:58:55 +0100 (BST) Received: from [192.168.254.8] ([62.24.230.83]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLC009ISLA7AIBC@d1-emea-09.sun.com>; Wed, 18 Jul 2007 00:58:55 +0100 (BST) Date: Wed, 18 Jul 2007 00:58:55 +0100 From: Calum Mackay Subject: Re: 2007/416 NFSv4 Mirror-mounts In-reply-to: <1184710292.26997.22.camel@thunk> Sender: Calum.Mackay@Sun.COM To: Bill Sommerfeld Cc: PSARC-ext@Sun.COM Message-id: <469D57BF.80007@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <469D34A2.9090603@sun.com> <1184710292.26997.22.camel@thunk> User-Agent: Thunderbird 1.5.0.12 (X11/20070604) Status: RO Content-Length: 1046 Bill Sommerfeld wrote: > Is there a server-side change associated with this project or is it > entirely a client-side feature? entirely client-side; apols if that wasn't clear. I also failed to note that mirror-mounts should work with any vendor's NFSv4 server implementation. >> Recursive manual hierarchical unmounting >> >> If an NFS filesystem is manually unmounted, then any mirror-mounted >> filesystems contained within it will also be unmounted, if idle. If >> there is an active mirror-mounted filesystem within, the manual unmount >> will fail, as though that original filesystem were busy. A forced >> unmount will, however, be propagated through to all enclosed >> mirror-mounted filesystems. > > this seems odd to me -- is there some reason the unforced unmount can't > always recurse into the enclosed mirror mountpoints? but if they're active - busy - then we shouldn't allow them to be unmounted, surely? Just as if the enclosing mount were busy, we would fail that unmount. or am I missing your point, Bill? cheers, c. From sommerfeld@sun.com Tue Jul 17 19:03:15 2007 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 l6I23F6s008851 for ; Tue, 17 Jul 2007 19:03:15 -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 l6I20GMk058872; Tue, 17 Jul 2007 20:00:18 -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 <0JLC0010DQY1DL00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 17 Jul 2007 19:01:13 -0700 (PDT) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLC00EZNQY0KAB0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 17 Jul 2007 19:01:13 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6I21Bjn025469; Tue, 17 Jul 2007 22:01:11 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6I21BeB000289; Tue, 17 Jul 2007 22:01:11 -0400 (EDT) Date: Tue, 17 Jul 2007 22:01:10 -0400 From: Bill Sommerfeld Subject: Re: 2007/416 NFSv4 Mirror-mounts In-reply-to: <469D57BF.80007@sun.com> To: Calum Mackay Cc: PSARC-ext@sun.com Message-id: <1184724070.26997.47.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <469D34A2.9090603@sun.com> <1184710292.26997.22.camel@thunk> <469D57BF.80007@sun.com> Status: RO Content-Length: 1434 On Wed, 2007-07-18 at 00:58 +0100, Calum Mackay wrote: > Bill Sommerfeld wrote: > > Is there a server-side change associated with this project or is it > > entirely a client-side feature? > > entirely client-side; apols if that wasn't clear. > I also failed to note that mirror-mounts should work with any vendor's > NFSv4 server implementation. thanks for the clarification. > >> Recursive manual hierarchical unmounting > >> > >> If an NFS filesystem is manually unmounted, then any mirror-mounted > >> filesystems contained within it will also be unmounted, if idle. If > >> there is an active mirror-mounted filesystem within, the manual unmount > >> will fail, as though that original filesystem were busy. A forced > >> unmount will, however, be propagated through to all enclosed > >> mirror-mounted filesystems. > > > > this seems odd to me -- is there some reason the unforced unmount can't > > always recurse into the enclosed mirror mountpoints? > > but if they're active - busy - then we shouldn't allow them to be > unmounted, surely? Just as if the enclosing mount were busy, we would > fail that unmount. > > or am I missing your point, Bill? No, I missed yours -- I managed to completely miss the second half of the first sentence of the paragraph I quoted and skipped ahead to the second sentence. now that i actually read it correctly, the behavior appears to be what I'm expecting. - Bill From Nicolas.Williams@sun.com Wed Jul 18 08:29:30 2007 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 l6IFTUdp023518 for ; Wed, 18 Jul 2007 08:29:30 -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.2) with ESMTP id l6IFQ4rA062971; Wed, 18 Jul 2007 09:26:28 -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 <0JLD0040DS9N0C00@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Jul 2007 08:27:23 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLD00M50S9LHQA0@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Jul 2007 08:27:21 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6IFRLsQ024675; Wed, 18 Jul 2007 10:27:21 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6IFRLQK024674; Wed, 18 Jul 2007 10:27:21 -0500 (CDT) Date: Wed, 18 Jul 2007 10:27:21 -0500 From: Nicolas Williams Subject: Re: 2007/416 NFSv4 Mirror-mounts In-reply-to: <469D34A2.9090603@sun.com> To: Calum Mackay Cc: PSARC-ext@sun.com Message-id: <20070718152720.GC24645@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <469D34A2.9090603@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 705 On Tue, Jul 17, 2007 at 10:29:06PM +0100, Calum Mackay wrote: > Interaction with the automounter > > Where there is an existing automount trigger point setup for a > particular server filesystem, it will take precedence over > mirror-mounting, i.e. a mirror-mount will not occur for that filesystem. So, no mirror mounts in /net?! Please say it ain't so :( The current /net -hosts automount map depends on the MOUNT protocol to get hierarchical mount information and does honor hierarchical mounts, but it does not refresh this ever, which is a big problem when the server uses ZFS (and therefore likes to make/destroy datasets willy nilly). Mirror mounts would clearly solve this problem. Nico -- From Thomas.Haynes@sun.com Wed Jul 18 08:36:41 2007 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 l6IFaf4A023624 for ; Wed, 18 Jul 2007 08:36:41 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6IFYcMn015475 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 18 Jul 2007 08:34:38 -0700 (PDT) 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 <0JLD0040LSLPA400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Jul 2007 08:34:37 -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 <0JLD00M1DSLOHWA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Jul 2007 08:34:36 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6IFYZBV001493 for ; Wed, 18 Jul 2007 15:34:36 +0000 (GMT) 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 <0JLD00901SKETI00@mail-amer.sun.com> (original mail from Thomas.Haynes@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Jul 2007 09:34:36 -0600 (MDT) Received: from [192.168.2.4] ([72.198.16.43]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLD007MMSLNMQB1@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Jul 2007 09:34:35 -0600 (MDT) Date: Wed, 18 Jul 2007 10:32:28 -0500 From: Tom Haynes Subject: Re: 2007/416 NFSv4 Mirror-mounts In-reply-to: <20070718152720.GC24645@Sun.COM> Sender: Thomas.Haynes@sun.com To: Nicolas Williams Cc: Calum Mackay , PSARC-ext@sun.com Message-id: <469E328C.7080301@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <469D34A2.9090603@sun.com> <20070718152720.GC24645@Sun.COM> User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) Status: RO Content-Length: 1255 Nicolas Williams wrote: > On Tue, Jul 17, 2007 at 10:29:06PM +0100, Calum Mackay wrote: > >> Interaction with the automounter >> >> Where there is an existing automount trigger point setup for a >> particular server filesystem, it will take precedence over >> mirror-mounting, i.e. a mirror-mount will not occur for that filesystem. >> > > So, no mirror mounts in /net?! Please say it ain't so :( > > The current /net -hosts automount map depends on the MOUNT protocol to > get hierarchical mount information and does honor hierarchical mounts, > but it does not refresh this ever, which is a big problem when the > server uses ZFS (and therefore likes to make/destroy datasets willy > nilly). Mirror mounts would clearly solve this problem. > > Nico > It ain't so. I think the intent here is that if you have a choice over an automount or a mirror mount, we take the automount. But if there is no automount entry and there is a chance to mirror mount, then we will of course mirror mount. Assume that a server has a zfs pool called tank and it is serving up home dirs. So: cd /net/server No mirror mounts have occurred. No: cd tank Okay, this will cause a mirror mount to occur. And as we dive down farther, more will occur. From Nicolas.Williams@Sun.COM Wed Jul 18 08:50:20 2007 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 l6IFoKUg023777 for ; Wed, 18 Jul 2007 08:50:20 -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.2) with ESMTP id l6IFlH7i004055; Wed, 18 Jul 2007 09:47:18 -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 <0JLD0041LT8FWL00@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Jul 2007 08:48:15 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLD00MPYT8DHSC0@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Jul 2007 08:48:13 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6IFmDDu024718; Wed, 18 Jul 2007 10:48:13 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6IFmD23024717; Wed, 18 Jul 2007 10:48:13 -0500 (CDT) Date: Wed, 18 Jul 2007 10:48:13 -0500 From: Nicolas Williams Subject: Re: 2007/416 NFSv4 Mirror-mounts In-reply-to: <469E328C.7080301@sun.com> To: Tom Haynes Cc: Calum Mackay , PSARC-ext@Sun.COM Message-id: <20070718154812.GG24645@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <469D34A2.9090603@sun.com> <20070718152720.GC24645@Sun.COM> <469E328C.7080301@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1192 On Wed, Jul 18, 2007 at 10:32:28AM -0500, Tom Haynes wrote: > Nicolas Williams wrote: > >So, no mirror mounts in /net?! Please say it ain't so :( > > It ain't so. Excellent, thanks. > I think the intent here is that if you have a choice over an automount > or a mirror mount, we take the > automount. > > But if there is no automount entry and there is a chance to mirror > mount, then we will of course > mirror mount. So what was intended is that where there are _explicit_ automount entries they override mirror mounts. The -hosts automount map lacks explicit entries, therefore for NFSv4 mounts mirror mounts always supercede the v3-centric MOUNT protocol-driven scheme. One more question, suppose I have an entry like: foo / someserver:/pool/foo /bar someserver:/tank/bar and there are further server-side mounts on /pool/foo/baz and /tank/bar/abc, THEN by the principle of least surprise I'd expect: - the automount entry is authoritative for the /foo/bar mount-point (hiding whatever is actually in /pool/foo/bar on the server), but - mirror mounts are still performed for /foo/baz and /foo/bar/abc Is it so? Nico -- From Thomas.Haynes@sun.com Wed Jul 18 13:48:53 2007 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 l6IKmqq1002863 for ; Wed, 18 Jul 2007 13:48:53 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6IKkjXZ004254 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 18 Jul 2007 21:46:49 +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 <0JLE00I0F71ZQ600@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Jul 2007 13:46:47 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLE00HXS71YH120@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Jul 2007 13:46:47 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6IKkkBR003508 for ; Wed, 18 Jul 2007 20:46:46 +0000 (GMT) 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 <0JLE00G016QXA400@mail-amer.sun.com> (original mail from Thomas.Haynes@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Jul 2007 14:46:46 -0600 (MDT) Received: from [129.150.49.7] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLE00B8071XQCB3@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Jul 2007 14:46:46 -0600 (MDT) Date: Wed, 18 Jul 2007 15:44:10 -0500 From: Tom Haynes Subject: Re: 2007/416 NFSv4 Mirror-mounts In-reply-to: <469E328C.7080301@sun.com> Sender: Thomas.Haynes@sun.com To: Tom Haynes Cc: Nicolas Williams , Calum Mackay , PSARC-ext@sun.com Message-id: <469E7B9A.6030402@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <469D34A2.9090603@sun.com> <20070718152720.GC24645@Sun.COM> <469E328C.7080301@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1986 Tom Haynes wrote: > Nicolas Williams wrote: >> On Tue, Jul 17, 2007 at 10:29:06PM +0100, Calum Mackay wrote: >> >>> Interaction with the automounter >>> >>> Where there is an existing automount trigger point setup for a >>> particular server filesystem, it will take precedence over >>> mirror-mounting, i.e. a mirror-mount will not occur for that >>> filesystem. >>> >> >> So, no mirror mounts in /net?! Please say it ain't so :( >> >> The current /net -hosts automount map depends on the MOUNT protocol to >> get hierarchical mount information and does honor hierarchical mounts, >> but it does not refresh this ever, which is a big problem when the >> server uses ZFS (and therefore likes to make/destroy datasets willy >> nilly). Mirror mounts would clearly solve this problem. >> >> Nico >> > > > It ain't so. > > I think the intent here is that if you have a choice over an automount > or a mirror mount, we take the > automount. > > But if there is no automount entry and there is a chance to mirror > mount, then we will of course > mirror mount. > > Assume that a server has a zfs pool called tank and it is serving up > home dirs. > > So: > > cd /net/server > > No mirror mounts have occurred. > > No: > > cd tank > > Okay, this will cause a mirror mount to occur. And as we dive down > farther, more will occur. > > I was wrong here. In this case, tank already exists and would thus have been gotten from the MOUNT protocol doing a scan. I was looking at the non-/net case. In re-reading your email Nico, I see what you are really concerned with is the following scenario: mount server:/ /mnt cd /mnt ls -la ... .... tank ... cd tank ls -la ... ... ... At which point those ZFS filesystems have been read in (actually occured way before this, right?). And now if we go to the server and create a new zfs filesystem in tank, will a mirrormount occur? I'm going to have to run this test and see what happens. I'll get back with that information. From Nicolas.Williams@sun.com Wed Jul 18 14:04:55 2007 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 l6IL4tOY003537 for ; Wed, 18 Jul 2007 14:04:55 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6IL2mcQ028602; Wed, 18 Jul 2007 14:02:50 -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 <0JLE006077SP4S00@brm-avmta-1.central.sun.com>; Wed, 18 Jul 2007 15:02:49 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLE00HIV7SOFSC0@brm-avmta-1.central.sun.com>; Wed, 18 Jul 2007 15:02:48 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6IL2mkO024943; Wed, 18 Jul 2007 16:02:48 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6IL2mSh024942; Wed, 18 Jul 2007 16:02:48 -0500 (CDT) Date: Wed, 18 Jul 2007 16:02:48 -0500 From: Nicolas Williams Subject: Re: 2007/416 NFSv4 Mirror-mounts In-reply-to: <469E7B9A.6030402@sun.com> To: Tom Haynes Cc: Calum Mackay , PSARC-ext@sun.com Message-id: <20070718210247.GL24645@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <469D34A2.9090603@sun.com> <20070718152720.GC24645@Sun.COM> <469E328C.7080301@sun.com> <469E7B9A.6030402@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 932 On Wed, Jul 18, 2007 at 03:44:10PM -0500, Tom Haynes wrote: > I was wrong here. In this case, tank already exists and would thus have > been gotten from the > MOUNT protocol doing a scan. > > I was looking at the non-/net case. > > In re-reading your email Nico, I see what you are really concerned with > is the following scenario: Basically, what I want is for automountd to ignore or even, and preferably, not to attempt to use the MOUNT protocol when NFSv4 would be used for a given -hosts map mount. Additionally and _separately_, I think mirror mounts should always work when: a) NFSv4 is used (of course), and b) there is no automount entry that would conflict, and therefore, override a server-side mountpoint. To sum up all of the above in one nice package: Automount entries override server-side mount-points in the same locations in the fs hierarchy, and ONLY such server-side mount-points. Nico -- From Calum.Mackay@sun.com Wed Jul 18 16:35:09 2007 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 l6INZ8of012380 for ; Wed, 18 Jul 2007 16:35:09 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6INX2ZN015198 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 19 Jul 2007 00:33:06 +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 <0JLE00C0BER5H400@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Jul 2007 16:33:05 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLE0022FER4PZ70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Jul 2007 16:33:05 -0700 (PDT) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6INX4Zs018318 for ; Wed, 18 Jul 2007 23:33:04 +0000 (GMT) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLE00201EO80U00@d1-emea-10.sun.com> (original mail from Calum.Mackay@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 19 Jul 2007 00:33:04 +0100 (BST) Received: from [192.168.254.1] ([62.24.230.83]) by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLE006LQER2SQ35@d1-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 19 Jul 2007 00:33:04 +0100 (BST) Date: Thu, 19 Jul 2007 00:33:02 +0100 From: Calum Mackay Subject: Re: 2007/416 NFSv4 Mirror-mounts In-reply-to: <20070718210247.GL24645@Sun.COM> Sender: Calum.Mackay@sun.com To: Nicolas Williams Cc: PSARC-ext@sun.com Message-id: <469EA32E.7050307@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <469D34A2.9090603@sun.com> <20070718152720.GC24645@Sun.COM> <469E328C.7080301@sun.com> <469E7B9A.6030402@sun.com> <20070718210247.GL24645@Sun.COM> User-Agent: Thunderbird 3.0a1pre (X11/20070627) Status: RO Content-Length: 2014 thanks much for the comments Nico. The NFSv4 namespace work that has been considered can be split into several areas: o Mirror-mounts o Referrals o Replication & Migration o Automount refactoring to not use MOUNT for NFSv4 This case is about enabling mirror-mounts. Whilst the automount refactoring is useful work, I feel that it's a separate case. In addition, the Referrals work proposed also requires automounter refactoring, and if the automount/MOUNT work were to be bundled in with something, it would make more sense for it to be with Referrals. With the proposed functionality, for mirror-mounts to be available requires at least one NFSv4 filesystem to already be mounted, either manually, or via the automounter. Once that first v4 mount has occurred, mirror-mounts will be possible from that point down. Some examples: Assume the server shares these separate filesystems: /export /export/sparc /export/x86 and also has a set of ZFS filesystems under /tank, all separately shared (but /tank itself perhaps not explicitly shared). If the client were to manually v4 mount: :/ mirror-mounts would show and provide access to everything :/export mirror-mounts would show and provide access to everything under /export :/tank mirror-mounts would show and provide access to everything under /tank If automounter maps were setup to mount the same directories, the same behaviour would apply. Regular v4 mounts would be used for these directories themselves, and mirror-mounts would then be available to show and provide access to everything under them. Any new ZFS filesystems created (and shared) under /tank would become immediately visible, and accessible, via mirror-mounts. Regarding /net: because the automounter retrieves the entire export list from the server, using the MOUNT protocol, and then populates /net with autofs trigger points for all of them, mirror-mounts do not get a chance (because we don't override an autofs trigger point). From Calum.Mackay@sun.com Wed Jul 18 16:36:44 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l6INaiI1012446 for ; Wed, 18 Jul 2007 16:36:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l6INYYvn024893 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 19 Jul 2007 07:34:42 +0800 (SGT) 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 <0JLE00301ETS8V00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Jul 2007 16:34:40 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLE0038QETR6800@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Jul 2007 16:34:39 -0700 (PDT) Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6INYc92028880 for ; Wed, 18 Jul 2007 23:34:38 +0000 (GMT) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLE00201EO80U00@d1-emea-10.sun.com> (original mail from Calum.Mackay@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 19 Jul 2007 00:34:38 +0100 (BST) Received: from [192.168.254.1] ([62.24.230.83]) by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLE00642ETPSN84@d1-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 19 Jul 2007 00:34:38 +0100 (BST) Date: Thu, 19 Jul 2007 00:34:36 +0100 From: Calum Mackay Subject: Re: 2007/416 NFSv4 Mirror-mounts In-reply-to: <469D34A2.9090603@sun.com> Sender: Calum.Mackay@sun.com To: Calum Mackay Cc: PSARC-ext@sun.com Message-id: <469EA38C.9010704@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <469D34A2.9090603@sun.com> User-Agent: Thunderbird 3.0a1pre (X11/20070627) Status: RO Content-Length: 65 This case was approved at today's PSARC meeting. cheers, calum.