From rm129958@sac.sfbay.sun.com Fri Oct 16 12:39:09 2009 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 n9GJd8Us011428 for ; Fri, 16 Oct 2009 12:39:08 -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 n9GJd6qO003247; Fri, 16 Oct 2009 12:39:08 -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 <0KRM00103H98OC00@brm-avmta-1.central.sun.com>; Fri, 16 Oct 2009 13:39:08 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRM00KN4H97UI10@brm-avmta-1.central.sun.com>; Fri, 16 Oct 2009 13:39:07 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9GJd61o034126; Fri, 16 Oct 2009 12:39:06 -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 n9GJd52l011423; Fri, 16 Oct 2009 12:39:05 -0700 (PDT) Received: (from rm129958@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n9GJd59M011419; Fri, 16 Oct 2009 12:39:05 -0700 (PDT) Date: Fri, 16 Oct 2009 12:39:05 -0700 (PDT) From: Richard Matthews Subject: Provide minor private interface modifications to support mntfs [PSARC/2009/566 FastTrack timeout 10/23/2009] To: PSARC-ext@sun.com Message-id: <200910161939.n9GJd59M011419@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 7154 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Provide minor private interface modifications to support mntfs 1.2. Name of Document Author/Supplier: Author: Robert Harris 1.3 Date of This Document: 16 October, 2009 4. Technical Description This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Provide minor private interface modifications to support mntfs. 1.2. Name of Document Author/Supplier: Author: Robert Harris 1.3 Date of This Document: 13 October, 2009 4. Technical Description 1. Proposal: Provide minor private interface modifications to support mntfs. 2. The Problem: The contents of /etc/mnttab are created by mntfs on demand. mntfs parses the in-kernel mnttab structures to create a snapshot that can be used to satisfy subsequent calls to read() or ioctl(). The snapshot is stored by the kernel within the address space of the process that made the first call to read() or ioctl(). The enclosing mapping is removed from the calling process's address space by mntfs on last close(). The snapshot-in-userland design has a flaw: the kernel cannot determine whether or not a close() is a specific process's last if the vnode count is greater than 1. This is because there is no way to determine whether a count that is greater than one has originated from dup(), from fork() or from both. This means that mntfs is unable to ensure that every insertion of a mapping into a process's address space is paired with a corresponding deletion. Two specific manifestations are 6394241, in which a newly-execed process has an arbitrary range of its address space unmapped by mntfs, and 6813502, in which a process address space is entirely consumed by orphaned mappings left behind by mntfs. 3. Solutions: The most obvious solution seemed, at first, to involve storing the snapshot data within the corresponding vnode, thereby allowing the existing file system infrastructure to free the resources when no longer required. This, however, was rejected on account of complications inherent in the unprivileged user's resulting ability to allocate and retain kernel memory. It was previously believed that there remained no alternative other than to abandon the use of snapshots in their current form. The approach would necessitate a change to the behaviour of /etc/mnttab and its API and resulted in an earlier PSARC case, 2009/352. Although case 2009/352 was approved, comments exchanged during its review have led to the design of a solution that retains all of the existing documented behaviour and yet has minimal consumption of kernel memory. This solution has been adopted as the preferred approach. Very briefly, the new proposal effects a snapshot by constructing a per-zone "database" that encapsulates the different states of the in-kernel mnttab that are visible to existing consumers. The database takes the form of a linked list where every element represents an entry in /etc/mnttab and has a time of birth and a time of death. By providing appropriate time stamps to each element, a consumer need remember only the time at which his own view was created. This view, i.e. snapshot, can be generated on demand by walking through the database and extracting all elements that were "born" before, but that "died" after, the snapshot creation time. Elements are removed when they are no longer referenced by any existing consumer, and so the database need not exist at all. 4. Impact: 4.1 Overview: This solution has some modest requirements. The database is maintained on a per-zone basis, and so the zone_t will acquire two new fields: a pointer to the database and a lock. Two new private ioctl() commands will be added, MNTIOC_GETEXTMNTENT and MNTIOC_GETMNTANY, to ensure that the getmntent(3C) family of functions can be serviced as efficiently as possible. More delicate is the need for every vfs_t present in the in-kernel mnttab to have a high-resolution time stamp indicating its time of creation (not its mount time). The vfs_t is unusual in that it is exposed to unbundled file systems, and is therefore considered dangerous to modify. To this end, following PSARC 2006/270, there now exists a vfs_impl_t, referenced by a vfs_t's vfs_implp, that is designed to accommodate additional fields that would otherwise occupy the vfs_t. As part of this change, the vfs_impl_t will acquire a new field: a high resolution time stamp. The new time stamp in the vfs_t's vfs_impl_t will be initialised in vfs_list_add(), a private function that inserts a mounted vfs_t into the in-kernel mnttab. Because the time stamp will be mandatory, vfs_list_add() will be modified to supply a vfs_t with a vfs_impl_t if it does not already have one. This is significant because unexpected behaviour could occur if an unbundled file system allocates its own vfs_t for insertion into the in-kernel mnttab. Consequently, developers of the unbundled file systems PxFS, VxFS, QFS and MVFS have been approached and have provided confirmation that the proposed changes will be harmless. Developers of OpenAFS have been approached but have not responded. File systems in ON are unaffected. 4.2 Interface changes: 1. The vfs_impl struct acquires a new member, vi_hrctime, which is the high-resolution creation time of the corresponding vfs_t. 2. vfs_list_add() will supply a vfs_t with a vfs_impl_t if it does not already have one. 3. The zone struct acquires two new members, zone_mntfs_db and zone_mntfs_db_lock. These implement the per-zone database described in section 3. 4. The existing ioctl() command MNTIOC_GETMNTENT will be modified and two new ioctl() commands, MNTIOC_GETEXTMNTENT and MNTIOC_GETMNTANY, will be created. These changes will support the getmntent(3C) family of functions. Note that they will create a backwards-incompatibility likely to affect S10-branded zones. These interfaces will all be Consolidation Private. 4.3 Other Once approved, this case will supercede PSARC/2009/352. 5. Release binding: Patch. 6. Documentation impact: None. 7. References: 1. CR 6394241 mntfs is not exec safe 2. CR 6813502 mntfs is not fork-safe program. 3. PSARC 2009/352. 4. PSARC 2006/270. 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 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 Gordon.Ross@sun.com Tue Oct 20 08:45:58 2009 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 n9KFjwOZ018254 for ; Tue, 20 Oct 2009 08:45:58 -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.2) with ESMTP id n9KFjtNG059687 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 20 Oct 2009 09:45:57 -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 <0KRT00L11L4LU400@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 20 Oct 2009 09:45:57 -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 <0KRT00L68L4KIL00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 20 Oct 2009 09:45:56 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9KFjuYY022862 for ; Tue, 20 Oct 2009 15:45:56 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KRT00E00JQUCW00@mail-amer.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 20 Oct 2009 09:45:56 -0600 (MDT) Received: from [129.148.169.214] ([unknown] [129.148.169.214]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KRT002V2L4J5O50@mail-amer.sun.com>; Tue, 20 Oct 2009 09:45:56 -0600 (MDT) Date: Tue, 20 Oct 2009 11:46:01 -0400 From: Gordon Ross Subject: Re: Provide minor private interface modifications to support mntfs [PSARC/2009/566 FastTrack timeout 10/23/2009] In-reply-to: <200910161939.n9GJd59M011419@sac.sfbay.sun.com> Sender: Gordon.Ross@sun.com To: Richard Matthews Cc: PSARC-ext@sun.com Message-id: <1256053561.1111.14.camel@dell6300gwr> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910161939.n9GJd59M011419@sac.sfbay.sun.com> Status: RO Content-Length: 1334 I'm pleased to see this improvement moving forward. Not sure if these are design or interface questions, but: Why is the mount time (vfs->vfs_mtime) not suitable for use in place of the new "created time" you're adding? Also, is the "destroyed time" not needed because elements will be removed from the list immediately upon unmount? If so, how is the "snapshot behavior" retained for an existing open performed before some mounts were removed? Thanks, Gordon Ross > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Provide minor private interface modifications to support > mntfs > 1.2. Name of Document Author/Supplier: > Author: Robert Harris > 1.3 Date of This Document: > 16 October, 2009 > 4. Technical Description > > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Provide minor private interface modifications to support mntfs. > 1.2. Name of Document Author/Supplier: > Author: Robert Harris > 1.3 Date of This Document: > 13 October, 2009 > 4. Technical Description > > 1. Proposal: > > Provide minor private interface modifications to support mntfs. > [...] > From glenn.skinner@sun.com Tue Oct 20 17:27:20 2009 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 n9L0RJ5R002527 for ; Tue, 20 Oct 2009 17:27:20 -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 n9L0RIaH002013 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 21 Oct 2009 01:27:19 +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 <0KRU00D0799HUP00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 20 Oct 2009 17:27:17 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRU005I899HVJ80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 20 Oct 2009 17:27:17 -0700 (PDT) Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9L0RHKa000797 for ; Tue, 20 Oct 2009 17:27:17 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id n9L0JlfV025263 for ; Tue, 20 Oct 2009 17:19:47 -0700 (PDT) Date: Tue, 20 Oct 2009 17:19:47 -0700 (PDT) From: Glenn Skinner Subject: Re: 2009/566 [interface modifications to support mntfs] To: PSARC-ext@sun.com Reply-to: Glenn Skinner Message-id: <200910210019.n9L0JlfV025263@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: SZMgjrMssAEl1SYB+psQdw== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2574 Date: Fri, 16 Oct 2009 12:39:05 -0700 (PDT) From: Richard Matthews Subject: Provide minor private interface modifications to support mntfs [PSARC/2009/566 FastTrack timeout 10/23/2009] First, +1. Second, a design question (see below); regardless of response, the +1 above stands. 1. Proposal: Provide minor private interface modifications to support mntfs. ... 4.1 Overview: This solution has some modest requirements. The database is maintained on a per-zone basis, and so the zone_t will acquire two new fields: a pointer to the database and a lock. Two new private ioctl() commands will be added, MNTIOC_GETEXTMNTENT and MNTIOC_GETMNTANY, to ensure that the getmntent(3C) family of functions can be serviced as efficiently as possible. More delicate is the need for every vfs_t present in the in-kernel mnttab to have a high-resolution time stamp indicating its time of creation (not its mount time). The vfs_t is unusual in that it is exposed to unbundled file systems, and is therefore considered dangerous to modify. To this end, following PSARC 2006/270, there now exists a vfs_impl_t, referenced by a vfs_t's vfs_implp, that is designed to accommodate additional fields that would otherwise occupy the vfs_t. As part of this change, the vfs_impl_t will acquire a new field: a high resolution time stamp. The new time stamp in the vfs_t's vfs_impl_t will be initialised in vfs_list_add(), a private function that inserts a mounted vfs_t into the in-kernel mnttab. Because the time stamp will be mandatory, vfs_list_add() will be modified to supply a vfs_t with a vfs_impl_t if it does not already have one. This is significant because unexpected behaviour could occur if an unbundled file system allocates its own vfs_t for insertion into the in-kernel mnttab. Consequently, developers of the unbundled file systems PxFS, VxFS, QFS and MVFS have been approached and have provided confirmation that the proposed changes will be harmless. Developers of OpenAFS have been approached but have not responded. File systems in ON are unaffected. Not really architecture, but rather design review: Why is a high resolution timestamp required? Wouldn't a counter that's incremented every time a file system is mounted or unmounted (across all zones) suffice? -- Glenn From Robert.Harris@sun.com Wed Oct 21 03:32:13 2009 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 n9LAWBws023863 for ; Wed, 21 Oct 2009 03:32:12 -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 n9LAW6Il028832 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 21 Oct 2009 11:32:11 +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 <0KRV0051X19M1T00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Oct 2009 03:32:10 -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 <0KRV005BC19K3SB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Oct 2009 03:32:09 -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 n9LAW8cC007623 for ; Wed, 21 Oct 2009 10:32:08 +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 <0KRU00000YVQ6O00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Oct 2009 11:31:54 +0100 (BST) Received: from [129.156.173.48] ([unknown] [129.156.173.48]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KRV005QO18WE320@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Oct 2009 11:31:44 +0100 (BST) Date: Wed, 21 Oct 2009 11:41:31 +0100 From: Robert Harris Subject: Re: Provide minor private interface modifications to support mntfs [PSARC/2009/566 FastTrack timeout 10/23/2009] Sender: Robert.Harris@sun.com To: Gordon Ross Cc: PSARC-ext@sun.com, Robert.Harris@sun.com Message-id: <4ADEE55B.7090503@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.22 (X11/20090817) Status: RO Content-Length: 2011 Hi Gordon, Gordon Ross wrote: > I'm pleased to see this improvement moving forward. > > Not sure if these are design or interface questions, but: > > Why is the mount time (vfs->vfs_mtime) not suitable for use > in place of the new "created time" you're adding? > > Also, is the "destroyed time" not needed because elements > will be removed from the list immediately upon unmount? > If so, how is the "snapshot behavior" retained for an > existing open performed before some mounts were removed? My implementation has deviated slightly from your original suggestion: rather than use nothing but the existing linked-list of mounted resources, I am creating a second data structure as and when required. This database reflects the state of the in-kernel mnttab that is seen by all currently-open vnodes. On each new open, the in-kernel mnttab and the database are scanned with the goal of updating the latter to reflect the current state of the former. The "destroyed time" is required so that a database element can be killed when the corresponding mounted resource is found to be absent. When updating the database it is necessary to be able either to find the vfs_t that corresponds to a given element or to determine that the vfs_t is no longer present. This requires something akin to a "serial number" that is unique to each vfs_t. The mount time is not suitable for this purpose because it can change over the lifetime of the vfs_t. In addition, a resource remains in place when remounted, and therefore one has to be able to determine not simply whether a particular entry in the mnttab is new but whether it obsoletes a previous one. I chose to use a separate database because the in-kernel mnttab is in some senses fragile. I think that the changes that would be required if one were to use the in-kernel mnttab alone would be considered too invasive. The existing proposal puts almost all of the complexity into mntfs with only a minimal intrusion into other subsystems. Regards, Robert From Robert.Harris@sun.com Wed Oct 21 04:12:47 2009 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 n9LBCjmR024564 for ; Wed, 21 Oct 2009 04:12:46 -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 n9LBCWZu021215 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 21 Oct 2009 19:12:44 +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 <0KRV00A07356FL00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Oct 2009 04:12:42 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRV009MY355SF00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Oct 2009 04:12:42 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9LBCYGu029092; Wed, 21 Oct 2009 11:12:35 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KRV0030031S1Z00@fe-emea-10.sun.com>; Wed, 21 Oct 2009 12:12:29 +0100 (BST) Received: from [129.156.173.48] ([unknown] [129.156.173.48]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KRV0038L34SWN60@fe-emea-10.sun.com>; Wed, 21 Oct 2009 12:12:28 +0100 (BST) Date: Wed, 21 Oct 2009 12:22:17 +0100 From: Robert Harris Subject: Re: 2009/566 [interface modifications to support mntfs] Sender: Robert.Harris@sun.com To: Glenn.Skinner@sun.com Cc: PSARC-ext@sun.com, Robert.Harris@sun.com Message-id: <4ADEEEE9.3030505@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.22 (X11/20090817) Status: RO Content-Length: 761 Hi Glenn, Glenn Skinner wrote: > Not really architecture, but rather design review: Why is a high > resolution timestamp required? Wouldn't a counter that's incremented > every time a file system is mounted or unmounted (across all zones) > suffice? Yes, a counter would suffice and was considered. From a design perspective, the chief advantage of a timespec_t is that it's "human-readable", making observation and diagnosis simpler. From a practical perspective, the existing vfs code already updates a timespec_t with a unique time whenever a file system is mounted or unmounted. It made more sense to ensure that these time stamps were not only unique but also monotonically increasing, and then to use the same source for mntfs. Regards, Robert From Gordon.Ross@Sun.COM Wed Oct 21 07:15:51 2009 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 n9LEFpUk027414 for ; Wed, 21 Oct 2009 07:15:51 -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 n9LEFmJV001477 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 21 Oct 2009 08:15:51 -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 <0KRV00L0TBMEJN00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Oct 2009 07:15:50 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRV00DESBMECN80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Oct 2009 07:15:50 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9LEFnFR026725 for ; Wed, 21 Oct 2009 14:15:49 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KRV00900APETU00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Oct 2009 08:15:49 -0600 (MDT) Received: from [192.168.1.6] ([unknown] [75.67.12.95]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KRV00K8EBMA4400@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Oct 2009 08:15:47 -0600 (MDT) Date: Wed, 21 Oct 2009 10:15:51 -0400 From: Gordon Ross Subject: Re: Provide minor private interface modifications to support mntfs [PSARC/2009/566 FastTrack timeout 10/23/2009] In-reply-to: <4ADEE55B.7090503@sun.com> Sender: Gordon.Ross@Sun.COM To: Robert Harris Cc: PSARC-ext@Sun.COM Message-id: <1256134551.1106.2.camel@dell6300gwr> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4ADEE55B.7090503@sun.com> Status: RO Content-Length: 369 > My implementation has deviated slightly from your original > suggestion: rather than use nothing but the existing > linked-list of mounted resources, I am creating a second > data structure as and when required. This database reflects > the state of the in-kernel mnttab that is seen by all > currently-open vnodes. [...] Sounds reasonable to me. Thanks, Gordon From Richard.Matthews@sun.com Wed Oct 21 10:20:52 2009 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 n9LHKpQd005301 for ; Wed, 21 Oct 2009 10:20:52 -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 n9LHKiNV028877 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 22 Oct 2009 01:20:50 +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 <0KRV0091FK6PCF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Oct 2009 10:20:49 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRV004QXK6NM360@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Oct 2009 10:20:48 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9LHKlTu002514 for ; Wed, 21 Oct 2009 17:20:47 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KRV00C00HLYSY00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Oct 2009 11:20:47 -0600 (MDT) Received: from [129.152.9.14] ([unknown] [129.152.9.14]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KRV00EHEK626R60@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Oct 2009 11:20:35 -0600 (MDT) Date: Wed, 21 Oct 2009 12:20:25 -0500 From: Rick Matthews Subject: Re: Provide minor private interface modifications to support mntfs [PSARC/2009/566 FastTrack timeout 10/23/2009] In-reply-to: <200910161939.n9GJd59M011419@sac.sfbay.sun.com> Sender: Richard.Matthews@sun.com To: PSARC-ext@sun.com, Robert Harris Reply-to: Richard.Matthews@sun.com Message-id: <4ADF42D9.5010203@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910161939.n9GJd59M011419@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 537 This fast track was approved during ARC business today, 10/21/2009. -- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews@sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 ---------------------------------------------------------------------