From tim.haley@oracle.com Tue May 4 15:25:31 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o44MPVVl019759 for ; Tue, 4 May 2010 15:25:31 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o44MPV6J012169 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 4 May 2010 15:25:31 -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 <0L1X006072AJMI00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 May 2010 15:25:31 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1X004X02AIHP00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 May 2010 15:25:30 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o44MPUsW018668 for ; Tue, 04 May 2010 22:25:30 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o44M2bC0031281 for ; Tue, 04 May 2010 22:25:29 +0000 (GMT) Received: from abhmt005.oracle.com by acsmt353.oracle.com with ESMTP id 214386251273011925; Tue, 04 May 2010 15:25:25 -0700 Received: from Giles.local (/10.7.250.184) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 May 2010 15:25:24 -0700 Date: Tue, 04 May 2010 16:25:22 -0600 From: Tim Haley Subject: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] To: PSARC-ext@sun.com Cc: nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com, afshin.salek@oracle.com Message-id: <4BE09ED2.6080505@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BE09ED9.0158:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 6681 I am sponsoring the following fast-track for Afshin Salek. This proposal condenses the pair of syscalls used independently for sharing nfs and cifs into one syscall. Requested binding is Micro/Patch. Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: Unified sharing system call 1.2. Name of Document Author/Supplier: Author: Afshin Salek 1.3 Date of This Document: 04 May, 2010 4. Technical Description 4.1. Details Currently, two system calls and a door are used to publish shares: the nfsys multi-purpose system call to export NFS shares, the sharefs system call to update sharetab and an smbd door to publish SMB shares. libshare has to call the NFS or SMB service once per file system and then it has to call sharefs once per share, which results in 1000's of system calls to publish 1000's of shares. This is a proposal to unify all file sharing via a single system call: sharefs. It is also to support of PSARC 2010/124 (libshare V2), which requires changes to NFS, SMB and ZFS. Publishing all shares via a single system call has several advantages: simplifies libshare, significantly reduces the number of system calls per file system and per share, and improves integration between sharetab and the protocol services. Libshare will call sharefs once per file system (for each protocol that has something to share) with a list of shares and the protocol services will update sharetab by making calls to an in-kernel sharefs API. There will be no user space interface to update sharetab directly. Having the protocol services update the sharetab file has two advantages for libshare and sharefs: it significantly reduces the number of system calls, as explained above, and neither libshare nor sharefs need to perform per share error handling. Each protocol service handles its own [un]publish operations and is responsible for updating sharetab as appropriate. There is no need for the protocol services to return a list of individual share results. The sharefs system call would be changed to accept: a protocol discriminator (NFS or SMB), an operation (publish or unpublish) and an opaque pointer to share data. The opaque data passes transparently through sharefs between the protocol-specific libshare plugin and the protocol service per PSARC 2010/124. The new prototype for sharefs would be of the form: int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, void *data, size_t datalen); Where: typedef enum sharefs_proto { SHAREFS_NFS, SHAREFS_SMB } sharefs_proto_t; typedef enum sharefs_op { SHAREFS_PUBLISH, SHAREFS_UNPUBLISH } sharefs_op_t; Sharefs would be changed from a dynamically loaded module to be part of the kernel. When invoked via the system call, sharefs would dynamically load the NFS or SMB module as required and call the appropriate op (publish or unpublish) registered by the module. The implication being that each protocol service would register an op table with sharefs at load time and that sharefs would provide an in-kernel API to update sharetab. Each protocol service would be responsible for calling the sharetab API as shares are added or removed. The nfssys system call will no longer handle [un]sharing of NFS shares: EXPORTFS support will be removed from nfssys_op. The in-kernel sharefs API would be: typedef int (*sharefs_sop_t)(sharefs_op_t opcode, void *data, size_t datalen); int sharefs_register(sharefs_proto_t proto, sharefs_sop_t sop); Register with sharefs to receive calls to publish or unpublish shares. If sop is a non-NULL pointer the function will be registered as the handler for the specified protocol. If sop is NULL, the handler for the specified protocol will be set to NULL, effectively unregistering the service. Return values: 0 success EINVAL Unknown protocol. typedef struct share { struct share *sh_next; char *sh_path; /* share path */ char *sh_resource; /* share name */ char *sh_fstype; /* protocol string ("nfs" | "smb") */ char *sh_opts; /* share property string */ char *sh_descr; /* share description */ size_t sh_size; } share_t; int sharetab_add(share_t *share); Add an entry to sharetab. Existing entries are replaced with the new entry. All data is copied to sharetab. Return values: 0 success EPERM permision denied int sharetab_remove(share_t *share); Remove an entry from sharetab. The parameter must contain enough information to uniquely identify a sharetab entry. For NFS: sh_fstype and sh_path For SMB: sh_fstype and sh_resource. Return values: 0 success ENOENT entry not found in sharetab EPERM permision denied 4.2 Bug/RFE Number(s): 6850837 4.5 Interfaces _______________________________________________________________ | Exported Interface | Classification | Comments | |________________________|___________________|__________________| | sharefs sys-call | Consolidation | Consumed by | | | Private | libshare | | | | | | sharefs_register | Consolidation | Consumed by NFS | | | Private | SMB modules | | | | | | sharetab_add | Consolidation | sharefs kernel | | sharetab_remove | Private | API to manage | | | | sharetab content | |________________________|___________________|__________________| 4.6. Doc Impact: N/A 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 tim.haley@oracle.com Tue May 4 15:25:33 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o44MPX4C019763 for ; Tue, 4 May 2010 15:25:33 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o44MPW9U000454 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 4 May 2010 17:25:33 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1X00M032AK1100@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 May 2010 15:25:32 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1X00H1K2AKLK30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 May 2010 15:25:32 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o44MPVje028585 for ; Tue, 04 May 2010 22:25:31 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o44M2bC2031281 for ; Tue, 04 May 2010 22:25:30 +0000 (GMT) Received: from abhmt005.oracle.com by acsmt353.oracle.com with ESMTP id 214386251273011925; Tue, 04 May 2010 15:25:25 -0700 Received: from Giles.local (/10.7.250.184) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 May 2010 15:25:24 -0700 Date: Tue, 04 May 2010 16:25:22 -0600 From: Tim Haley Subject: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] To: PSARC-ext@sun.com Cc: nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com, afshin.salek@oracle.com Message-id: <4BE09ED2.6080505@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BE09EDB.00DA:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 6681 I am sponsoring the following fast-track for Afshin Salek. This proposal condenses the pair of syscalls used independently for sharing nfs and cifs into one syscall. Requested binding is Micro/Patch. Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: Unified sharing system call 1.2. Name of Document Author/Supplier: Author: Afshin Salek 1.3 Date of This Document: 04 May, 2010 4. Technical Description 4.1. Details Currently, two system calls and a door are used to publish shares: the nfsys multi-purpose system call to export NFS shares, the sharefs system call to update sharetab and an smbd door to publish SMB shares. libshare has to call the NFS or SMB service once per file system and then it has to call sharefs once per share, which results in 1000's of system calls to publish 1000's of shares. This is a proposal to unify all file sharing via a single system call: sharefs. It is also to support of PSARC 2010/124 (libshare V2), which requires changes to NFS, SMB and ZFS. Publishing all shares via a single system call has several advantages: simplifies libshare, significantly reduces the number of system calls per file system and per share, and improves integration between sharetab and the protocol services. Libshare will call sharefs once per file system (for each protocol that has something to share) with a list of shares and the protocol services will update sharetab by making calls to an in-kernel sharefs API. There will be no user space interface to update sharetab directly. Having the protocol services update the sharetab file has two advantages for libshare and sharefs: it significantly reduces the number of system calls, as explained above, and neither libshare nor sharefs need to perform per share error handling. Each protocol service handles its own [un]publish operations and is responsible for updating sharetab as appropriate. There is no need for the protocol services to return a list of individual share results. The sharefs system call would be changed to accept: a protocol discriminator (NFS or SMB), an operation (publish or unpublish) and an opaque pointer to share data. The opaque data passes transparently through sharefs between the protocol-specific libshare plugin and the protocol service per PSARC 2010/124. The new prototype for sharefs would be of the form: int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, void *data, size_t datalen); Where: typedef enum sharefs_proto { SHAREFS_NFS, SHAREFS_SMB } sharefs_proto_t; typedef enum sharefs_op { SHAREFS_PUBLISH, SHAREFS_UNPUBLISH } sharefs_op_t; Sharefs would be changed from a dynamically loaded module to be part of the kernel. When invoked via the system call, sharefs would dynamically load the NFS or SMB module as required and call the appropriate op (publish or unpublish) registered by the module. The implication being that each protocol service would register an op table with sharefs at load time and that sharefs would provide an in-kernel API to update sharetab. Each protocol service would be responsible for calling the sharetab API as shares are added or removed. The nfssys system call will no longer handle [un]sharing of NFS shares: EXPORTFS support will be removed from nfssys_op. The in-kernel sharefs API would be: typedef int (*sharefs_sop_t)(sharefs_op_t opcode, void *data, size_t datalen); int sharefs_register(sharefs_proto_t proto, sharefs_sop_t sop); Register with sharefs to receive calls to publish or unpublish shares. If sop is a non-NULL pointer the function will be registered as the handler for the specified protocol. If sop is NULL, the handler for the specified protocol will be set to NULL, effectively unregistering the service. Return values: 0 success EINVAL Unknown protocol. typedef struct share { struct share *sh_next; char *sh_path; /* share path */ char *sh_resource; /* share name */ char *sh_fstype; /* protocol string ("nfs" | "smb") */ char *sh_opts; /* share property string */ char *sh_descr; /* share description */ size_t sh_size; } share_t; int sharetab_add(share_t *share); Add an entry to sharetab. Existing entries are replaced with the new entry. All data is copied to sharetab. Return values: 0 success EPERM permision denied int sharetab_remove(share_t *share); Remove an entry from sharetab. The parameter must contain enough information to uniquely identify a sharetab entry. For NFS: sh_fstype and sh_path For SMB: sh_fstype and sh_resource. Return values: 0 success ENOENT entry not found in sharetab EPERM permision denied 4.2 Bug/RFE Number(s): 6850837 4.5 Interfaces _______________________________________________________________ | Exported Interface | Classification | Comments | |________________________|___________________|__________________| | sharefs sys-call | Consolidation | Consumed by | | | Private | libshare | | | | | | sharefs_register | Consolidation | Consumed by NFS | | | Private | SMB modules | | | | | | sharetab_add | Consolidation | sharefs kernel | | sharetab_remove | Private | API to manage | | | | sharetab content | |________________________|___________________|__________________| 4.6. Doc Impact: N/A 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 Pavel.Filipensky@sun.com Wed May 5 07:07:26 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45E7QLs026265 for ; Wed, 5 May 2010 07:07:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o45E7OCk038453 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 08:07:26 -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 <0L1Y00G6R9WDSJ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 07:07:25 -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 <0L1Y00JT49WAGT50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 07:07:22 -0700 (PDT) Received: from fe-emea-13.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 o45E7LlM023842 for ; Wed, 05 May 2010 14:07:21 +0000 (GMT) Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L1Y000009Q7GW00@fe-emea-13.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 15:06:38 +0100 (BST) Received: from [129.157.250.202] ([unknown] [129.157.250.202]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L1Y00LRM9V1LU60@fe-emea-13.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 15:06:37 +0100 (BST) Date: Wed, 05 May 2010 16:04:14 +0200 From: Pavel Filipensky Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE09ED2.6080505@oracle.com> Sender: Pavel.Filipensky@sun.com To: Tim Haley Cc: psarc-ext@sun.com, nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com, afshin.salek@oracle.com Message-id: <4BE17ADE.7010701@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4BE09ED2.6080505@oracle.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090706) Status: RO Content-Length: 6506 In case of the re-sharing (sharing with different options) - will the libshare issue two syscalls - SHAREFS_UNPUBLISH followed by SHAREFS_PUBLISH? Or just a SHAREFS_PUBLISH will be issued? I am asking because the current interfaces are not explicit about the type - they do not specify if it is a share or a re-share. It seems that also this proposal is not explicit about that. SHARE versus RESHARE The interfaces are not explicit about the type - it is a share or a re-share? Neither the caller (libshare) specifies if it is doing a share/re-share, nor the kernel (nfssrv/sharefs) reports back in the return value if it has done a share or a re-share. Pavel On 05/05/10 00:25, Tim Haley wrote: > I am sponsoring the following fast-track for Afshin Salek. This > proposal condenses the pair of syscalls used independently for sharing > nfs and cifs into one syscall. Requested binding is Micro/Patch. > > Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI > This information is Copyright (c) 2010, Oracle and/or its affiliates. > All rights reserved. > 1. Introduction > 1.1. Project/Component Working Name: > Unified sharing system call > 1.2. Name of Document Author/Supplier: > Author: Afshin Salek > 1.3 Date of This Document: > 04 May, 2010 > > 4. Technical Description > > 4.1. Details > > Currently, two system calls and a door are used to publish shares: the > nfsys multi-purpose system call to export NFS shares, the sharefs system > call to update sharetab and an smbd door to publish SMB shares. libshare > has to call the NFS or SMB service once per file system and then it has > to call sharefs once per share, which results in 1000's of system calls > to publish 1000's of shares. > > This is a proposal to unify all file sharing via a single system call: > sharefs. It is also to support of PSARC 2010/124 (libshare V2), which > requires changes to NFS, SMB and ZFS. > > Publishing all shares via a single system call has several advantages: > simplifies libshare, significantly reduces the number of system calls > per file system and per share, and improves integration between sharetab > and the protocol services. Libshare will call sharefs once per file > system (for each protocol that has something to share) with a list of > shares and the protocol services will update sharetab by making calls > to an in-kernel sharefs API. There will be no user space interface to > update sharetab directly. > > Having the protocol services update the sharetab file has two advantages > for libshare and sharefs: it significantly reduces the number of system > calls, as explained above, and neither libshare nor sharefs need to > perform per share error handling. Each protocol service handles its own > [un]publish operations and is responsible for updating sharetab as > appropriate. There is no need for the protocol services to return a list > of individual share results. > > The sharefs system call would be changed to accept: a protocol > discriminator > (NFS or SMB), an operation (publish or unpublish) and an opaque > pointer to > share data. The opaque data passes transparently through sharefs between > the protocol-specific libshare plugin and the protocol service per PSARC > 2010/124. The new prototype for sharefs would be of the form: > > int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, > void *data, size_t datalen); > > Where: > > typedef enum sharefs_proto { > SHAREFS_NFS, > SHAREFS_SMB > } sharefs_proto_t; > > typedef enum sharefs_op { > SHAREFS_PUBLISH, > SHAREFS_UNPUBLISH > } sharefs_op_t; > > Sharefs would be changed from a dynamically loaded module to be part of > the kernel. When invoked via the system call, sharefs would dynamically > load the NFS or SMB module as required and call the appropriate op > (publish or unpublish) registered by the module. The implication being > that each protocol service would register an op table with sharefs at > load time and that sharefs would provide an in-kernel API to update > sharetab. Each protocol service would be responsible for calling the > sharetab API as shares are added or removed. > > The nfssys system call will no longer handle [un]sharing of NFS shares: > EXPORTFS support will be removed from nfssys_op. > > The in-kernel sharefs API would be: > > typedef int (*sharefs_sop_t)(sharefs_op_t opcode, > void *data, size_t datalen); > > int sharefs_register(sharefs_proto_t proto, sharefs_sop_t sop); > > Register with sharefs to receive calls to publish or unpublish > shares. If sop is a non-NULL pointer the function will > be registered as the handler for the specified protocol. > If sop is NULL, the handler for the specified protocol > will be set to NULL, effectively unregistering the service. > > Return values: > 0 success > EINVAL Unknown protocol. > > typedef struct share { > struct share *sh_next; > char *sh_path; /* share path */ > char *sh_resource; /* share name */ > char *sh_fstype; /* protocol string ("nfs" | "smb") */ > char *sh_opts; /* share property string */ > char *sh_descr; /* share description */ > size_t sh_size; > } share_t; > > int sharetab_add(share_t *share); > > Add an entry to sharetab. Existing entries are replaced > with the new entry. All data is copied to sharetab. > > Return values: > 0 success > EPERM permision denied > > int sharetab_remove(share_t *share); > > Remove an entry from sharetab. The parameter must contain > enough information to uniquely identify a sharetab entry. > For NFS: sh_fstype and sh_path > For SMB: sh_fstype and sh_resource. > > Return values: > 0 success > ENOENT entry not found in sharetab > EPERM permision denied > > 4.2 Bug/RFE Number(s): > > 6850837 > > 4.5 Interfaces > > _______________________________________________________________ > | Exported Interface | Classification | Comments | > |________________________|___________________|__________________| > | sharefs sys-call | Consolidation | Consumed by | > | | Private | libshare | > | | | | > | sharefs_register | Consolidation | Consumed by NFS | > | | Private | SMB modules | > | | | | > | sharetab_add | Consolidation | sharefs kernel | > | sharetab_remove | Private | API to manage | > | | | sharetab content | > |________________________|___________________|__________________| > > 4.6. Doc Impact: > > N/A > > 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 tom.haynes@oracle.com Wed May 5 08:08:34 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45F8Y9F027431 for ; Wed, 5 May 2010 08:08:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45F8XhT020233 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 10:08:33 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y00J05CQ9PB00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 08:08:33 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y00BI1CQ9SLC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 08:08:33 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45F8We3005261 for ; Wed, 05 May 2010 15:08:32 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45ElmCt017886 for ; Wed, 05 May 2010 15:08:29 +0000 (GMT) Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 216480071273072106; Wed, 05 May 2010 08:08:26 -0700 Received: from [129.150.48.148] (/129.150.48.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 08:08:24 -0700 Date: Wed, 05 May 2010 10:08:53 -0500 From: Tom Haynes Subject: Re: [Fwd: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010]] In-reply-to: <4BE175B1.5050602@oracle.com> To: Rich Brown , PSARC-ext@sun.com Cc: Tim Haley , nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com, afshin.salek@oracle.com Message-id: <4BE18A05.8070602@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BE189ED.013E:SCFMA4539814,ss=1,fgs=0 References: <4BE175B1.5050602@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 590 > typedef struct share { > struct share *sh_next; > char *sh_path; /* share path */ > char *sh_resource; /* share name */ > char *sh_fstype; /* protocol string ("nfs" | > "smb") */ > char *sh_opts; /* share property string */ > char *sh_descr; /* share description */ > size_t sh_size; > } share_t; > sh_fstype is not an appropriate name for the contents. The contents are a protocol and not a filesystem. sh_proto? From tom.haynes@oracle.com Wed May 5 08:08:35 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45F8ZBK027435 for ; Wed, 5 May 2010 08:08:35 -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 o45F8WTw025710 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 08:08:34 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y00801CQAJU00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 09:08:34 -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 <0L1Y008FECQA3500@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 09:08:34 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45F8XrU004989 for ; Wed, 05 May 2010 15:08:34 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45ElmCv017886 for ; Wed, 05 May 2010 15:08:33 +0000 (GMT) Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 216480071273072106; Wed, 05 May 2010 08:08:26 -0700 Received: from [129.150.48.148] (/129.150.48.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 08:08:24 -0700 Date: Wed, 05 May 2010 10:08:53 -0500 From: Tom Haynes Subject: Re: [Fwd: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010]] In-reply-to: <4BE175B1.5050602@oracle.com> To: Rich Brown , PSARC-ext@sun.com Cc: Tim Haley , nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com, afshin.salek@oracle.com Message-id: <4BE18A05.8070602@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BE189F1.017C:SCFMA4539814,ss=1,fgs=0 References: <4BE175B1.5050602@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 590 > typedef struct share { > struct share *sh_next; > char *sh_path; /* share path */ > char *sh_resource; /* share name */ > char *sh_fstype; /* protocol string ("nfs" | > "smb") */ > char *sh_opts; /* share property string */ > char *sh_descr; /* share description */ > size_t sh_size; > } share_t; > sh_fstype is not an appropriate name for the contents. The contents are a protocol and not a filesystem. sh_proto? From Afshin.Salek@Oracle.com Wed May 5 12:30:21 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45JULRN005037 for ; Wed, 5 May 2010 12:30:21 -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 o45JUJTj028104 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 12:30:20 -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 <0L1Y0060JOUKNO00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 13:30:20 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y00845OUJ36E0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 13:30:19 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o45JUJ02000453 for ; Wed, 05 May 2010 19:30:19 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45JHA3G000544 for ; Wed, 05 May 2010 19:30:18 +0000 (GMT) Received: from abhmt016.oracle.com by acsmt353.oracle.com with ESMTP id 240125061273087816; Wed, 05 May 2010 12:30:16 -0700 Received: from [10.1.106.212] (/10.1.106.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 12:30:16 -0700 Date: Wed, 05 May 2010 12:30:05 -0700 From: Afshin Salek Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE17ADE.7010701@sun.com> To: Pavel Filipensky Cc: Tim Haley , PSARC-ext@sun.com, nfs-instance_ww@Oracle.com, libshare-team_ww@Oracle.com, mark.shellenbaum@Oracle.com Message-id: <4BE1C73D.9000104@Oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BE1C74A.0141:SCFMA4539814,ss=1,pt=DBB_65838,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE17ADE.7010701@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 6892 This might have been specified in libshare V2 design document but the current behavior is unpublish followed by publish. Afshin On 05/ 5/10 07:04 AM, Pavel Filipensky wrote: > In case of the re-sharing (sharing with different options) - will the > libshare > issue two syscalls - SHAREFS_UNPUBLISH followed by SHAREFS_PUBLISH? > Or just a SHAREFS_PUBLISH will be issued? > > I am asking because the current interfaces are not explicit about the type > - they do not specify if it is a share or a re-share. > It seems that also this proposal is not explicit about that. > > > SHARE versus RESHARE > > The interfaces are not explicit about the type - it is a share or a re-share? > Neither the caller (libshare) specifies if it is doing a share/re-share, > nor the kernel (nfssrv/sharefs) reports back in the return value if it has > done a share or a re-share. > > > > Pavel > > > On 05/05/10 00:25, Tim Haley wrote: >> I am sponsoring the following fast-track for Afshin Salek. This >> proposal condenses the pair of syscalls used independently for sharing >> nfs and cifs into one syscall. Requested binding is Micro/Patch. >> >> Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI >> This information is Copyright (c) 2010, Oracle and/or its affiliates. >> All rights reserved. >> 1. Introduction >> 1.1. Project/Component Working Name: >> Unified sharing system call >> 1.2. Name of Document Author/Supplier: >> Author: Afshin Salek >> 1.3 Date of This Document: >> 04 May, 2010 >> >> 4. Technical Description >> >> 4.1. Details >> >> Currently, two system calls and a door are used to publish shares: the >> nfsys multi-purpose system call to export NFS shares, the sharefs system >> call to update sharetab and an smbd door to publish SMB shares. libshare >> has to call the NFS or SMB service once per file system and then it has >> to call sharefs once per share, which results in 1000's of system calls >> to publish 1000's of shares. >> >> This is a proposal to unify all file sharing via a single system call: >> sharefs. It is also to support of PSARC 2010/124 (libshare V2), which >> requires changes to NFS, SMB and ZFS. >> >> Publishing all shares via a single system call has several advantages: >> simplifies libshare, significantly reduces the number of system calls >> per file system and per share, and improves integration between sharetab >> and the protocol services. Libshare will call sharefs once per file >> system (for each protocol that has something to share) with a list of >> shares and the protocol services will update sharetab by making calls >> to an in-kernel sharefs API. There will be no user space interface to >> update sharetab directly. >> >> Having the protocol services update the sharetab file has two advantages >> for libshare and sharefs: it significantly reduces the number of system >> calls, as explained above, and neither libshare nor sharefs need to >> perform per share error handling. Each protocol service handles its own >> [un]publish operations and is responsible for updating sharetab as >> appropriate. There is no need for the protocol services to return a list >> of individual share results. >> >> The sharefs system call would be changed to accept: a protocol >> discriminator >> (NFS or SMB), an operation (publish or unpublish) and an opaque >> pointer to >> share data. The opaque data passes transparently through sharefs between >> the protocol-specific libshare plugin and the protocol service per PSARC >> 2010/124. The new prototype for sharefs would be of the form: >> >> int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, >> void *data, size_t datalen); >> >> Where: >> >> typedef enum sharefs_proto { >> SHAREFS_NFS, >> SHAREFS_SMB >> } sharefs_proto_t; >> >> typedef enum sharefs_op { >> SHAREFS_PUBLISH, >> SHAREFS_UNPUBLISH >> } sharefs_op_t; >> >> Sharefs would be changed from a dynamically loaded module to be part of >> the kernel. When invoked via the system call, sharefs would dynamically >> load the NFS or SMB module as required and call the appropriate op >> (publish or unpublish) registered by the module. The implication being >> that each protocol service would register an op table with sharefs at >> load time and that sharefs would provide an in-kernel API to update >> sharetab. Each protocol service would be responsible for calling the >> sharetab API as shares are added or removed. >> >> The nfssys system call will no longer handle [un]sharing of NFS shares: >> EXPORTFS support will be removed from nfssys_op. >> >> The in-kernel sharefs API would be: >> >> typedef int (*sharefs_sop_t)(sharefs_op_t opcode, >> void *data, size_t datalen); >> >> int sharefs_register(sharefs_proto_t proto, sharefs_sop_t sop); >> >> Register with sharefs to receive calls to publish or unpublish >> shares. If sop is a non-NULL pointer the function will >> be registered as the handler for the specified protocol. >> If sop is NULL, the handler for the specified protocol >> will be set to NULL, effectively unregistering the service. >> >> Return values: >> 0 success >> EINVAL Unknown protocol. >> >> typedef struct share { >> struct share *sh_next; >> char *sh_path; /* share path */ >> char *sh_resource; /* share name */ >> char *sh_fstype; /* protocol string ("nfs" | "smb") */ >> char *sh_opts; /* share property string */ >> char *sh_descr; /* share description */ >> size_t sh_size; >> } share_t; >> >> int sharetab_add(share_t *share); >> >> Add an entry to sharetab. Existing entries are replaced >> with the new entry. All data is copied to sharetab. >> >> Return values: >> 0 success >> EPERM permision denied >> >> int sharetab_remove(share_t *share); >> >> Remove an entry from sharetab. The parameter must contain >> enough information to uniquely identify a sharetab entry. >> For NFS: sh_fstype and sh_path >> For SMB: sh_fstype and sh_resource. >> >> Return values: >> 0 success >> ENOENT entry not found in sharetab >> EPERM permision denied >> >> 4.2 Bug/RFE Number(s): >> >> 6850837 >> >> 4.5 Interfaces >> >> _______________________________________________________________ >> | Exported Interface | Classification | Comments | >> |________________________|___________________|__________________| >> | sharefs sys-call | Consolidation | Consumed by | >> | | Private | libshare | >> | | | | >> | sharefs_register | Consolidation | Consumed by NFS | >> | | Private | SMB modules | >> | | | | >> | sharetab_add | Consolidation | sharefs kernel | >> | sharetab_remove | Private | API to manage | >> | | | sharetab content | >> |________________________|___________________|__________________| >> >> 4.6. Doc Impact: >> >> N/A >> >> 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 Afshin.Salek@Oracle.com Wed May 5 12:30:22 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45JUMYX005065 for ; Wed, 5 May 2010 12:30:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45JUM3o028142 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 12:30:22 -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 <0L1Y00355OUMYN00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 12:30:22 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y00LWROUKHXE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 12:30:20 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45JUJ2a024469 for ; Wed, 05 May 2010 19:30:19 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45JHA3I000544 for ; Wed, 05 May 2010 19:30:19 +0000 (GMT) Received: from abhmt016.oracle.com by acsmt353.oracle.com with ESMTP id 240125061273087816; Wed, 05 May 2010 12:30:16 -0700 Received: from [10.1.106.212] (/10.1.106.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 12:30:16 -0700 Date: Wed, 05 May 2010 12:30:05 -0700 From: Afshin Salek Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE17ADE.7010701@sun.com> To: Pavel Filipensky Cc: Tim Haley , PSARC-ext@sun.com, nfs-instance_ww@Oracle.com, libshare-team_ww@Oracle.com, mark.shellenbaum@Oracle.com Message-id: <4BE1C73D.9000104@Oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BE1C74B.00C8:SCFMA4539814,ss=1,pt=DBB_65838,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE17ADE.7010701@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 6892 This might have been specified in libshare V2 design document but the current behavior is unpublish followed by publish. Afshin On 05/ 5/10 07:04 AM, Pavel Filipensky wrote: > In case of the re-sharing (sharing with different options) - will the > libshare > issue two syscalls - SHAREFS_UNPUBLISH followed by SHAREFS_PUBLISH? > Or just a SHAREFS_PUBLISH will be issued? > > I am asking because the current interfaces are not explicit about the type > - they do not specify if it is a share or a re-share. > It seems that also this proposal is not explicit about that. > > > SHARE versus RESHARE > > The interfaces are not explicit about the type - it is a share or a re-share? > Neither the caller (libshare) specifies if it is doing a share/re-share, > nor the kernel (nfssrv/sharefs) reports back in the return value if it has > done a share or a re-share. > > > > Pavel > > > On 05/05/10 00:25, Tim Haley wrote: >> I am sponsoring the following fast-track for Afshin Salek. This >> proposal condenses the pair of syscalls used independently for sharing >> nfs and cifs into one syscall. Requested binding is Micro/Patch. >> >> Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI >> This information is Copyright (c) 2010, Oracle and/or its affiliates. >> All rights reserved. >> 1. Introduction >> 1.1. Project/Component Working Name: >> Unified sharing system call >> 1.2. Name of Document Author/Supplier: >> Author: Afshin Salek >> 1.3 Date of This Document: >> 04 May, 2010 >> >> 4. Technical Description >> >> 4.1. Details >> >> Currently, two system calls and a door are used to publish shares: the >> nfsys multi-purpose system call to export NFS shares, the sharefs system >> call to update sharetab and an smbd door to publish SMB shares. libshare >> has to call the NFS or SMB service once per file system and then it has >> to call sharefs once per share, which results in 1000's of system calls >> to publish 1000's of shares. >> >> This is a proposal to unify all file sharing via a single system call: >> sharefs. It is also to support of PSARC 2010/124 (libshare V2), which >> requires changes to NFS, SMB and ZFS. >> >> Publishing all shares via a single system call has several advantages: >> simplifies libshare, significantly reduces the number of system calls >> per file system and per share, and improves integration between sharetab >> and the protocol services. Libshare will call sharefs once per file >> system (for each protocol that has something to share) with a list of >> shares and the protocol services will update sharetab by making calls >> to an in-kernel sharefs API. There will be no user space interface to >> update sharetab directly. >> >> Having the protocol services update the sharetab file has two advantages >> for libshare and sharefs: it significantly reduces the number of system >> calls, as explained above, and neither libshare nor sharefs need to >> perform per share error handling. Each protocol service handles its own >> [un]publish operations and is responsible for updating sharetab as >> appropriate. There is no need for the protocol services to return a list >> of individual share results. >> >> The sharefs system call would be changed to accept: a protocol >> discriminator >> (NFS or SMB), an operation (publish or unpublish) and an opaque >> pointer to >> share data. The opaque data passes transparently through sharefs between >> the protocol-specific libshare plugin and the protocol service per PSARC >> 2010/124. The new prototype for sharefs would be of the form: >> >> int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, >> void *data, size_t datalen); >> >> Where: >> >> typedef enum sharefs_proto { >> SHAREFS_NFS, >> SHAREFS_SMB >> } sharefs_proto_t; >> >> typedef enum sharefs_op { >> SHAREFS_PUBLISH, >> SHAREFS_UNPUBLISH >> } sharefs_op_t; >> >> Sharefs would be changed from a dynamically loaded module to be part of >> the kernel. When invoked via the system call, sharefs would dynamically >> load the NFS or SMB module as required and call the appropriate op >> (publish or unpublish) registered by the module. The implication being >> that each protocol service would register an op table with sharefs at >> load time and that sharefs would provide an in-kernel API to update >> sharetab. Each protocol service would be responsible for calling the >> sharetab API as shares are added or removed. >> >> The nfssys system call will no longer handle [un]sharing of NFS shares: >> EXPORTFS support will be removed from nfssys_op. >> >> The in-kernel sharefs API would be: >> >> typedef int (*sharefs_sop_t)(sharefs_op_t opcode, >> void *data, size_t datalen); >> >> int sharefs_register(sharefs_proto_t proto, sharefs_sop_t sop); >> >> Register with sharefs to receive calls to publish or unpublish >> shares. If sop is a non-NULL pointer the function will >> be registered as the handler for the specified protocol. >> If sop is NULL, the handler for the specified protocol >> will be set to NULL, effectively unregistering the service. >> >> Return values: >> 0 success >> EINVAL Unknown protocol. >> >> typedef struct share { >> struct share *sh_next; >> char *sh_path; /* share path */ >> char *sh_resource; /* share name */ >> char *sh_fstype; /* protocol string ("nfs" | "smb") */ >> char *sh_opts; /* share property string */ >> char *sh_descr; /* share description */ >> size_t sh_size; >> } share_t; >> >> int sharetab_add(share_t *share); >> >> Add an entry to sharetab. Existing entries are replaced >> with the new entry. All data is copied to sharetab. >> >> Return values: >> 0 success >> EPERM permision denied >> >> int sharetab_remove(share_t *share); >> >> Remove an entry from sharetab. The parameter must contain >> enough information to uniquely identify a sharetab entry. >> For NFS: sh_fstype and sh_path >> For SMB: sh_fstype and sh_resource. >> >> Return values: >> 0 success >> ENOENT entry not found in sharetab >> EPERM permision denied >> >> 4.2 Bug/RFE Number(s): >> >> 6850837 >> >> 4.5 Interfaces >> >> _______________________________________________________________ >> | Exported Interface | Classification | Comments | >> |________________________|___________________|__________________| >> | sharefs sys-call | Consolidation | Consumed by | >> | | Private | libshare | >> | | | | >> | sharefs_register | Consolidation | Consumed by NFS | >> | | Private | SMB modules | >> | | | | >> | sharetab_add | Consolidation | sharefs kernel | >> | sharetab_remove | Private | API to manage | >> | | | sharetab content | >> |________________________|___________________|__________________| >> >> 4.6. Doc Impact: >> >> N/A >> >> 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 Afshin.Salek@Oracle.com Wed May 5 12:31:55 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45JVsm0005131 for ; Wed, 5 May 2010 12:31:55 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45JVsOq028851 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 12:31:54 -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 <0L1Y0041VOX6BH00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 12:31:54 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y00LP7OX6HZC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 12:31:54 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45JVr5V029848 for ; Wed, 05 May 2010 19:31:53 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45JOOoa006487 for ; Wed, 05 May 2010 19:31:53 +0000 (GMT) Received: from abhmt008.oracle.com by acsmt354.oracle.com with ESMTP id 240130841273087909; Wed, 05 May 2010 12:31:49 -0700 Received: from [10.1.106.212] (/10.1.106.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 12:31:49 -0700 Date: Wed, 05 May 2010 12:31:38 -0700 From: Afshin Salek Subject: Re: [Fwd: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010]] In-reply-to: <4BE18A05.8070602@oracle.com> To: Tom Haynes Cc: Rich Brown , PSARC-ext@sun.com, Tim Haley , nfs-instance_ww@Oracle.com, libshare-team_ww@Oracle.com, mark.shellenbaum@Oracle.com Message-id: <4BE1C79A.7020809@Oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BE1C7A9.00CD:SCFMA4539814,ss=1,fgs=0 References: <4BE175B1.5050602@oracle.com> <4BE18A05.8070602@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 618 share_t is an existing structure, I didn't change anything but I could make such changes as part of implementing this proposal. Afshin On 05/ 5/10 08:08 AM, Tom Haynes wrote: > >> typedef struct share { >> struct share *sh_next; >> char *sh_path; /* share path */ >> char *sh_resource; /* share name */ >> char *sh_fstype; /* protocol string ("nfs" | >> "smb") */ >> char *sh_opts; /* share property string */ >> char *sh_descr; /* share description */ >> size_t sh_size; >> } share_t; >> > > sh_fstype is not an appropriate name for the contents. > > The contents are a protocol and not a filesystem. > > sh_proto? From Afshin.Salek@Oracle.com Wed May 5 12:31:56 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45JVuHe005168 for ; Wed, 5 May 2010 12:31:56 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45JVtUs013839 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 14:31:56 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y00429OX8BH00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 12:31:56 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y00LPDOX6HZC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 12:31:54 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45JVsxk004120 for ; Wed, 05 May 2010 19:31:54 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45JOOoc006487 for ; Wed, 05 May 2010 19:31:53 +0000 (GMT) Received: from abhmt008.oracle.com by acsmt354.oracle.com with ESMTP id 240130841273087909; Wed, 05 May 2010 12:31:49 -0700 Received: from [10.1.106.212] (/10.1.106.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 12:31:49 -0700 Date: Wed, 05 May 2010 12:31:38 -0700 From: Afshin Salek Subject: Re: [Fwd: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010]] In-reply-to: <4BE18A05.8070602@oracle.com> To: Tom Haynes Cc: Rich Brown , PSARC-ext@sun.com, Tim Haley , nfs-instance_ww@Oracle.com, libshare-team_ww@Oracle.com, mark.shellenbaum@Oracle.com Message-id: <4BE1C79A.7020809@Oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BE1C7A9.01D4:SCFMA4539814,ss=1,fgs=0 References: <4BE175B1.5050602@oracle.com> <4BE18A05.8070602@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 618 share_t is an existing structure, I didn't change anything but I could make such changes as part of implementing this proposal. Afshin On 05/ 5/10 08:08 AM, Tom Haynes wrote: > >> typedef struct share { >> struct share *sh_next; >> char *sh_path; /* share path */ >> char *sh_resource; /* share name */ >> char *sh_fstype; /* protocol string ("nfs" | >> "smb") */ >> char *sh_opts; /* share property string */ >> char *sh_descr; /* share description */ >> size_t sh_size; >> } share_t; >> > > sh_fstype is not an appropriate name for the contents. > > The contents are a protocol and not a filesystem. > > sh_proto? From Nicolas.Williams@oracle.com Wed May 5 12:39:24 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45JdNFQ005341 for ; Wed, 5 May 2010 12:39:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o45JdL5m053373 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 13:39:23 -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 <0L1Y0070LP9NDI00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 13:39:23 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y0085NP9M36F0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 13:39:22 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45JdLs8002893 for ; Wed, 05 May 2010 19:39:22 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45JX2OS015702 for ; Wed, 05 May 2010 19:39:21 +0000 (GMT) Received: from abhmt008.oracle.com by acsmt355.oracle.com with ESMTP id 240151991273088360; Wed, 05 May 2010 12:39:20 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 12:39:20 -0700 Date: Wed, 05 May 2010 14:39:15 -0500 From: Nicolas Williams Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE1C73D.9000104@Oracle.com> To: Afshin Salek Cc: Pavel Filipensky , Tim Haley , PSARC-ext@sun.com, nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com Message-id: <20100505193915.GD9429@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BE1C969.00E4:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE17ADE.7010701@sun.com> <4BE1C73D.9000104@Oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 447 On Wed, May 05, 2010 at 12:30:05PM -0700, Afshin Salek wrote: > This might have been specified in libshare V2 design document but the > current behavior is unpublish followed by publish. Couldn't that cause an outtage? If the re-share is just to change some sharing option, there should be no hiccup for clients not affected by the option change (e.g., security mode changes, where NFSv4 clients may be able to recover automatically). Nico -- From Nicolas.Williams@oracle.com Wed May 5 12:39:25 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45JdPsd005345 for ; Wed, 5 May 2010 12:39:25 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o45JdO19053423 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 13:39:25 -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 <0L1Y0060HP9O3Z00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 12:39:24 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y00LRKP9MHZD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 12:39:23 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45JdMT6029790 for ; Wed, 05 May 2010 19:39:22 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45JX2OU015702 for ; Wed, 05 May 2010 19:39:22 +0000 (GMT) Received: from abhmt008.oracle.com by acsmt355.oracle.com with ESMTP id 240151991273088360; Wed, 05 May 2010 12:39:20 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 12:39:20 -0700 Date: Wed, 05 May 2010 14:39:15 -0500 From: Nicolas Williams Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE1C73D.9000104@Oracle.com> To: Afshin Salek Cc: Pavel Filipensky , Tim Haley , PSARC-ext@sun.com, nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com Message-id: <20100505193915.GD9429@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BE1C96A.006C:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE17ADE.7010701@sun.com> <4BE1C73D.9000104@Oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 447 On Wed, May 05, 2010 at 12:30:05PM -0700, Afshin Salek wrote: > This might have been specified in libshare V2 design document but the > current behavior is unpublish followed by publish. Couldn't that cause an outtage? If the re-share is just to change some sharing option, there should be no hiccup for clients not affected by the option change (e.g., security mode changes, where NFSv4 clients may be able to recover automatically). Nico -- From alan.wright@oracle.com Wed May 5 12:53:35 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45JrZj2005486 for ; Wed, 5 May 2010 12:53:35 -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 o45JrZIC008119 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 12:53:35 -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 <0L1Y00801PXBKD00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 13:53:35 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y007GLPXASX10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 13:53:34 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45JrYFL013272 for ; Wed, 05 May 2010 19:53:34 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45IslxR007694 for ; Wed, 05 May 2010 19:53:33 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 217334781273089211; Wed, 05 May 2010 12:53:31 -0700 Received: from [10.1.106.211] (/10.1.106.211) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 12:53:30 -0700 Date: Wed, 05 May 2010 12:52:39 -0700 From: Alan Wright Subject: Re: [Fwd: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010]] In-reply-to: <4BE18A05.8070602@oracle.com> To: Tom Haynes Cc: Rich Brown , PSARC-ext@sun.com, Tim Haley , nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com, afshin.salek@oracle.com Message-id: <4BE1CC87.2070206@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BE1CCBD.0161:SCFMA4539814,ss=1,fgs=0 References: <4BE175B1.5050602@oracle.com> <4BE18A05.8070602@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Thunderbird/3.0.1 Status: RO Content-Length: 654 On 05/ 5/10 08:08 AM, Tom Haynes wrote: > >> typedef struct share { >> struct share *sh_next; >> char *sh_path; /* share path */ >> char *sh_resource; /* share name */ >> char *sh_fstype; /* protocol string ("nfs" | >> "smb") */ >> char *sh_opts; /* share property string */ >> char *sh_descr; /* share description */ >> size_t sh_size; >> } share_t; >> > > sh_fstype is not an appropriate name for the contents. > > The contents are a protocol and not a filesystem. > > sh_proto? This is actually an existing structure. see: uts/common/sharefs/share.h And the layout botch is my fault. No changes are planned to the existing Nevada structure. Alan From alan.wright@oracle.com Wed May 5 12:53:36 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45JrZxt005490 for ; Wed, 5 May 2010 12:53:36 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o45JrZJM061700 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 13:53:35 -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 <0L1Y00803PXBKE00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 13:53:35 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y007FGPXBSV10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 13:53:35 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o45JrY2B012454 for ; Wed, 05 May 2010 19:53:35 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45IslxT007694 for ; Wed, 05 May 2010 19:53:34 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 217334781273089211; Wed, 05 May 2010 12:53:31 -0700 Received: from [10.1.106.211] (/10.1.106.211) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 12:53:30 -0700 Date: Wed, 05 May 2010 12:52:39 -0700 From: Alan Wright Subject: Re: [Fwd: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010]] In-reply-to: <4BE18A05.8070602@oracle.com> To: Tom Haynes Cc: Rich Brown , PSARC-ext@sun.com, Tim Haley , nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com, afshin.salek@oracle.com Message-id: <4BE1CC87.2070206@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BE1CCBE.00D7:SCFMA4539814,ss=1,fgs=0 References: <4BE175B1.5050602@oracle.com> <4BE18A05.8070602@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Thunderbird/3.0.1 Status: RO Content-Length: 654 On 05/ 5/10 08:08 AM, Tom Haynes wrote: > >> typedef struct share { >> struct share *sh_next; >> char *sh_path; /* share path */ >> char *sh_resource; /* share name */ >> char *sh_fstype; /* protocol string ("nfs" | >> "smb") */ >> char *sh_opts; /* share property string */ >> char *sh_descr; /* share description */ >> size_t sh_size; >> } share_t; >> > > sh_fstype is not an appropriate name for the contents. > > The contents are a protocol and not a filesystem. > > sh_proto? This is actually an existing structure. see: uts/common/sharefs/share.h And the layout botch is my fault. No changes are planned to the existing Nevada structure. Alan From tom.haynes@oracle.com Wed May 5 13:47:21 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45KlKeV006835 for ; Wed, 5 May 2010 13:47:21 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45KlKDW021074 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 15:47:20 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y0000XSEWR900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 13:47:20 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y008L5SEVIT50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 13:47:19 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45KlIXp005545 for ; Wed, 05 May 2010 20:47:19 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45Jww07028615 for ; Wed, 05 May 2010 20:47:18 +0000 (GMT) Received: from abhmt004.oracle.com by acsmt355.oracle.com with ESMTP id 240352531273092437; Wed, 05 May 2010 13:47:17 -0700 Received: from [129.150.48.148] (/129.150.48.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 13:47:14 -0700 Date: Wed, 05 May 2010 15:47:43 -0500 From: Tom Haynes Subject: Re: [Fwd: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010]] In-reply-to: <4BE1CC87.2070206@oracle.com> To: Alan Wright Cc: Rich Brown , PSARC-ext@sun.com, Tim Haley , nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com, afshin.salek@oracle.com Message-id: <4BE1D96F.8000308@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BE1D956.0127:SCFMA4539814,ss=1,fgs=0 References: <4BE175B1.5050602@oracle.com> <4BE18A05.8070602@oracle.com> <4BE1CC87.2070206@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 2367 On 05/ 5/10 02:52 PM, Alan Wright wrote: > On 05/ 5/10 08:08 AM, Tom Haynes wrote: >> >>> typedef struct share { >>> struct share *sh_next; >>> char *sh_path; /* share path */ >>> char *sh_resource; /* share name */ >>> char *sh_fstype; /* protocol string ("nfs" | >>> "smb") */ >>> char *sh_opts; /* share property string */ >>> char *sh_descr; /* share description */ >>> size_t sh_size; >>> } share_t; >>> >> >> sh_fstype is not an appropriate name for the contents. >> >> The contents are a protocol and not a filesystem. >> >> sh_proto? > > This is actually an existing structure. see: > > uts/common/sharefs/share.h > > And the layout botch is my fault. No changes are planned > to the existing Nevada structure. > > Alan Yeah, I'm very familiar with that directory. I dunno why we didn't fix this issue when we first did sharefs. My guess is back then we talked in terms of fstypes and not protocols. I.e., look at the allowed types to share(1M): [th199096@aus1500-home sharefs]> more /etc/dfs/fstypes nfs NFS Utilities autofs AUTOFS Utilities cachefs CACHEFS Utilities smbfs CIFS Utilities Which brings up the point that share(1M) specifies that the allowed values in sh_fstype are those defined in fstypes(4). This also occurs with sharetab(4). So those would be "nfs" and "smbfs". Not "nfs" and "smb". Are we changing the parameters to the share command? Or actually to the Distributed File System (DFS) Administration commands? Or does there already exist means for making this mapping occur? (Yes, it is coded in sharemgr.) I find that the intent laid out in the man pages is confusing with the intent laid out in this case. And while some of the existing code uses sh_fstype to mean a protocol, some of it uses it to mean a filesystem type. This case makes a change in what goes into sh_fstype and uses the terminology "protocol" and not "filesystem". But it also exposes that the input and output to the DFS commands do not match the documentation. If we want to retain fstypes, we need to change the proto argument in all of the code to use "smbfs" and not "smb". If we want to use protocols, we need to update the man pages to the fact that sharetab(4) and friends are no longer relying on fstypes(4) to define "fstype" and indeed we ought to change "fstype" to be "proto" in the man pages and "sh_fstype" to be "sh_proto" in the code. From tom.haynes@oracle.com Wed May 5 13:47:21 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45KlLfP006836 for ; Wed, 5 May 2010 13:47:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o45KlKcG026668 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 14:47:20 -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 <0L1Y00C19SEW3J00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 13:47:20 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y00760SEWY740@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 13:47:20 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45KlJ0u001634 for ; Wed, 05 May 2010 20:47:19 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45Jww09028615 for ; Wed, 05 May 2010 20:47:19 +0000 (GMT) Received: from abhmt004.oracle.com by acsmt355.oracle.com with ESMTP id 240352531273092437; Wed, 05 May 2010 13:47:17 -0700 Received: from [129.150.48.148] (/129.150.48.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 13:47:14 -0700 Date: Wed, 05 May 2010 15:47:43 -0500 From: Tom Haynes Subject: Re: [Fwd: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010]] In-reply-to: <4BE1CC87.2070206@oracle.com> To: Alan Wright Cc: Rich Brown , PSARC-ext@sun.com, Tim Haley , nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com, afshin.salek@oracle.com Message-id: <4BE1D96F.8000308@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BE1D957.00CF:SCFMA4539814,ss=1,fgs=0 References: <4BE175B1.5050602@oracle.com> <4BE18A05.8070602@oracle.com> <4BE1CC87.2070206@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 2367 On 05/ 5/10 02:52 PM, Alan Wright wrote: > On 05/ 5/10 08:08 AM, Tom Haynes wrote: >> >>> typedef struct share { >>> struct share *sh_next; >>> char *sh_path; /* share path */ >>> char *sh_resource; /* share name */ >>> char *sh_fstype; /* protocol string ("nfs" | >>> "smb") */ >>> char *sh_opts; /* share property string */ >>> char *sh_descr; /* share description */ >>> size_t sh_size; >>> } share_t; >>> >> >> sh_fstype is not an appropriate name for the contents. >> >> The contents are a protocol and not a filesystem. >> >> sh_proto? > > This is actually an existing structure. see: > > uts/common/sharefs/share.h > > And the layout botch is my fault. No changes are planned > to the existing Nevada structure. > > Alan Yeah, I'm very familiar with that directory. I dunno why we didn't fix this issue when we first did sharefs. My guess is back then we talked in terms of fstypes and not protocols. I.e., look at the allowed types to share(1M): [th199096@aus1500-home sharefs]> more /etc/dfs/fstypes nfs NFS Utilities autofs AUTOFS Utilities cachefs CACHEFS Utilities smbfs CIFS Utilities Which brings up the point that share(1M) specifies that the allowed values in sh_fstype are those defined in fstypes(4). This also occurs with sharetab(4). So those would be "nfs" and "smbfs". Not "nfs" and "smb". Are we changing the parameters to the share command? Or actually to the Distributed File System (DFS) Administration commands? Or does there already exist means for making this mapping occur? (Yes, it is coded in sharemgr.) I find that the intent laid out in the man pages is confusing with the intent laid out in this case. And while some of the existing code uses sh_fstype to mean a protocol, some of it uses it to mean a filesystem type. This case makes a change in what goes into sh_fstype and uses the terminology "protocol" and not "filesystem". But it also exposes that the input and output to the DFS commands do not match the documentation. If we want to retain fstypes, we need to change the proto argument in all of the code to use "smbfs" and not "smb". If we want to use protocols, we need to update the man pages to the fact that sharetab(4) and friends are no longer relying on fstypes(4) to define "fstype" and indeed we ought to change "fstype" to be "proto" in the man pages and "sh_fstype" to be "sh_proto" in the code. From alan.wright@oracle.com Wed May 5 14:20:00 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45LK0r8007651 for ; Wed, 5 May 2010 14:20:00 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45LJxCU007431 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 16:20:00 -0500 (CDT) 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 <0L1Y00G07TXB3W00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 15:19:59 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y007NNTXBSVD0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 15:19:59 -0600 (MDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45LJxUg023136 for ; Wed, 05 May 2010 21:19:59 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45K8j71005423 for ; Wed, 05 May 2010 21:19:58 +0000 (GMT) Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 217546801273094396; Wed, 05 May 2010 14:19:56 -0700 Received: from [10.1.106.211] (/10.1.106.211) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 14:19:56 -0700 Date: Wed, 05 May 2010 14:19:05 -0700 From: Alan Wright Subject: Re: [Fwd: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010]] In-reply-to: <4BE1D96F.8000308@oracle.com> To: Tom Haynes Cc: Rich Brown , PSARC-ext@sun.com, Tim Haley , nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com, afshin.salek@oracle.com Message-id: <4BE1E0C9.9000304@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BE1E0FE.0148:SCFMA4539814,ss=1,fgs=0 References: <4BE175B1.5050602@oracle.com> <4BE18A05.8070602@oracle.com> <4BE1CC87.2070206@oracle.com> <4BE1D96F.8000308@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Thunderbird/3.0.1 Status: RO Content-Length: 3516 On 05/ 5/10 01:47 PM, Tom Haynes wrote: > On 05/ 5/10 02:52 PM, Alan Wright wrote: >> On 05/ 5/10 08:08 AM, Tom Haynes wrote: >>> >>>> typedef struct share { >>>> struct share *sh_next; >>>> char *sh_path; /* share path */ >>>> char *sh_resource; /* share name */ >>>> char *sh_fstype; /* protocol string ("nfs" | >>>> "smb") */ >>>> char *sh_opts; /* share property string */ >>>> char *sh_descr; /* share description */ >>>> size_t sh_size; >>>> } share_t; >>>> >>> >>> sh_fstype is not an appropriate name for the contents. >>> >>> The contents are a protocol and not a filesystem. >>> >>> sh_proto? >> >> This is actually an existing structure. see: >> >> uts/common/sharefs/share.h >> >> And the layout botch is my fault. No changes are planned >> to the existing Nevada structure. >> >> Alan > > Yeah, I'm very familiar with that directory. > > I dunno why we didn't fix this issue when we first did sharefs. > > My guess is back then we talked in terms of fstypes and not > protocols. > > I.e., look at the allowed types to share(1M): > > [th199096@aus1500-home sharefs]> more /etc/dfs/fstypes > nfs NFS Utilities > autofs AUTOFS Utilities > cachefs CACHEFS Utilities > smbfs CIFS Utilities > > Which brings up the point that share(1M) specifies that > the allowed values in sh_fstype are those defined in > fstypes(4). This also occurs with sharetab(4). > > So those would be "nfs" and "smbfs". Not "nfs" and "smb". smb is correct (this is the server-side protocol service) but it appears to be missing from sharetab(4), which is an existing bug because smb appears in sharetab today when you share a file system over smb. We'll open a CR on that. smbfs is specific to the smb/client, i.e. smbfs is only used by clients connecting to shares on a server. > Are we changing the parameters to the share command? > Or actually to the Distributed File System (DFS) Administration > commands? > Or does there already exist means for making this mapping > occur? (Yes, it is coded in sharemgr.) No commands, utilities or man pages should be harmed by this case. There should be no externally visible effect. > I find that the intent laid out in the man pages is confusing > with the intent laid out in this case. And while some of the > existing code uses sh_fstype to mean a protocol, some of > it uses it to mean a filesystem type. We can change the wording in the case to use filesystem (see also below). > This case makes a change in what goes into sh_fstype and > uses the terminology "protocol" and not "filesystem". But > it also exposes that the input and output to the DFS > commands do not match the documentation. No change to sh_fstype is being proposed, "smb" is already supported (just not listed in /etc/dfs/fstypes). > If we want to retain fstypes, we need to change the proto > argument in all of the code to use "smbfs" and not "smb". See above on smb/smbfs. > If we want to use protocols, we need to update the man > pages to the fact that sharetab(4) and friends are no > longer relying on fstypes(4) to define "fstype" and indeed > we ought to change "fstype" to be "proto" in the > man pages and "sh_fstype" to be "sh_proto" in the > code. If the consensus is that we should change fstype to proto, that's fine, but I would like to take that as a separate change because it has a larger impact than this case, including documentation impact. The intent here is simply to consolidate on a single share system call, which only impacts libshare and the nfs and smb servers. Alan From alan.wright@oracle.com Wed May 5 14:20:01 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45LK1fA007653 for ; Wed, 5 May 2010 14:20:01 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45LJw1L007426 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 16:20:00 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y00911TXCDE00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 14:20:00 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y0085YTXCIU80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 14:20:00 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o45LJxWN009377 for ; Wed, 05 May 2010 21:19:59 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45K8j73005423 for ; Wed, 05 May 2010 21:19:59 +0000 (GMT) Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 217546801273094396; Wed, 05 May 2010 14:19:56 -0700 Received: from [10.1.106.211] (/10.1.106.211) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 14:19:56 -0700 Date: Wed, 05 May 2010 14:19:05 -0700 From: Alan Wright Subject: Re: [Fwd: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010]] In-reply-to: <4BE1D96F.8000308@oracle.com> To: Tom Haynes Cc: Rich Brown , PSARC-ext@sun.com, Tim Haley , nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com, afshin.salek@oracle.com Message-id: <4BE1E0C9.9000304@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BE1E0FF.00E4:SCFMA4539814,ss=1,fgs=0 References: <4BE175B1.5050602@oracle.com> <4BE18A05.8070602@oracle.com> <4BE1CC87.2070206@oracle.com> <4BE1D96F.8000308@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Thunderbird/3.0.1 Status: RO Content-Length: 3516 On 05/ 5/10 01:47 PM, Tom Haynes wrote: > On 05/ 5/10 02:52 PM, Alan Wright wrote: >> On 05/ 5/10 08:08 AM, Tom Haynes wrote: >>> >>>> typedef struct share { >>>> struct share *sh_next; >>>> char *sh_path; /* share path */ >>>> char *sh_resource; /* share name */ >>>> char *sh_fstype; /* protocol string ("nfs" | >>>> "smb") */ >>>> char *sh_opts; /* share property string */ >>>> char *sh_descr; /* share description */ >>>> size_t sh_size; >>>> } share_t; >>>> >>> >>> sh_fstype is not an appropriate name for the contents. >>> >>> The contents are a protocol and not a filesystem. >>> >>> sh_proto? >> >> This is actually an existing structure. see: >> >> uts/common/sharefs/share.h >> >> And the layout botch is my fault. No changes are planned >> to the existing Nevada structure. >> >> Alan > > Yeah, I'm very familiar with that directory. > > I dunno why we didn't fix this issue when we first did sharefs. > > My guess is back then we talked in terms of fstypes and not > protocols. > > I.e., look at the allowed types to share(1M): > > [th199096@aus1500-home sharefs]> more /etc/dfs/fstypes > nfs NFS Utilities > autofs AUTOFS Utilities > cachefs CACHEFS Utilities > smbfs CIFS Utilities > > Which brings up the point that share(1M) specifies that > the allowed values in sh_fstype are those defined in > fstypes(4). This also occurs with sharetab(4). > > So those would be "nfs" and "smbfs". Not "nfs" and "smb". smb is correct (this is the server-side protocol service) but it appears to be missing from sharetab(4), which is an existing bug because smb appears in sharetab today when you share a file system over smb. We'll open a CR on that. smbfs is specific to the smb/client, i.e. smbfs is only used by clients connecting to shares on a server. > Are we changing the parameters to the share command? > Or actually to the Distributed File System (DFS) Administration > commands? > Or does there already exist means for making this mapping > occur? (Yes, it is coded in sharemgr.) No commands, utilities or man pages should be harmed by this case. There should be no externally visible effect. > I find that the intent laid out in the man pages is confusing > with the intent laid out in this case. And while some of the > existing code uses sh_fstype to mean a protocol, some of > it uses it to mean a filesystem type. We can change the wording in the case to use filesystem (see also below). > This case makes a change in what goes into sh_fstype and > uses the terminology "protocol" and not "filesystem". But > it also exposes that the input and output to the DFS > commands do not match the documentation. No change to sh_fstype is being proposed, "smb" is already supported (just not listed in /etc/dfs/fstypes). > If we want to retain fstypes, we need to change the proto > argument in all of the code to use "smbfs" and not "smb". See above on smb/smbfs. > If we want to use protocols, we need to update the man > pages to the fact that sharetab(4) and friends are no > longer relying on fstypes(4) to define "fstype" and indeed > we ought to change "fstype" to be "proto" in the > man pages and "sh_fstype" to be "sh_proto" in the > code. If the consensus is that we should change fstype to proto, that's fine, but I would like to take that as a separate change because it has a larger impact than this case, including documentation impact. The intent here is simply to consolidate on a single share system call, which only impacts libshare and the nfs and smb servers. Alan From Afshin.Salek@oracle.com Wed May 5 14:38:42 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45Lcggf007890 for ; Wed, 5 May 2010 14:38:42 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45LcfrH024460 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 14:38:42 -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 <0L1Y00E0PUSHNA00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 14:38:41 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y007Q8USHYK70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 14:38:41 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45LceMG010219 for ; Wed, 05 May 2010 21:38:40 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45Kjgcx005897 for ; Wed, 05 May 2010 21:38:40 +0000 (GMT) Received: from abhmt003.oracle.com by acsmt353.oracle.com with ESMTP id 217594111273095519; Wed, 05 May 2010 14:38:39 -0700 Received: from [10.1.106.212] (/10.1.106.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 14:38:38 -0700 Date: Wed, 05 May 2010 14:38:28 -0700 From: Afshin Salek Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE1C73D.9000104@Oracle.com> To: Afshin Salek Cc: Pavel Filipensky , PSARC-ext@sun.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com, nfs-instance_ww@oracle.com Message-id: <4BE1E554.60301@Oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BE1E560.00B4:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE17ADE.7010701@sun.com> <4BE1C73D.9000104@Oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 7578 I should add that sharefs here is only acting as a pass through between libshare in userspace and protocol services in the kernel. It provides, two commands for publishing/unpublishing (sharing/unsharing). Since sharefs is just a pass through, semantics of these commands are of libshare + protocol service concern and not sharefs. Afshin On 05/ 5/10 12:30 PM, Afshin Salek wrote: > This might have been specified in libshare V2 design document but the > current behavior is unpublish followed by publish. > > Afshin > > On 05/ 5/10 07:04 AM, Pavel Filipensky wrote: >> In case of the re-sharing (sharing with different options) - will the >> libshare >> issue two syscalls - SHAREFS_UNPUBLISH followed by SHAREFS_PUBLISH? >> Or just a SHAREFS_PUBLISH will be issued? >> >> I am asking because the current interfaces are not explicit about the type >> - they do not specify if it is a share or a re-share. >> It seems that also this proposal is not explicit about that. >> >> >> SHARE versus RESHARE >> >> The interfaces are not explicit about the type - it is a share or a re-share? >> Neither the caller (libshare) specifies if it is doing a share/re-share, >> nor the kernel (nfssrv/sharefs) reports back in the return value if it has >> done a share or a re-share. >> >> >> >> Pavel >> >> >> On 05/05/10 00:25, Tim Haley wrote: >>> I am sponsoring the following fast-track for Afshin Salek. This >>> proposal condenses the pair of syscalls used independently for sharing >>> nfs and cifs into one syscall. Requested binding is Micro/Patch. >>> >>> Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI >>> This information is Copyright (c) 2010, Oracle and/or its affiliates. >>> All rights reserved. >>> 1. Introduction >>> 1.1. Project/Component Working Name: >>> Unified sharing system call >>> 1.2. Name of Document Author/Supplier: >>> Author: Afshin Salek >>> 1.3 Date of This Document: >>> 04 May, 2010 >>> >>> 4. Technical Description >>> >>> 4.1. Details >>> >>> Currently, two system calls and a door are used to publish shares: the >>> nfsys multi-purpose system call to export NFS shares, the sharefs system >>> call to update sharetab and an smbd door to publish SMB shares. libshare >>> has to call the NFS or SMB service once per file system and then it has >>> to call sharefs once per share, which results in 1000's of system calls >>> to publish 1000's of shares. >>> >>> This is a proposal to unify all file sharing via a single system call: >>> sharefs. It is also to support of PSARC 2010/124 (libshare V2), which >>> requires changes to NFS, SMB and ZFS. >>> >>> Publishing all shares via a single system call has several advantages: >>> simplifies libshare, significantly reduces the number of system calls >>> per file system and per share, and improves integration between sharetab >>> and the protocol services. Libshare will call sharefs once per file >>> system (for each protocol that has something to share) with a list of >>> shares and the protocol services will update sharetab by making calls >>> to an in-kernel sharefs API. There will be no user space interface to >>> update sharetab directly. >>> >>> Having the protocol services update the sharetab file has two advantages >>> for libshare and sharefs: it significantly reduces the number of system >>> calls, as explained above, and neither libshare nor sharefs need to >>> perform per share error handling. Each protocol service handles its own >>> [un]publish operations and is responsible for updating sharetab as >>> appropriate. There is no need for the protocol services to return a list >>> of individual share results. >>> >>> The sharefs system call would be changed to accept: a protocol >>> discriminator >>> (NFS or SMB), an operation (publish or unpublish) and an opaque >>> pointer to >>> share data. The opaque data passes transparently through sharefs between >>> the protocol-specific libshare plugin and the protocol service per PSARC >>> 2010/124. The new prototype for sharefs would be of the form: >>> >>> int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, >>> void *data, size_t datalen); >>> >>> Where: >>> >>> typedef enum sharefs_proto { >>> SHAREFS_NFS, >>> SHAREFS_SMB >>> } sharefs_proto_t; >>> >>> typedef enum sharefs_op { >>> SHAREFS_PUBLISH, >>> SHAREFS_UNPUBLISH >>> } sharefs_op_t; >>> >>> Sharefs would be changed from a dynamically loaded module to be part of >>> the kernel. When invoked via the system call, sharefs would dynamically >>> load the NFS or SMB module as required and call the appropriate op >>> (publish or unpublish) registered by the module. The implication being >>> that each protocol service would register an op table with sharefs at >>> load time and that sharefs would provide an in-kernel API to update >>> sharetab. Each protocol service would be responsible for calling the >>> sharetab API as shares are added or removed. >>> >>> The nfssys system call will no longer handle [un]sharing of NFS shares: >>> EXPORTFS support will be removed from nfssys_op. >>> >>> The in-kernel sharefs API would be: >>> >>> typedef int (*sharefs_sop_t)(sharefs_op_t opcode, >>> void *data, size_t datalen); >>> >>> int sharefs_register(sharefs_proto_t proto, sharefs_sop_t sop); >>> >>> Register with sharefs to receive calls to publish or unpublish >>> shares. If sop is a non-NULL pointer the function will >>> be registered as the handler for the specified protocol. >>> If sop is NULL, the handler for the specified protocol >>> will be set to NULL, effectively unregistering the service. >>> >>> Return values: >>> 0 success >>> EINVAL Unknown protocol. >>> >>> typedef struct share { >>> struct share *sh_next; >>> char *sh_path; /* share path */ >>> char *sh_resource; /* share name */ >>> char *sh_fstype; /* protocol string ("nfs" | "smb") */ >>> char *sh_opts; /* share property string */ >>> char *sh_descr; /* share description */ >>> size_t sh_size; >>> } share_t; >>> >>> int sharetab_add(share_t *share); >>> >>> Add an entry to sharetab. Existing entries are replaced >>> with the new entry. All data is copied to sharetab. >>> >>> Return values: >>> 0 success >>> EPERM permision denied >>> >>> int sharetab_remove(share_t *share); >>> >>> Remove an entry from sharetab. The parameter must contain >>> enough information to uniquely identify a sharetab entry. >>> For NFS: sh_fstype and sh_path >>> For SMB: sh_fstype and sh_resource. >>> >>> Return values: >>> 0 success >>> ENOENT entry not found in sharetab >>> EPERM permision denied >>> >>> 4.2 Bug/RFE Number(s): >>> >>> 6850837 >>> >>> 4.5 Interfaces >>> >>> _______________________________________________________________ >>> | Exported Interface | Classification | Comments | >>> |________________________|___________________|__________________| >>> | sharefs sys-call | Consolidation | Consumed by | >>> | | Private | libshare | >>> | | | | >>> | sharefs_register | Consolidation | Consumed by NFS | >>> | | Private | SMB modules | >>> | | | | >>> | sharetab_add | Consolidation | sharefs kernel | >>> | sharetab_remove | Private | API to manage | >>> | | | sharetab content | >>> |________________________|___________________|__________________| >>> >>> 4.6. Doc Impact: >>> >>> N/A >>> >>> 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 >>> >>> >> > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From Afshin.Salek@oracle.com Wed May 5 14:38:42 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45Lcg3c007894 for ; Wed, 5 May 2010 14:38:42 -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 o45LcgQM024462 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 14:38:42 -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 <0L1Y00H17USIT700@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 15:38:42 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y00H8EUSH8K00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 15:38:42 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o45LcfYQ015205 for ; Wed, 05 May 2010 21:38:41 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45Kjgd1005897 for ; Wed, 05 May 2010 21:38:40 +0000 (GMT) Received: from abhmt003.oracle.com by acsmt353.oracle.com with ESMTP id 217594111273095519; Wed, 05 May 2010 14:38:39 -0700 Received: from [10.1.106.212] (/10.1.106.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 14:38:38 -0700 Date: Wed, 05 May 2010 14:38:28 -0700 From: Afshin Salek Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE1C73D.9000104@Oracle.com> To: Afshin Salek Cc: Pavel Filipensky , PSARC-ext@sun.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com, nfs-instance_ww@oracle.com Message-id: <4BE1E554.60301@Oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BE1E561.0022:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE17ADE.7010701@sun.com> <4BE1C73D.9000104@Oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 7578 I should add that sharefs here is only acting as a pass through between libshare in userspace and protocol services in the kernel. It provides, two commands for publishing/unpublishing (sharing/unsharing). Since sharefs is just a pass through, semantics of these commands are of libshare + protocol service concern and not sharefs. Afshin On 05/ 5/10 12:30 PM, Afshin Salek wrote: > This might have been specified in libshare V2 design document but the > current behavior is unpublish followed by publish. > > Afshin > > On 05/ 5/10 07:04 AM, Pavel Filipensky wrote: >> In case of the re-sharing (sharing with different options) - will the >> libshare >> issue two syscalls - SHAREFS_UNPUBLISH followed by SHAREFS_PUBLISH? >> Or just a SHAREFS_PUBLISH will be issued? >> >> I am asking because the current interfaces are not explicit about the type >> - they do not specify if it is a share or a re-share. >> It seems that also this proposal is not explicit about that. >> >> >> SHARE versus RESHARE >> >> The interfaces are not explicit about the type - it is a share or a re-share? >> Neither the caller (libshare) specifies if it is doing a share/re-share, >> nor the kernel (nfssrv/sharefs) reports back in the return value if it has >> done a share or a re-share. >> >> >> >> Pavel >> >> >> On 05/05/10 00:25, Tim Haley wrote: >>> I am sponsoring the following fast-track for Afshin Salek. This >>> proposal condenses the pair of syscalls used independently for sharing >>> nfs and cifs into one syscall. Requested binding is Micro/Patch. >>> >>> Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI >>> This information is Copyright (c) 2010, Oracle and/or its affiliates. >>> All rights reserved. >>> 1. Introduction >>> 1.1. Project/Component Working Name: >>> Unified sharing system call >>> 1.2. Name of Document Author/Supplier: >>> Author: Afshin Salek >>> 1.3 Date of This Document: >>> 04 May, 2010 >>> >>> 4. Technical Description >>> >>> 4.1. Details >>> >>> Currently, two system calls and a door are used to publish shares: the >>> nfsys multi-purpose system call to export NFS shares, the sharefs system >>> call to update sharetab and an smbd door to publish SMB shares. libshare >>> has to call the NFS or SMB service once per file system and then it has >>> to call sharefs once per share, which results in 1000's of system calls >>> to publish 1000's of shares. >>> >>> This is a proposal to unify all file sharing via a single system call: >>> sharefs. It is also to support of PSARC 2010/124 (libshare V2), which >>> requires changes to NFS, SMB and ZFS. >>> >>> Publishing all shares via a single system call has several advantages: >>> simplifies libshare, significantly reduces the number of system calls >>> per file system and per share, and improves integration between sharetab >>> and the protocol services. Libshare will call sharefs once per file >>> system (for each protocol that has something to share) with a list of >>> shares and the protocol services will update sharetab by making calls >>> to an in-kernel sharefs API. There will be no user space interface to >>> update sharetab directly. >>> >>> Having the protocol services update the sharetab file has two advantages >>> for libshare and sharefs: it significantly reduces the number of system >>> calls, as explained above, and neither libshare nor sharefs need to >>> perform per share error handling. Each protocol service handles its own >>> [un]publish operations and is responsible for updating sharetab as >>> appropriate. There is no need for the protocol services to return a list >>> of individual share results. >>> >>> The sharefs system call would be changed to accept: a protocol >>> discriminator >>> (NFS or SMB), an operation (publish or unpublish) and an opaque >>> pointer to >>> share data. The opaque data passes transparently through sharefs between >>> the protocol-specific libshare plugin and the protocol service per PSARC >>> 2010/124. The new prototype for sharefs would be of the form: >>> >>> int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, >>> void *data, size_t datalen); >>> >>> Where: >>> >>> typedef enum sharefs_proto { >>> SHAREFS_NFS, >>> SHAREFS_SMB >>> } sharefs_proto_t; >>> >>> typedef enum sharefs_op { >>> SHAREFS_PUBLISH, >>> SHAREFS_UNPUBLISH >>> } sharefs_op_t; >>> >>> Sharefs would be changed from a dynamically loaded module to be part of >>> the kernel. When invoked via the system call, sharefs would dynamically >>> load the NFS or SMB module as required and call the appropriate op >>> (publish or unpublish) registered by the module. The implication being >>> that each protocol service would register an op table with sharefs at >>> load time and that sharefs would provide an in-kernel API to update >>> sharetab. Each protocol service would be responsible for calling the >>> sharetab API as shares are added or removed. >>> >>> The nfssys system call will no longer handle [un]sharing of NFS shares: >>> EXPORTFS support will be removed from nfssys_op. >>> >>> The in-kernel sharefs API would be: >>> >>> typedef int (*sharefs_sop_t)(sharefs_op_t opcode, >>> void *data, size_t datalen); >>> >>> int sharefs_register(sharefs_proto_t proto, sharefs_sop_t sop); >>> >>> Register with sharefs to receive calls to publish or unpublish >>> shares. If sop is a non-NULL pointer the function will >>> be registered as the handler for the specified protocol. >>> If sop is NULL, the handler for the specified protocol >>> will be set to NULL, effectively unregistering the service. >>> >>> Return values: >>> 0 success >>> EINVAL Unknown protocol. >>> >>> typedef struct share { >>> struct share *sh_next; >>> char *sh_path; /* share path */ >>> char *sh_resource; /* share name */ >>> char *sh_fstype; /* protocol string ("nfs" | "smb") */ >>> char *sh_opts; /* share property string */ >>> char *sh_descr; /* share description */ >>> size_t sh_size; >>> } share_t; >>> >>> int sharetab_add(share_t *share); >>> >>> Add an entry to sharetab. Existing entries are replaced >>> with the new entry. All data is copied to sharetab. >>> >>> Return values: >>> 0 success >>> EPERM permision denied >>> >>> int sharetab_remove(share_t *share); >>> >>> Remove an entry from sharetab. The parameter must contain >>> enough information to uniquely identify a sharetab entry. >>> For NFS: sh_fstype and sh_path >>> For SMB: sh_fstype and sh_resource. >>> >>> Return values: >>> 0 success >>> ENOENT entry not found in sharetab >>> EPERM permision denied >>> >>> 4.2 Bug/RFE Number(s): >>> >>> 6850837 >>> >>> 4.5 Interfaces >>> >>> _______________________________________________________________ >>> | Exported Interface | Classification | Comments | >>> |________________________|___________________|__________________| >>> | sharefs sys-call | Consolidation | Consumed by | >>> | | Private | libshare | >>> | | | | >>> | sharefs_register | Consolidation | Consumed by NFS | >>> | | Private | SMB modules | >>> | | | | >>> | sharetab_add | Consolidation | sharefs kernel | >>> | sharetab_remove | Private | API to manage | >>> | | | sharetab content | >>> |________________________|___________________|__________________| >>> >>> 4.6. Doc Impact: >>> >>> N/A >>> >>> 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 >>> >>> >> > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From tom.haynes@oracle.com Wed May 5 14:45:05 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45Lj49F007957 for ; Wed, 5 May 2010 14:45:05 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45Lj24H019182 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 16:45:04 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y00E1XV33ZT00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 14:45:03 -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 <0L1Y00700V33YK80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 14:45:03 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45Lj2Tj005860 for ; Wed, 05 May 2010 21:45:03 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45L4tWg031294 for ; Wed, 05 May 2010 21:45:02 +0000 (GMT) Received: from abhmt007.oracle.com by acsmt355.oracle.com with ESMTP id 240495531273095899; Wed, 05 May 2010 14:44:59 -0700 Received: from [129.150.48.148] (/129.150.48.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 14:44:58 -0700 Date: Wed, 05 May 2010 16:45:28 -0500 From: Tom Haynes Subject: Re: [Fwd: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010]] In-reply-to: <4BE1E0C9.9000304@oracle.com> To: Alan Wright Cc: Rich Brown , PSARC-ext@sun.com, Tim Haley , nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com, afshin.salek@oracle.com Message-id: <4BE1E6F8.4000001@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BE1E6DE.0133:SCFMA4539814,ss=1,fgs=0 References: <4BE175B1.5050602@oracle.com> <4BE18A05.8070602@oracle.com> <4BE1CC87.2070206@oracle.com> <4BE1D96F.8000308@oracle.com> <4BE1E0C9.9000304@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 474 On 05/ 5/10 04:19 PM, Alan Wright wrote: > > If the consensus is that we should change fstype to proto, > that's fine, but I would like to take that as a separate change > because it has a larger impact than this case, including > documentation impact. The intent here is simply to consolidate > on a single share system call, which only impacts libshare and > the nfs and smb servers. > > Alan If you add smb as an fstype, then I agree that no other action is needed. From tom.haynes@oracle.com Wed May 5 14:45:05 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45Lj5O6007961 for ; Wed, 5 May 2010 14:45:05 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45Lj24P019182 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 16:45:05 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y00F0FV350900@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 14:45:05 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y007QMV34YJ60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 14:45:04 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45Lj3xi007289 for ; Wed, 05 May 2010 21:45:03 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45L4tWi031294 for ; Wed, 05 May 2010 21:45:03 +0000 (GMT) Received: from abhmt007.oracle.com by acsmt355.oracle.com with ESMTP id 240495531273095899; Wed, 05 May 2010 14:44:59 -0700 Received: from [129.150.48.148] (/129.150.48.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 14:44:58 -0700 Date: Wed, 05 May 2010 16:45:28 -0500 From: Tom Haynes Subject: Re: [Fwd: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010]] In-reply-to: <4BE1E0C9.9000304@oracle.com> To: Alan Wright Cc: Rich Brown , PSARC-ext@sun.com, Tim Haley , nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com, afshin.salek@oracle.com Message-id: <4BE1E6F8.4000001@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BE1E6DF.00C4:SCFMA4539814,ss=1,fgs=0 References: <4BE175B1.5050602@oracle.com> <4BE18A05.8070602@oracle.com> <4BE1CC87.2070206@oracle.com> <4BE1D96F.8000308@oracle.com> <4BE1E0C9.9000304@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 474 On 05/ 5/10 04:19 PM, Alan Wright wrote: > > If the consensus is that we should change fstype to proto, > that's fine, but I would like to take that as a separate change > because it has a larger impact than this case, including > documentation impact. The intent here is simply to consolidate > on a single share system call, which only impacts libshare and > the nfs and smb servers. > > Alan If you add smb as an fstype, then I agree that no other action is needed. From alan.wright@oracle.com Wed May 5 15:25:38 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45MPcF4008897 for ; Wed, 5 May 2010 15:25:38 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45MPcUx010165 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 17:25:38 -0500 (CDT) 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 <0L1Y00M01WYQ1T00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 16:25:38 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y00HPQWYP8I20@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 16:25:37 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45MPbo2003180 for ; Wed, 05 May 2010 22:25:37 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45M97A3011503 for ; Wed, 05 May 2010 22:25:37 +0000 (GMT) Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 217707901273098334; Wed, 05 May 2010 15:25:34 -0700 Received: from [10.1.106.211] (/10.1.106.211) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 15:25:34 -0700 Date: Wed, 05 May 2010 15:24:44 -0700 From: Alan Wright Subject: Re: [Fwd: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010]] In-reply-to: <4BE1E6F8.4000001@oracle.com> To: Tom Haynes Cc: Rich Brown , PSARC-ext@sun.com, Tim Haley , nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com, afshin.salek@oracle.com Message-id: <4BE1F02C.3000706@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BE1F061.0084:SCFMA4539814,ss=1,fgs=0 References: <4BE175B1.5050602@oracle.com> <4BE18A05.8070602@oracle.com> <4BE1CC87.2070206@oracle.com> <4BE1D96F.8000308@oracle.com> <4BE1E0C9.9000304@oracle.com> <4BE1E6F8.4000001@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Thunderbird/3.0.1 Status: RO Content-Length: 587 On 05/ 5/10 02:45 PM, Tom Haynes wrote: > On 05/ 5/10 04:19 PM, Alan Wright wrote: >> >> If the consensus is that we should change fstype to proto, >> that's fine, but I would like to take that as a separate change >> because it has a larger impact than this case, including >> documentation impact. The intent here is simply to consolidate >> on a single share system call, which only impacts libshare and >> the nfs and smb servers. >> >> Alan > > If you add smb as an fstype, then I agree that no other action > is needed. 6950069 smb is missing from /etc/dfs/fstypes Thanks. Alan From alan.wright@oracle.com Wed May 5 15:25:39 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45MPdBr008901 for ; Wed, 5 May 2010 15:25:39 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45MPc3u006523 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 15:25:39 -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 <0L1Y00H09WYR4800@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 15:25:39 -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 <0L1Y007MJWYPY790@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 15:25:37 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45MPa21027316 for ; Wed, 05 May 2010 22:25:37 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45M97A1011503 for ; Wed, 05 May 2010 22:25:36 +0000 (GMT) Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 217707901273098334; Wed, 05 May 2010 15:25:34 -0700 Received: from [10.1.106.211] (/10.1.106.211) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 15:25:34 -0700 Date: Wed, 05 May 2010 15:24:44 -0700 From: Alan Wright Subject: Re: [Fwd: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010]] In-reply-to: <4BE1E6F8.4000001@oracle.com> To: Tom Haynes Cc: Rich Brown , PSARC-ext@sun.com, Tim Haley , nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com, afshin.salek@oracle.com Message-id: <4BE1F02C.3000706@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BE1F060.018E:SCFMA4539814,ss=1,fgs=0 References: <4BE175B1.5050602@oracle.com> <4BE18A05.8070602@oracle.com> <4BE1CC87.2070206@oracle.com> <4BE1D96F.8000308@oracle.com> <4BE1E0C9.9000304@oracle.com> <4BE1E6F8.4000001@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Thunderbird/3.0.1 Status: RO Content-Length: 587 On 05/ 5/10 02:45 PM, Tom Haynes wrote: > On 05/ 5/10 04:19 PM, Alan Wright wrote: >> >> If the consensus is that we should change fstype to proto, >> that's fine, but I would like to take that as a separate change >> because it has a larger impact than this case, including >> documentation impact. The intent here is simply to consolidate >> on a single share system call, which only impacts libshare and >> the nfs and smb servers. >> >> Alan > > If you add smb as an fstype, then I agree that no other action > is needed. 6950069 smb is missing from /etc/dfs/fstypes Thanks. Alan From Afshin.Salek@Oracle.com Wed May 5 16:43:27 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45NhRGZ010178 for ; Wed, 5 May 2010 16:43:27 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45NhRmG007986 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 16:43:27 -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 <0L1Z002010KFMH00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 16:43:27 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Z00CTH0KEYL20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 16:43:27 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45NhQRD025502 for ; Wed, 05 May 2010 23:43:26 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45MeVFr020582 for ; Wed, 05 May 2010 23:43:25 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 240751821273102995; Wed, 05 May 2010 16:43:15 -0700 Received: from [10.1.106.212] (/10.1.106.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 16:43:15 -0700 Date: Wed, 05 May 2010 16:43:03 -0700 From: Afshin Salek Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <20100505193915.GD9429@oracle.com> To: Nicolas Williams Cc: Pavel Filipensky , Tim Haley , PSARC-ext@sun.com, nfs-instance_ww@Oracle.com, libshare-team_ww@Oracle.com, mark.shellenbaum@Oracle.com Message-id: <4BE20287.4050504@Oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BE2029E.0049:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE17ADE.7010701@sun.com> <4BE1C73D.9000104@Oracle.com> <20100505193915.GD9429@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 831 libshare may choose not to do it that way and leave it to the protocol services to treat a share request as adding or replacing a share based on whether or not the share already exists. As I've responded to Pavel, sharefs is not doing anything with the given data except passing it through to the protocol services. Afshin On 05/ 5/10 12:39 PM, Nicolas Williams wrote: > On Wed, May 05, 2010 at 12:30:05PM -0700, Afshin Salek wrote: >> This might have been specified in libshare V2 design document but the >> current behavior is unpublish followed by publish. > > Couldn't that cause an outtage? If the re-share is just to change some > sharing option, there should be no hiccup for clients not affected by > the option change (e.g., security mode changes, where NFSv4 clients may > be able to recover automatically). > > Nico From Afshin.Salek@Oracle.com Wed May 5 16:43:28 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45NhSPL010182 for ; Wed, 5 May 2010 16:43:28 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45NhS9M007988 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 16:43:28 -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 <0L1Z006010KF5700@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 17:43:27 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Z00HSA0KF8Q50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 17:43:27 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45NhQaJ005843 for ; Wed, 05 May 2010 23:43:27 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45MeVFt020582 for ; Wed, 05 May 2010 23:43:26 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 240751821273102995; Wed, 05 May 2010 16:43:15 -0700 Received: from [10.1.106.212] (/10.1.106.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 16:43:15 -0700 Date: Wed, 05 May 2010 16:43:03 -0700 From: Afshin Salek Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <20100505193915.GD9429@oracle.com> To: Nicolas Williams Cc: Pavel Filipensky , Tim Haley , PSARC-ext@sun.com, nfs-instance_ww@Oracle.com, libshare-team_ww@Oracle.com, mark.shellenbaum@Oracle.com Message-id: <4BE20287.4050504@Oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BE2029E.0156:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE17ADE.7010701@sun.com> <4BE1C73D.9000104@Oracle.com> <20100505193915.GD9429@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 831 libshare may choose not to do it that way and leave it to the protocol services to treat a share request as adding or replacing a share based on whether or not the share already exists. As I've responded to Pavel, sharefs is not doing anything with the given data except passing it through to the protocol services. Afshin On 05/ 5/10 12:39 PM, Nicolas Williams wrote: > On Wed, May 05, 2010 at 12:30:05PM -0700, Afshin Salek wrote: >> This might have been specified in libshare V2 design document but the >> current behavior is unpublish followed by publish. > > Couldn't that cause an outtage? If the re-share is just to change some > sharing option, there should be no hiccup for clients not affected by > the option change (e.g., security mode changes, where NFSv4 clients may > be able to recover automatically). > > Nico From tim.haley@oracle.com Tue May 11 13:11:14 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4BKBEEb025815 for ; Tue, 11 May 2010 13:11:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4BKBELh008124 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 13:11:14 -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 <0L2900D0BUQQ0B00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 13:11:14 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L29003SUUQQJXB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 13:11:14 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4BKBDev026630 for ; Tue, 11 May 2010 20:11:13 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4BK8ZbP006781 for ; Tue, 11 May 2010 20:11:13 +0000 (GMT) Received: from abhmt020.oracle.com by acsmt355.oracle.com with ESMTP id 232732671273608672; Tue, 11 May 2010 13:11:12 -0700 Received: from [172.20.25.27] (/10.85.25.27) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 13:11:11 -0700 Date: Tue, 11 May 2010 14:11:11 -0600 From: Tim Haley Subject: Re: [Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010]] To: PSARC-ext@sun.com Cc: Afshin Salek , nfs-instance_ww@oracle.com, Mark Shellenbaum , LIBSHARE-TEAM_WW Message-id: <4BE9B9DF.3080703@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BE9B9E1.00D0:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 132 This case times out today and I haven't seen any member comment or +1. If someone can take a look we'd appreciate it. thanks, -tim From tim.haley@oracle.com Tue May 11 13:11:15 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4BKBFA3025819 for ; Tue, 11 May 2010 13:11:15 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4BKBFki004258 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 15:11:15 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2900D05UQR0C00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 13:11:15 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2900345UQQJZB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 13:11:14 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4BKBEPa018683 for ; Tue, 11 May 2010 20:11:14 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4BK8ZbR006781 for ; Tue, 11 May 2010 20:11:13 +0000 (GMT) Received: from abhmt020.oracle.com by acsmt355.oracle.com with ESMTP id 232732671273608672; Tue, 11 May 2010 13:11:12 -0700 Received: from [172.20.25.27] (/10.85.25.27) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 13:11:11 -0700 Date: Tue, 11 May 2010 14:11:11 -0600 From: Tim Haley Subject: Re: [Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010]] To: PSARC-ext@sun.com Cc: Afshin Salek , nfs-instance_ww@oracle.com, Mark Shellenbaum , LIBSHARE-TEAM_WW Message-id: <4BE9B9DF.3080703@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BE9B9E2.0008:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 132 This case times out today and I haven't seen any member comment or +1. If someone can take a look we'd appreciate it. thanks, -tim From gisburn@gmail.com Tue May 11 13:49:06 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4BKn6kD026400 for ; Tue, 11 May 2010 13:49:06 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4BKmxpJ029392 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 14:49:06 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2900E05WHTU400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 13:49:05 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L29003A8WHTJXE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 13:49:05 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4BKdLj0017202 for ; Tue, 11 May 2010 20:49:05 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay13i.sun.com with ESMTP id BT-MMP-1159561 for PSARC-ext@sun.com; Tue, 11 May 2010 20:49:05 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-723058 for PSARC-ext@sun.com; Tue, 11 May 2010 20:49:04 +0000 (Z) Received: from mail-ww0-f49.google.com ([74.125.82.49] [74.125.82.49]) by relay1i.sun.com with ESMTP id BT-MMP-57724527 for PSARC-ext@sun.com; Tue, 11 May 2010 20:49:04 +0000 (Z) Received: by wwb22 with SMTP id 22so2901850wwb.8 for ; Tue, 11 May 2010 13:49:00 -0700 (PDT) Received: by 10.216.88.139 with SMTP id a11mr3890502wef.74.1273610940072; Tue, 11 May 2010 13:49:00 -0700 (PDT) Received: by 10.216.233.148 with HTTP; Tue, 11 May 2010 13:49:00 -0700 (PDT) Date: Tue, 11 May 2010 22:49:00 +0200 From: Roland Mainz Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE09ED2.6080505@oracle.com> Sender: gisburn@gmail.com To: Tim Haley Cc: PSARC-ext@sun.com, mark.shellenbaum@oracle.com, libshare-team_ww@oracle.com, nfs-instance_ww@oracle.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=LBAuPzp2Tgl6z6QvM5eCgYvDVCuAyIsGzAbgI6sOmo0=; b=H7vf0xqFqP3AZy7VyVOzSEF7PD3RKrB9395CRs5GZ7SABxKkuAbwNkOV4S+qPXy0ci WqVpT9ao/PJn2+3g7679s+PhqO63javBUuo/bOiTns8xWqkOVoehR32522OJfD3vJbmB DlRE+JZ6I9su3J7ckFSgr0ARsXY8jrpJ8unSI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=k6dG5ivc9jUmND31JRdM+XprAFsfTgcvE+Ky9gU8n3Ee5ODW413ttYvXi61hz8lUV0 hf8B3YWSTT56RlXE1+LZsiytIg+6fxyfoW9woyozw8IXEfyj9tXgCQRexLWE64dHqns3 lGFTyMQA5lIR5VlCke9r6p1FZlorW3rJxf10o= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: Ew3zt6QuX9IeG-kEUCUutcChRFA X-Antispam: No, score=-2.6/5.0, scanned in 0.091sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BE09ED2.6080505@oracle.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id o4BKn6kD026400 Status: RO Content-Length: 3388 On Wed, May 5, 2010 at 12:25 AM, Tim Haley wrote: > I am sponsoring the following fast-track for Afshin Salek.  This > proposal condenses the pair of syscalls used independently for sharing > nfs and cifs into one syscall.  Requested binding is Micro/Patch. > > Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI > This information is Copyright (c) 2010, Oracle and/or its affiliates. All > rights reserved. > 1. Introduction >    1.1. Project/Component Working Name: >         Unified sharing system call >    1.2. Name of Document Author/Supplier: >         Author:  Afshin Salek >    1.3  Date of This Document: >        04 May, 2010 > > 4. Technical Description > >   4.1. Details > > Currently, two system calls and a door are used to publish shares: the > nfsys multi-purpose system call to export NFS shares, the sharefs system > call to update sharetab and an smbd door to publish SMB shares.  libshare > has to call the NFS or SMB service once per file system and then it has > to call sharefs once per share, which results in 1000's of system calls > to publish 1000's of shares. > > This is a proposal to unify all file sharing via a single system call: > sharefs.  It is also to support of PSARC 2010/124 (libshare V2), which > requires changes to NFS, SMB and ZFS. > > Publishing all shares via a single system call has several advantages: > simplifies libshare, significantly reduces the number of system calls > per file system and per share, and improves integration between sharetab > and the protocol services.  Libshare will call sharefs once per file > system (for each protocol that has something to share) with a list of > shares and the protocol services will update sharetab by making calls > to an in-kernel sharefs API.  There will be no user space interface to > update sharetab directly. > > Having the protocol services update the sharetab file has two advantages > for libshare and sharefs: it significantly reduces the number of system > calls, as explained above, and neither libshare nor sharefs need to > perform per share error handling.  Each protocol service handles its own > [un]publish operations and is responsible for updating sharetab as > appropriate.  There is no need for the protocol services to return a list > of individual share results. > > The sharefs system call would be changed to accept: a protocol discriminator > (NFS or SMB), an operation (publish or unpublish) and an opaque pointer to > share data.  The opaque data passes transparently through sharefs between > the protocol-specific libshare plugin and the protocol service per PSARC > 2010/124.  The new prototype for sharefs would be of the form: > >    int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, >        void *data, size_t datalen); Please do me a small favour and add a flags field, e.g. turn this prototype into: -- snip -- int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, void *data, size_t datalen, uint32_t flags); -- snip -- The idea is that future consumers (e.g. AFS etc.) can use this for _easy_ extensions without having to change this API again (and please don't say this is not needed - see |fork()| vs. |forkx()|). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From Afshin.Salek@Oracle.com Tue May 11 13:53:39 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4BKrdiL026472 for ; Tue, 11 May 2010 13:53:39 -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 o4BKrcbH022165 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 13:53:39 -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 <0L2900603WPE4I00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 14:53:38 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2900IUPWPEOO80@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 14:53:38 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4BKrc8h029413 for ; Tue, 11 May 2010 20:53:38 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4BKXXKs014996 for ; Tue, 11 May 2010 20:53:37 +0000 (GMT) Received: from abhmt004.oracle.com by acsmt355.oracle.com with ESMTP id 256196291273611214; Tue, 11 May 2010 13:53:34 -0700 Received: from [10.1.106.212] (/10.1.106.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 13:53:34 -0700 Date: Tue, 11 May 2010 13:53:24 -0700 From: Afshin Salek Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: To: Roland Mainz Cc: Tim Haley , PSARC-ext@sun.com, mark.shellenbaum@Oracle.com, libshare-team_ww@Oracle.com, nfs-instance_ww@Oracle.com Message-id: <4BE9C3C4.3030402@Oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BE9C3D1.01BB:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 3586 If a new protocol needs to be supported that should be added to sharefs_proto_t. If a new operation needs to be supported that should be added to sharefs_op_t. So, what kind of extension are you talking about here? Afshin On 05/11/10 01:49 PM, Roland Mainz wrote: > On Wed, May 5, 2010 at 12:25 AM, Tim Haley wrote: >> I am sponsoring the following fast-track for Afshin Salek. This >> proposal condenses the pair of syscalls used independently for sharing >> nfs and cifs into one syscall. Requested binding is Micro/Patch. >> >> Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI >> This information is Copyright (c) 2010, Oracle and/or its affiliates. All >> rights reserved. >> 1. Introduction >> 1.1. Project/Component Working Name: >> Unified sharing system call >> 1.2. Name of Document Author/Supplier: >> Author: Afshin Salek >> 1.3 Date of This Document: >> 04 May, 2010 >> >> 4. Technical Description >> >> 4.1. Details >> >> Currently, two system calls and a door are used to publish shares: the >> nfsys multi-purpose system call to export NFS shares, the sharefs system >> call to update sharetab and an smbd door to publish SMB shares. libshare >> has to call the NFS or SMB service once per file system and then it has >> to call sharefs once per share, which results in 1000's of system calls >> to publish 1000's of shares. >> >> This is a proposal to unify all file sharing via a single system call: >> sharefs. It is also to support of PSARC 2010/124 (libshare V2), which >> requires changes to NFS, SMB and ZFS. >> >> Publishing all shares via a single system call has several advantages: >> simplifies libshare, significantly reduces the number of system calls >> per file system and per share, and improves integration between sharetab >> and the protocol services. Libshare will call sharefs once per file >> system (for each protocol that has something to share) with a list of >> shares and the protocol services will update sharetab by making calls >> to an in-kernel sharefs API. There will be no user space interface to >> update sharetab directly. >> >> Having the protocol services update the sharetab file has two advantages >> for libshare and sharefs: it significantly reduces the number of system >> calls, as explained above, and neither libshare nor sharefs need to >> perform per share error handling. Each protocol service handles its own >> [un]publish operations and is responsible for updating sharetab as >> appropriate. There is no need for the protocol services to return a list >> of individual share results. >> >> The sharefs system call would be changed to accept: a protocol discriminator >> (NFS or SMB), an operation (publish or unpublish) and an opaque pointer to >> share data. The opaque data passes transparently through sharefs between >> the protocol-specific libshare plugin and the protocol service per PSARC >> 2010/124. The new prototype for sharefs would be of the form: >> >> int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, >> void *data, size_t datalen); > > Please do me a small favour and add a flags field, e.g. turn this > prototype into: > -- snip -- > int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, > void *data, size_t datalen, uint32_t flags); > -- snip -- > > The idea is that future consumers (e.g. AFS etc.) can use this for > _easy_ extensions without having to change this API again (and please > don't say this is not needed - see |fork()| vs. |forkx()|). > > ---- > > Bye, > Roland > From Afshin.Salek@Oracle.com Tue May 11 13:53:40 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4BKrele026476 for ; Tue, 11 May 2010 13:53:40 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4BKrd34023312 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 15:53:40 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2900619WPFEN00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 13:53:39 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L290055JWPDLQ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 13:53:38 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4BKrbBx007851 for ; Tue, 11 May 2010 20:53:37 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4BKXXKq014996 for ; Tue, 11 May 2010 20:53:37 +0000 (GMT) Received: from abhmt004.oracle.com by acsmt355.oracle.com with ESMTP id 256196291273611214; Tue, 11 May 2010 13:53:34 -0700 Received: from [10.1.106.212] (/10.1.106.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 13:53:34 -0700 Date: Tue, 11 May 2010 13:53:24 -0700 From: Afshin Salek Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: To: Roland Mainz Cc: Tim Haley , PSARC-ext@sun.com, mark.shellenbaum@Oracle.com, libshare-team_ww@Oracle.com, nfs-instance_ww@Oracle.com Message-id: <4BE9C3C4.3030402@Oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BE9C3D1.00A7:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 3586 If a new protocol needs to be supported that should be added to sharefs_proto_t. If a new operation needs to be supported that should be added to sharefs_op_t. So, what kind of extension are you talking about here? Afshin On 05/11/10 01:49 PM, Roland Mainz wrote: > On Wed, May 5, 2010 at 12:25 AM, Tim Haley wrote: >> I am sponsoring the following fast-track for Afshin Salek. This >> proposal condenses the pair of syscalls used independently for sharing >> nfs and cifs into one syscall. Requested binding is Micro/Patch. >> >> Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI >> This information is Copyright (c) 2010, Oracle and/or its affiliates. All >> rights reserved. >> 1. Introduction >> 1.1. Project/Component Working Name: >> Unified sharing system call >> 1.2. Name of Document Author/Supplier: >> Author: Afshin Salek >> 1.3 Date of This Document: >> 04 May, 2010 >> >> 4. Technical Description >> >> 4.1. Details >> >> Currently, two system calls and a door are used to publish shares: the >> nfsys multi-purpose system call to export NFS shares, the sharefs system >> call to update sharetab and an smbd door to publish SMB shares. libshare >> has to call the NFS or SMB service once per file system and then it has >> to call sharefs once per share, which results in 1000's of system calls >> to publish 1000's of shares. >> >> This is a proposal to unify all file sharing via a single system call: >> sharefs. It is also to support of PSARC 2010/124 (libshare V2), which >> requires changes to NFS, SMB and ZFS. >> >> Publishing all shares via a single system call has several advantages: >> simplifies libshare, significantly reduces the number of system calls >> per file system and per share, and improves integration between sharetab >> and the protocol services. Libshare will call sharefs once per file >> system (for each protocol that has something to share) with a list of >> shares and the protocol services will update sharetab by making calls >> to an in-kernel sharefs API. There will be no user space interface to >> update sharetab directly. >> >> Having the protocol services update the sharetab file has two advantages >> for libshare and sharefs: it significantly reduces the number of system >> calls, as explained above, and neither libshare nor sharefs need to >> perform per share error handling. Each protocol service handles its own >> [un]publish operations and is responsible for updating sharetab as >> appropriate. There is no need for the protocol services to return a list >> of individual share results. >> >> The sharefs system call would be changed to accept: a protocol discriminator >> (NFS or SMB), an operation (publish or unpublish) and an opaque pointer to >> share data. The opaque data passes transparently through sharefs between >> the protocol-specific libshare plugin and the protocol service per PSARC >> 2010/124. The new prototype for sharefs would be of the form: >> >> int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, >> void *data, size_t datalen); > > Please do me a small favour and add a flags field, e.g. turn this > prototype into: > -- snip -- > int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, > void *data, size_t datalen, uint32_t flags); > -- snip -- > > The idea is that future consumers (e.g. AFS etc.) can use this for > _easy_ extensions without having to change this API again (and please > don't say this is not needed - see |fork()| vs. |forkx()|). > > ---- > > Bye, > Roland > From Afshin.Salek@Oracle.com Tue May 11 14:08:40 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4BL8dGI027027 for ; Tue, 11 May 2010 14:08:40 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4BL8dw8039363 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 15:08:39 -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 <0L290070FXEFHN00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 15:08:39 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2900IGSXEEOW80@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 15:08:39 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4BL8csN021600 for ; Tue, 11 May 2010 21:08:38 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4BKwYSE027579 for ; Tue, 11 May 2010 21:08:37 +0000 (GMT) Received: from abhmt014.oracle.com by acsmt354.oracle.com with ESMTP id 256247531273612110; Tue, 11 May 2010 14:08:30 -0700 Received: from [10.1.106.212] (/10.1.106.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 14:08:29 -0700 Date: Tue, 11 May 2010 14:08:19 -0700 From: Afshin Salek Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE9C3C4.3030402@Oracle.com> To: Afshin Salek Cc: Roland Mainz , Tim Haley , PSARC-ext@sun.com, mark.shellenbaum@Oracle.com, libshare-team_ww@Oracle.com, nfs-instance_ww@Oracle.com Message-id: <4BE9C743.1020800@Oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BE9C756.003A:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE9C3C4.3030402@Oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 3991 Also note that the only consumer of this system call is supposed to be Solaris libshare [V2]. Any enhancement to Solaris sharing functionality is supposed to be done through libshare and its plugin infrastructure (for example adding a new type of backend). The new sharefs is not intended to be used out of libshare [V2] context. Afshin On 05/11/10 01:53 PM, Afshin Salek wrote: > If a new protocol needs to be supported that should be added to > sharefs_proto_t. If a new operation needs to be supported that > should be added to sharefs_op_t. > > So, what kind of extension are you talking about here? > > Afshin > > On 05/11/10 01:49 PM, Roland Mainz wrote: >> On Wed, May 5, 2010 at 12:25 AM, Tim Haley wrote: >>> I am sponsoring the following fast-track for Afshin Salek. This >>> proposal condenses the pair of syscalls used independently for sharing >>> nfs and cifs into one syscall. Requested binding is Micro/Patch. >>> >>> Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI >>> This information is Copyright (c) 2010, Oracle and/or its affiliates. >>> All >>> rights reserved. >>> 1. Introduction >>> 1.1. Project/Component Working Name: >>> Unified sharing system call >>> 1.2. Name of Document Author/Supplier: >>> Author: Afshin Salek >>> 1.3 Date of This Document: >>> 04 May, 2010 >>> >>> 4. Technical Description >>> >>> 4.1. Details >>> >>> Currently, two system calls and a door are used to publish shares: the >>> nfsys multi-purpose system call to export NFS shares, the sharefs system >>> call to update sharetab and an smbd door to publish SMB shares. libshare >>> has to call the NFS or SMB service once per file system and then it has >>> to call sharefs once per share, which results in 1000's of system calls >>> to publish 1000's of shares. >>> >>> This is a proposal to unify all file sharing via a single system call: >>> sharefs. It is also to support of PSARC 2010/124 (libshare V2), which >>> requires changes to NFS, SMB and ZFS. >>> >>> Publishing all shares via a single system call has several advantages: >>> simplifies libshare, significantly reduces the number of system calls >>> per file system and per share, and improves integration between sharetab >>> and the protocol services. Libshare will call sharefs once per file >>> system (for each protocol that has something to share) with a list of >>> shares and the protocol services will update sharetab by making calls >>> to an in-kernel sharefs API. There will be no user space interface to >>> update sharetab directly. >>> >>> Having the protocol services update the sharetab file has two advantages >>> for libshare and sharefs: it significantly reduces the number of system >>> calls, as explained above, and neither libshare nor sharefs need to >>> perform per share error handling. Each protocol service handles its own >>> [un]publish operations and is responsible for updating sharetab as >>> appropriate. There is no need for the protocol services to return a list >>> of individual share results. >>> >>> The sharefs system call would be changed to accept: a protocol >>> discriminator >>> (NFS or SMB), an operation (publish or unpublish) and an opaque >>> pointer to >>> share data. The opaque data passes transparently through sharefs between >>> the protocol-specific libshare plugin and the protocol service per PSARC >>> 2010/124. The new prototype for sharefs would be of the form: >>> >>> int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, >>> void *data, size_t datalen); >> >> Please do me a small favour and add a flags field, e.g. turn this >> prototype into: >> -- snip -- >> int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, >> void *data, size_t datalen, uint32_t flags); >> -- snip -- >> >> The idea is that future consumers (e.g. AFS etc.) can use this for >> _easy_ extensions without having to change this API again (and please >> don't say this is not needed - see |fork()| vs. |forkx()|). >> >> ---- >> >> Bye, >> Roland >> > From Afshin.Salek@Oracle.com Tue May 11 14:08:41 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4BL8fcT027031 for ; Tue, 11 May 2010 14:08:41 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4BL8eJk029765 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 16:08:41 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2900F0JXEGRV00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 14:08:40 -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 <0L290039MXEFJXF0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 14:08:39 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4BL8dX9021369 for ; Tue, 11 May 2010 21:08:39 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4BKwYSG027579 for ; Tue, 11 May 2010 21:08:38 +0000 (GMT) Received: from abhmt014.oracle.com by acsmt354.oracle.com with ESMTP id 256247531273612110; Tue, 11 May 2010 14:08:30 -0700 Received: from [10.1.106.212] (/10.1.106.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 14:08:29 -0700 Date: Tue, 11 May 2010 14:08:19 -0700 From: Afshin Salek Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE9C3C4.3030402@Oracle.com> To: Afshin Salek Cc: Roland Mainz , Tim Haley , PSARC-ext@sun.com, mark.shellenbaum@Oracle.com, libshare-team_ww@Oracle.com, nfs-instance_ww@Oracle.com Message-id: <4BE9C743.1020800@Oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BE9C756.019A:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE9C3C4.3030402@Oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 3991 Also note that the only consumer of this system call is supposed to be Solaris libshare [V2]. Any enhancement to Solaris sharing functionality is supposed to be done through libshare and its plugin infrastructure (for example adding a new type of backend). The new sharefs is not intended to be used out of libshare [V2] context. Afshin On 05/11/10 01:53 PM, Afshin Salek wrote: > If a new protocol needs to be supported that should be added to > sharefs_proto_t. If a new operation needs to be supported that > should be added to sharefs_op_t. > > So, what kind of extension are you talking about here? > > Afshin > > On 05/11/10 01:49 PM, Roland Mainz wrote: >> On Wed, May 5, 2010 at 12:25 AM, Tim Haley wrote: >>> I am sponsoring the following fast-track for Afshin Salek. This >>> proposal condenses the pair of syscalls used independently for sharing >>> nfs and cifs into one syscall. Requested binding is Micro/Patch. >>> >>> Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI >>> This information is Copyright (c) 2010, Oracle and/or its affiliates. >>> All >>> rights reserved. >>> 1. Introduction >>> 1.1. Project/Component Working Name: >>> Unified sharing system call >>> 1.2. Name of Document Author/Supplier: >>> Author: Afshin Salek >>> 1.3 Date of This Document: >>> 04 May, 2010 >>> >>> 4. Technical Description >>> >>> 4.1. Details >>> >>> Currently, two system calls and a door are used to publish shares: the >>> nfsys multi-purpose system call to export NFS shares, the sharefs system >>> call to update sharetab and an smbd door to publish SMB shares. libshare >>> has to call the NFS or SMB service once per file system and then it has >>> to call sharefs once per share, which results in 1000's of system calls >>> to publish 1000's of shares. >>> >>> This is a proposal to unify all file sharing via a single system call: >>> sharefs. It is also to support of PSARC 2010/124 (libshare V2), which >>> requires changes to NFS, SMB and ZFS. >>> >>> Publishing all shares via a single system call has several advantages: >>> simplifies libshare, significantly reduces the number of system calls >>> per file system and per share, and improves integration between sharetab >>> and the protocol services. Libshare will call sharefs once per file >>> system (for each protocol that has something to share) with a list of >>> shares and the protocol services will update sharetab by making calls >>> to an in-kernel sharefs API. There will be no user space interface to >>> update sharetab directly. >>> >>> Having the protocol services update the sharetab file has two advantages >>> for libshare and sharefs: it significantly reduces the number of system >>> calls, as explained above, and neither libshare nor sharefs need to >>> perform per share error handling. Each protocol service handles its own >>> [un]publish operations and is responsible for updating sharetab as >>> appropriate. There is no need for the protocol services to return a list >>> of individual share results. >>> >>> The sharefs system call would be changed to accept: a protocol >>> discriminator >>> (NFS or SMB), an operation (publish or unpublish) and an opaque >>> pointer to >>> share data. The opaque data passes transparently through sharefs between >>> the protocol-specific libshare plugin and the protocol service per PSARC >>> 2010/124. The new prototype for sharefs would be of the form: >>> >>> int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, >>> void *data, size_t datalen); >> >> Please do me a small favour and add a flags field, e.g. turn this >> prototype into: >> -- snip -- >> int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, >> void *data, size_t datalen, uint32_t flags); >> -- snip -- >> >> The idea is that future consumers (e.g. AFS etc.) can use this for >> _easy_ extensions without having to change this API again (and please >> don't say this is not needed - see |fork()| vs. |forkx()|). >> >> ---- >> >> Bye, >> Roland >> > From gisburn@gmail.com Tue May 11 14:58:38 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4BLwcQZ028889 for ; Tue, 11 May 2010 14:58:38 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4BLwcoB020481 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 16:58:38 -0500 (CDT) 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 <0L2900B0BZPPK500@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 15:58:37 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2900IIOZPNOSD0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 15:58:35 -0600 (MDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4BLu3Ld003116 for ; Tue, 11 May 2010 21:58:35 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay14i.sun.com with ESMTP id BT-MMP-3237041 for PSARC-ext@sun.com; Tue, 11 May 2010 21:58:34 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-77489 for PSARC-ext@sun.com; Tue, 11 May 2010 21:58:34 +0000 (Z) Received: from mail-wy0-f177.google.com ([74.125.82.177] [74.125.82.177]) by relay1i.sun.com with ESMTP id BT-MMP-21148417 for PSARC-ext@sun.com; Tue, 11 May 2010 21:58:33 +0000 (Z) Received: by wyj26 with SMTP id 26so1893876wyj.8 for ; Tue, 11 May 2010 14:58:24 -0700 (PDT) Received: by 10.216.180.198 with SMTP id j48mr1477601wem.108.1273615104133; Tue, 11 May 2010 14:58:24 -0700 (PDT) Received: by 10.216.233.148 with HTTP; Tue, 11 May 2010 14:58:23 -0700 (PDT) Date: Tue, 11 May 2010 23:58:23 +0200 From: Roland Mainz Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE9C3C4.3030402@Oracle.com> Sender: gisburn@gmail.com To: Afshin Salek Cc: Tim Haley , PSARC-ext@sun.com, mark.shellenbaum@oracle.com, libshare-team_ww@oracle.com, nfs-instance_ww@oracle.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=S4zsCepKTOsiqGeNk/QI9WQo30lCko+sl4in6tO8yls=; b=JZNq4iCfwpBHMzWaus03FrM64eJpZ8csiUAy1aZ/eNIxmLeHL3oewgBbZPVVaaxX0e dK/5xjQ254OA86GXiwIqwvsXba3Q/JE+3CfkvH0Cb1N9+qJTorWqlN37ZonXhQUetc5h wP489gX7QKqsEvR+uhc2zJ3lx2cXHGvb1pTMg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=IsZHWLluXtx48I6L2bra355tfVAWgPni3GkR1KyNmDRTBDuXja/rINt8blz5aL1xAC EvvPhpx+lc6Jqi83Y30rrLTSNi3yym9pWPBrfz5YalAvNuCXynnj/k7XKyIbdppc02gn n7LzTSJcDim98M/m2QRomYPLgnF4k6+z9OHZw= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: xj1K1HsjqfSIkiXLciWYe0-DXtg X-Antispam: No, score=-1.1/5.0, scanned in 0.112sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BE09ED2.6080505@oracle.com> <4BE9C3C4.3030402@Oracle.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id o4BLwcQZ028889 Status: RO Content-Length: 5054 On Tue, May 11, 2010 at 10:53 PM, Afshin Salek wrote: > On 05/11/10 01:49 PM, Roland Mainz wrote: >> >> On Wed, May 5, 2010 at 12:25 AM, Tim Haley  wrote: >>> >>> I am sponsoring the following fast-track for Afshin Salek.  This >>> proposal condenses the pair of syscalls used independently for sharing >>> nfs and cifs into one syscall.  Requested binding is Micro/Patch. >>> >>> Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI >>> This information is Copyright (c) 2010, Oracle and/or its affiliates. All >>> rights reserved. >>> 1. Introduction >>>    1.1. Project/Component Working Name: >>>         Unified sharing system call >>>    1.2. Name of Document Author/Supplier: >>>         Author:  Afshin Salek >>>    1.3  Date of This Document: >>>        04 May, 2010 >>> >>> 4. Technical Description >>> >>>   4.1. Details >>> >>> Currently, two system calls and a door are used to publish shares: the >>> nfsys multi-purpose system call to export NFS shares, the sharefs system >>> call to update sharetab and an smbd door to publish SMB shares.  libshare >>> has to call the NFS or SMB service once per file system and then it has >>> to call sharefs once per share, which results in 1000's of system calls >>> to publish 1000's of shares. >>> >>> This is a proposal to unify all file sharing via a single system call: >>> sharefs.  It is also to support of PSARC 2010/124 (libshare V2), which >>> requires changes to NFS, SMB and ZFS. >>> >>> Publishing all shares via a single system call has several advantages: >>> simplifies libshare, significantly reduces the number of system calls >>> per file system and per share, and improves integration between sharetab >>> and the protocol services.  Libshare will call sharefs once per file >>> system (for each protocol that has something to share) with a list of >>> shares and the protocol services will update sharetab by making calls >>> to an in-kernel sharefs API.  There will be no user space interface to >>> update sharetab directly. >>> >>> Having the protocol services update the sharetab file has two advantages >>> for libshare and sharefs: it significantly reduces the number of system >>> calls, as explained above, and neither libshare nor sharefs need to >>> perform per share error handling.  Each protocol service handles its own >>> [un]publish operations and is responsible for updating sharetab as >>> appropriate.  There is no need for the protocol services to return a list >>> of individual share results. >>> >>> The sharefs system call would be changed to accept: a protocol >>> discriminator >>> (NFS or SMB), an operation (publish or unpublish) and an opaque pointer >>> to >>> share data.  The opaque data passes transparently through sharefs between >>> the protocol-specific libshare plugin and the protocol service per PSARC >>> 2010/124.  The new prototype for sharefs would be of the form: >>> >>>    int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, >>>        void *data, size_t datalen); >> >> Please do me a small favour and add a flags field, e.g. turn this >> prototype into: >> -- snip -- >>    int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, >>        void *data, size_t datalen, uint32_t flags); >> -- snip -- >> >> The idea is that future consumers (e.g. AFS etc.) can use this for >> _easy_ extensions without having to change this API again (and please >> don't say this is not needed - see |fork()| vs. |forkx()|). > > If a new protocol needs to be supported that should be added to > sharefs_proto_t. If a new operation needs to be supported that > should be added to sharefs_op_t. > > So, what kind of extension are you talking about here? I am talking about the _general_ observation that such APIs evolve over years and sometimes the lack of such flag fields to define extensions cause trouble, usually in the form of an API change or a 2nd sibling API (or syscall). I've seen that kind of issue crawling-up in things ranging over UNIX, AmigaOS (mainly in the widget API, for AmigaOS2.0 a novel solution was found which (unfortunately) was forgotten in the history of API design (well, |posix_spawn()| has something similar, but that is not suprising since one of the authors once was at CBM)), Motif (e.g. many changes between Motif 1.x and 2.x were exactly about dealing with needed extensions where the original authors didn't imangine possible extensions (or brushed them aside with comments like "we never need it")), X11 (both the core protocol, client libraries and the Xserver driver API), GTK+ etc etc etc. It's always the same story, problem and usually noone cares until it is too late: No flag field (or other method of extension) of a (semi-)public API and later horrible workarounds are invented to deal with the inflexibilty and crawl&&creep around and prey on developer minds. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From darren.reed@oracle.com Tue May 11 16:39:13 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4BNdDNF000609 for ; Tue, 11 May 2010 16:39:13 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4BNdCm1020061 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 16:39:12 -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 <0L2A0015D4DCB800@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 16:39:12 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2A005YM4DCLBA0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 16:39:12 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4BNdBaD024240 for ; Tue, 11 May 2010 23:39:11 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4BM5t6w002201 for ; Tue, 11 May 2010 23:39:11 +0000 (GMT) Received: from abhmt002.oracle.com by acsmt354.oracle.com with ESMTP id 256615141273621148; Tue, 11 May 2010 16:39:08 -0700 Received: from mintslice.sfbay.sun.com (/129.146.106.55) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 16:39:07 -0700 Date: Tue, 11 May 2010 16:39:25 -0700 From: Darren Reed Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE09ED2.6080505@oracle.com> To: Tim Haley Cc: PSARC-ext@sun.com, nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com, afshin.salek@oracle.com Message-id: <4BE9EAAD.7010706@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BE9EA9F.00DA:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-GB; rv:1.9.1.5) Gecko/20091206 Thunderbird/3.0 Status: RO Content-Length: 277 In the document, it talks about sharing being per filesystem. Is that actually the case? Or does this interface only handle path names and is it thus up to the file sharing protocol to determine whether or not it will allow a directory shared vs a full file system? Darren From darren.reed@oracle.com Tue May 11 16:39:13 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4BNdD0g000613 for ; Tue, 11 May 2010 16:39:13 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4BNdDeN001158 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 18:39:13 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2A001214DDCI00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 16:39:13 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2A005Z94DCLC80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 16:39:12 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4BNdCkx023336 for ; Tue, 11 May 2010 23:39:12 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4BM5t70002201 for ; Tue, 11 May 2010 23:39:11 +0000 (GMT) Received: from abhmt002.oracle.com by acsmt354.oracle.com with ESMTP id 256615141273621148; Tue, 11 May 2010 16:39:08 -0700 Received: from mintslice.sfbay.sun.com (/129.146.106.55) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 16:39:07 -0700 Date: Tue, 11 May 2010 16:39:25 -0700 From: Darren Reed Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE09ED2.6080505@oracle.com> To: Tim Haley Cc: PSARC-ext@sun.com, nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com, afshin.salek@oracle.com Message-id: <4BE9EAAD.7010706@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BE9EA9F.0187:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-GB; rv:1.9.1.5) Gecko/20091206 Thunderbird/3.0 Status: RO Content-Length: 277 In the document, it talks about sharing being per filesystem. Is that actually the case? Or does this interface only handle path names and is it thus up to the file sharing protocol to determine whether or not it will allow a directory shared vs a full file system? Darren From Afshin.Salek@Oracle.com Tue May 11 17:23:17 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4C0NHoM001223 for ; Tue, 11 May 2010 17:23:17 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4C0NHu6009178 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 17:23:17 -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 <0L2A001036ET0100@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 17:23:17 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2A00GPQ6ETH0B0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 17:23:17 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4C0NGSt011051 for ; Wed, 12 May 2010 00:23:16 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4C03gq6022669 for ; Wed, 12 May 2010 00:23:16 +0000 (GMT) Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 256693851273623776; Tue, 11 May 2010 17:22:56 -0700 Received: from [10.1.106.212] (/10.1.106.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 17:22:56 -0700 Date: Tue, 11 May 2010 17:22:44 -0700 From: Afshin Salek Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE9EAAD.7010706@oracle.com> To: Darren Reed Cc: Tim Haley , PSARC-ext@sun.com, nfs-instance_ww@Oracle.com, libshare-team_ww@Oracle.com, mark.shellenbaum@Oracle.com Message-id: <4BE9F4D4.7050609@Oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BE9F4F4.00A6:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE9EAAD.7010706@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 849 What it means by sharing per filesystem is that libshare V2 builds a list of all shares defined on a filesystem (i.e. zfs dataset) and passes the whole list to sharefs. sharefs then passes this list of shares to the appropriate protocol service where each share is [un]published individually. Each share definition is comprised of path, resource name and all other associated properties. Shares are uniquely identified by their path + resource name so these two properties must be present for all shares. Afshin On 05/11/10 04:39 PM, Darren Reed wrote: > In the document, it talks about sharing being per filesystem. > > Is that actually the case? > > Or does this interface only handle path names and is it > thus up to the file sharing protocol to determine whether > or not it will allow a directory shared vs a full file system? > > Darren > From Afshin.Salek@Oracle.com Tue May 11 17:23:19 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4C0NJiL001227 for ; Tue, 11 May 2010 17:23:19 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4C0NIO7019433 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 19:23:18 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2A001076EU0200@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 17:23:18 -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 <0L2A00G3F6ETH2D0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 17:23:18 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4C0NHQo006924 for ; Wed, 12 May 2010 00:23:17 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4C03gq8022669 for ; Wed, 12 May 2010 00:23:16 +0000 (GMT) Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 256693851273623776; Tue, 11 May 2010 17:22:56 -0700 Received: from [10.1.106.212] (/10.1.106.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 17:22:56 -0700 Date: Tue, 11 May 2010 17:22:44 -0700 From: Afshin Salek Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE9EAAD.7010706@oracle.com> To: Darren Reed Cc: Tim Haley , PSARC-ext@sun.com, nfs-instance_ww@Oracle.com, libshare-team_ww@Oracle.com, mark.shellenbaum@Oracle.com Message-id: <4BE9F4D4.7050609@Oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BE9F4F5.0026:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE9EAAD.7010706@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 849 What it means by sharing per filesystem is that libshare V2 builds a list of all shares defined on a filesystem (i.e. zfs dataset) and passes the whole list to sharefs. sharefs then passes this list of shares to the appropriate protocol service where each share is [un]published individually. Each share definition is comprised of path, resource name and all other associated properties. Shares are uniquely identified by their path + resource name so these two properties must be present for all shares. Afshin On 05/11/10 04:39 PM, Darren Reed wrote: > In the document, it talks about sharing being per filesystem. > > Is that actually the case? > > Or does this interface only handle path names and is it > thus up to the file sharing protocol to determine whether > or not it will allow a directory shared vs a full file system? > > Darren > From Afshin.Salek@Oracle.com Tue May 11 17:25:48 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4C0Pmf2001259 for ; Tue, 11 May 2010 17:25:48 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4C0PlBK000070 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 18:25:48 -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 <0L2A0010V6J04S00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 17:25:48 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2A00GJN6IZGTB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 17:25:48 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4C0PlNs020880 for ; Wed, 12 May 2010 00:25:47 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4C01fB1007403 for ; Wed, 12 May 2010 00:25:47 +0000 (GMT) Received: from abhmt010.oracle.com by acsmt353.oracle.com with ESMTP id 256698151273623937; Tue, 11 May 2010 17:25:37 -0700 Received: from [10.1.106.212] (/10.1.106.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 17:25:36 -0700 Date: Tue, 11 May 2010 17:25:24 -0700 From: Afshin Salek Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE9F4D4.7050609@Oracle.com> To: Darren Reed Cc: Tim Haley , PSARC-ext@sun.com, nfs-instance_ww@Oracle.com, libshare-team_ww@Oracle.com, mark.shellenbaum@Oracle.com Message-id: <4BE9F574.1090001@Oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BE9F58B.0094:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE9EAAD.7010706@oracle.com> <4BE9F4D4.7050609@Oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1149 I forgot to mention that, this only happens at startup time, when a filesystem mounted or when zfs sharesmb is set to on. When an individual share is added/removed, the mentioned list would contain only one share. Afshin On 05/11/10 05:22 PM, Afshin Salek wrote: > What it means by sharing per filesystem is that libshare V2 builds > a list of all shares defined on a filesystem (i.e. zfs dataset) and > passes the whole list to sharefs. sharefs then passes this list of > shares to the appropriate protocol service where each share is > [un]published individually. > > Each share definition is comprised of path, resource name > and all other associated properties. Shares are uniquely > identified by their path + resource name so these two properties > must be present for all shares. > > Afshin > > On 05/11/10 04:39 PM, Darren Reed wrote: >> In the document, it talks about sharing being per filesystem. >> >> Is that actually the case? >> >> Or does this interface only handle path names and is it >> thus up to the file sharing protocol to determine whether >> or not it will allow a directory shared vs a full file system? >> >> Darren >> From Afshin.Salek@Oracle.com Tue May 11 17:25:50 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4C0Po4d001263 for ; Tue, 11 May 2010 17:25:50 -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 o4C0PlNF009790 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 17:25: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 <0L2A000456J1EZ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 18:25:49 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2A00H5Z6IZ5270@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 18:25:47 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4C0Pk7o010752 for ; Wed, 12 May 2010 00:25:47 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4C01fAx007403 for ; Wed, 12 May 2010 00:25:46 +0000 (GMT) Received: from abhmt010.oracle.com by acsmt353.oracle.com with ESMTP id 256698151273623937; Tue, 11 May 2010 17:25:37 -0700 Received: from [10.1.106.212] (/10.1.106.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 17:25:36 -0700 Date: Tue, 11 May 2010 17:25:24 -0700 From: Afshin Salek Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE9F4D4.7050609@Oracle.com> To: Darren Reed Cc: Tim Haley , PSARC-ext@sun.com, nfs-instance_ww@Oracle.com, libshare-team_ww@Oracle.com, mark.shellenbaum@Oracle.com Message-id: <4BE9F574.1090001@Oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BE9F58A.0131:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE9EAAD.7010706@oracle.com> <4BE9F4D4.7050609@Oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1149 I forgot to mention that, this only happens at startup time, when a filesystem mounted or when zfs sharesmb is set to on. When an individual share is added/removed, the mentioned list would contain only one share. Afshin On 05/11/10 05:22 PM, Afshin Salek wrote: > What it means by sharing per filesystem is that libshare V2 builds > a list of all shares defined on a filesystem (i.e. zfs dataset) and > passes the whole list to sharefs. sharefs then passes this list of > shares to the appropriate protocol service where each share is > [un]published individually. > > Each share definition is comprised of path, resource name > and all other associated properties. Shares are uniquely > identified by their path + resource name so these two properties > must be present for all shares. > > Afshin > > On 05/11/10 04:39 PM, Darren Reed wrote: >> In the document, it talks about sharing being per filesystem. >> >> Is that actually the case? >> >> Or does this interface only handle path names and is it >> thus up to the file sharing protocol to determine whether >> or not it will allow a directory shared vs a full file system? >> >> Darren >> From darren.reed@oracle.com Tue May 11 17:34:35 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4C0YZN2001330 for ; Tue, 11 May 2010 17:34:35 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4C0YZCV013059 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 17:34:35 -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 <0L2A001016XNI600@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 17:34:35 -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 <0L2A00GYG6XMGYD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 17:34:34 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4C0YXqU014047 for ; Wed, 12 May 2010 00:34:34 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4C03jMA022759 for ; Wed, 12 May 2010 00:34:33 +0000 (GMT) Received: from abhmt008.oracle.com by acsmt355.oracle.com with ESMTP id 256717671273624471; Tue, 11 May 2010 17:34:31 -0700 Received: from mintslice.sfbay.sun.com (/129.146.106.55) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 17:34:31 -0700 Date: Tue, 11 May 2010 17:34:47 -0700 From: Darren Reed Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE9F4D4.7050609@Oracle.com> To: Afshin Salek Cc: Tim Haley , PSARC-ext@sun.com, nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com Message-id: <4BE9F7A7.10306@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BE9F799.0123:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE9EAAD.7010706@oracle.com> <4BE9F4D4.7050609@Oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-GB; rv:1.9.1.5) Gecko/20091206 Thunderbird/3.0 Status: RO Content-Length: 1203 You still haven't directly answered the question I asked. Maybe I'll be more direct. Can I share only a specific directory within a filesystem? Or must I share the entire filesystem? Or is the choice over what's allowed defined by what is implementing the sharing? Darren On 11/05/10 05:22 PM, Afshin Salek wrote: > What it means by sharing per filesystem is that libshare V2 builds > a list of all shares defined on a filesystem (i.e. zfs dataset) and > passes the whole list to sharefs. sharefs then passes this list of > shares to the appropriate protocol service where each share is > [un]published individually. > > Each share definition is comprised of path, resource name > and all other associated properties. Shares are uniquely > identified by their path + resource name so these two properties > must be present for all shares. > > Afshin > > On 05/11/10 04:39 PM, Darren Reed wrote: >> In the document, it talks about sharing being per filesystem. >> >> Is that actually the case? >> >> Or does this interface only handle path names and is it >> thus up to the file sharing protocol to determine whether >> or not it will allow a directory shared vs a full file system? >> >> Darren >> From darren.reed@oracle.com Tue May 11 17:34:37 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4C0YaED001334 for ; Tue, 11 May 2010 17:34:37 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4C0YaC5023341 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 19:34:36 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2A00E196XOU200@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 17:34:36 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2A005V66XMLSE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 17:34:35 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4C0YYCB012116 for ; Wed, 12 May 2010 00:34:34 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4C03jMC022759 for ; Wed, 12 May 2010 00:34:33 +0000 (GMT) Received: from abhmt008.oracle.com by acsmt355.oracle.com with ESMTP id 256717671273624471; Tue, 11 May 2010 17:34:31 -0700 Received: from mintslice.sfbay.sun.com (/129.146.106.55) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 17:34:31 -0700 Date: Tue, 11 May 2010 17:34:47 -0700 From: Darren Reed Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE9F4D4.7050609@Oracle.com> To: Afshin Salek Cc: Tim Haley , PSARC-ext@sun.com, nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com Message-id: <4BE9F7A7.10306@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BE9F79A.004E:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE9EAAD.7010706@oracle.com> <4BE9F4D4.7050609@Oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-GB; rv:1.9.1.5) Gecko/20091206 Thunderbird/3.0 Status: RO Content-Length: 1203 You still haven't directly answered the question I asked. Maybe I'll be more direct. Can I share only a specific directory within a filesystem? Or must I share the entire filesystem? Or is the choice over what's allowed defined by what is implementing the sharing? Darren On 11/05/10 05:22 PM, Afshin Salek wrote: > What it means by sharing per filesystem is that libshare V2 builds > a list of all shares defined on a filesystem (i.e. zfs dataset) and > passes the whole list to sharefs. sharefs then passes this list of > shares to the appropriate protocol service where each share is > [un]published individually. > > Each share definition is comprised of path, resource name > and all other associated properties. Shares are uniquely > identified by their path + resource name so these two properties > must be present for all shares. > > Afshin > > On 05/11/10 04:39 PM, Darren Reed wrote: >> In the document, it talks about sharing being per filesystem. >> >> Is that actually the case? >> >> Or does this interface only handle path names and is it >> thus up to the file sharing protocol to determine whether >> or not it will allow a directory shared vs a full file system? >> >> Darren >> From helen.chao@oracle.com Tue May 11 17:38:45 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4C0ciVF001361 for ; Tue, 11 May 2010 17:38:45 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4C0cium005858 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 18:38:44 -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 <0L2A0010774KPF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 17:38:44 -0700 (PDT) Received: from jurassic.Eng.Sun.COM ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2A00GUY74KH6E0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 17:38:44 -0700 (PDT) Received: from [129.146.108.61] (jackwah.SFBay.Sun.COM [129.146.108.61]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o4C0chGW214929; Tue, 11 May 2010 17:38:43 -0700 (PDT) Date: Tue, 11 May 2010 17:38:57 -0700 From: Helen Chao Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE9F7A7.10306@oracle.com> To: Darren Reed Cc: Afshin Salek , Tim Haley , PSARC-ext@sun.com, nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com Message-id: <4BE9F8A1.9070801@oracle.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_d6ZFWsfZtK9uPvAs5M4XMw)" X-PMX-Version: 5.4.1.325704 References: <4BE09ED2.6080505@oracle.com> <4BE9EAAD.7010706@oracle.com> <4BE9F4D4.7050609@Oracle.com> <4BE9F7A7.10306@oracle.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081215) Status: RO Content-Length: 1743 This is a multi-part message in MIME format. --Boundary_(ID_d6ZFWsfZtK9uPvAs5M4XMw) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT On 05/11/10 17:34, Darren Reed wrote: > You still haven't directly answered the question I asked. > > Maybe I'll be more direct. > > Can I share only a specific directory within a filesystem? Yes for NFS, as long as the parent filesystem/directory has not been shared. > Or must I share the entire filesystem? > Or is the choice over what's allowed defined by what is > implementing the sharing? -- Thanks, Helen --Boundary_(ID_d6ZFWsfZtK9uPvAs5M4XMw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT On 05/11/10 17:34, Darren Reed wrote:
You still haven't directly answered the question I asked.

Maybe I'll be more direct.

Can I share only a specific directory within a filesystem?

Yes for NFS, as long as the parent filesystem/directory
has not been shared.

Or must I share the entire filesystem?
Or is the choice over what's allowed defined by what is
implementing the sharing? 


-- 

Thanks,
Helen
--Boundary_(ID_d6ZFWsfZtK9uPvAs5M4XMw)-- From thomas.h.poon@oracle.com Tue May 11 17:52:21 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4C0qL4w001439 for ; Tue, 11 May 2010 17:52:21 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4C0qLkW013099 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 18:52:21 -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 <0L2A00J037R9E900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 17:52:21 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2A005V97R8LQD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 17:52:20 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4C0qKom020265 for ; Wed, 12 May 2010 00:52:20 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4C03gqQ022669 for ; Wed, 12 May 2010 00:52:19 +0000 (GMT) Received: from abhmt020.oracle.com by acsmt355.oracle.com with ESMTP id 256747411273625534; Tue, 11 May 2010 17:52:14 -0700 Received: from [10.1.106.73] (/10.1.106.73) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 17:52:13 -0700 Date: Tue, 11 May 2010 17:53:43 -0700 From: "thomas.h.poon" Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE9F8A1.9070801@oracle.com> To: Helen Chao Cc: Darren Reed , Afshin Salek , Tim Haley , PSARC-ext@sun.com, nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com Message-id: <4BE9FC17.1080502@oracle.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_qIU0gaQBR0Rd2BIUSd22Qg)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BE9FBC3.0173:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE9EAAD.7010706@oracle.com> <4BE9F4D4.7050609@Oracle.com> <4BE9F7A7.10306@oracle.com> <4BE9F8A1.9070801@oracle.com> User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) Status: RO Content-Length: 2270 This is a multi-part message in MIME format. --Boundary_(ID_qIU0gaQBR0Rd2BIUSd22Qg) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Helen Chao wrote: > On 05/11/10 17:34, Darren Reed wrote: >> You still haven't directly answered the question I asked. >> >> Maybe I'll be more direct. >> >> Can I share only a specific directory within a filesystem? > > Yes for NFS, as long as the parent filesystem/directory > has not been shared. It is the same case for SMB. You can map a share with specific directory in a filesystem. > >> Or must I share the entire filesystem? >> Or is the choice over what's allowed defined by what is >> implementing the sharing? > > > -- > > Thanks, > Helen > > --Boundary_(ID_qIU0gaQBR0Rd2BIUSd22Qg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Helen Chao wrote:
On 05/11/10 17:34, Darren Reed wrote:
You still haven't directly answered the question I asked.

Maybe I'll be more direct.

Can I share only a specific directory within a filesystem?

Yes for NFS, as long as the parent filesystem/directory
has not been shared.
It is the same case for SMB.
You can map a share with specific directory in a filesystem.

Or must I share the entire filesystem?
Or is the choice over what's allowed defined by what is
implementing the sharing? 


-- 

Thanks,
Helen

--Boundary_(ID_qIU0gaQBR0Rd2BIUSd22Qg)-- From thomas.h.poon@oracle.com Tue May 11 17:52:22 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4C0qMij001443 for ; Tue, 11 May 2010 17:52:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4C0qM3t001004 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 19:52:22 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2A00J0F7R9E900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 17:52:21 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2A005EL7R9LIE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 17:52:21 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4C0qKRK012509 for ; Wed, 12 May 2010 00:52:21 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4C03gqS022669 for ; Wed, 12 May 2010 00:52:20 +0000 (GMT) Received: from abhmt020.oracle.com by acsmt355.oracle.com with ESMTP id 256747411273625534; Tue, 11 May 2010 17:52:14 -0700 Received: from [10.1.106.73] (/10.1.106.73) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 17:52:13 -0700 Date: Tue, 11 May 2010 17:53:43 -0700 From: "thomas.h.poon" Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE9F8A1.9070801@oracle.com> To: Helen Chao Cc: Darren Reed , Afshin Salek , Tim Haley , PSARC-ext@sun.com, nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com Message-id: <4BE9FC17.1080502@oracle.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_mnyR1CCso/0be9s/llIAGA)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BE9FBC4.0143:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE9EAAD.7010706@oracle.com> <4BE9F4D4.7050609@Oracle.com> <4BE9F7A7.10306@oracle.com> <4BE9F8A1.9070801@oracle.com> User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) Status: RO Content-Length: 2270 This is a multi-part message in MIME format. --Boundary_(ID_mnyR1CCso/0be9s/llIAGA) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Helen Chao wrote: > On 05/11/10 17:34, Darren Reed wrote: >> You still haven't directly answered the question I asked. >> >> Maybe I'll be more direct. >> >> Can I share only a specific directory within a filesystem? > > Yes for NFS, as long as the parent filesystem/directory > has not been shared. It is the same case for SMB. You can map a share with specific directory in a filesystem. > >> Or must I share the entire filesystem? >> Or is the choice over what's allowed defined by what is >> implementing the sharing? > > > -- > > Thanks, > Helen > > --Boundary_(ID_mnyR1CCso/0be9s/llIAGA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Helen Chao wrote:
On 05/11/10 17:34, Darren Reed wrote:
You still haven't directly answered the question I asked.

Maybe I'll be more direct.

Can I share only a specific directory within a filesystem?

Yes for NFS, as long as the parent filesystem/directory
has not been shared.
It is the same case for SMB.
You can map a share with specific directory in a filesystem.

Or must I share the entire filesystem?
Or is the choice over what's allowed defined by what is
implementing the sharing? 


-- 

Thanks,
Helen

--Boundary_(ID_mnyR1CCso/0be9s/llIAGA)-- From Afshin.Salek@Oracle.com Tue May 11 17:58:16 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4C0wGV3001866 for ; Tue, 11 May 2010 17:58:16 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4C0wGkA003182 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 19:58:16 -0500 (CDT) 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 <0L2A00303814AH00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 18:58:16 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2A00H3R8134Y90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 18:58:15 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4C0wFWi014392 for ; Wed, 12 May 2010 00:58:15 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4BNfJjh021177 for ; Wed, 12 May 2010 00:58:14 +0000 (GMT) Received: from abhmt016.oracle.com by acsmt354.oracle.com with ESMTP id 233423861273625887; Tue, 11 May 2010 17:58:07 -0700 Received: from [10.1.106.212] (/10.1.106.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 17:58:07 -0700 Date: Tue, 11 May 2010 17:57:56 -0700 From: Afshin Salek Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE9F7A7.10306@oracle.com> To: Darren Reed Cc: Tim Haley , PSARC-ext@sun.com, nfs-instance_ww@Oracle.com, libshare-team_ww@Oracle.com, mark.shellenbaum@Oracle.com Message-id: <4BE9FD14.3040905@Oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BE9FD26.01A9:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE9EAAD.7010706@oracle.com> <4BE9F4D4.7050609@Oracle.com> <4BE9F7A7.10306@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1423 Yes, it is possible to [un]share an individual directory within a file system without having to share the whole file system. Afshin On 05/11/10 05:34 PM, Darren Reed wrote: > You still haven't directly answered the question I asked. > > Maybe I'll be more direct. > > Can I share only a specific directory within a filesystem? > Or must I share the entire filesystem? > Or is the choice over what's allowed defined by what is > implementing the sharing? > > Darren > > On 11/05/10 05:22 PM, Afshin Salek wrote: >> What it means by sharing per filesystem is that libshare V2 builds >> a list of all shares defined on a filesystem (i.e. zfs dataset) and >> passes the whole list to sharefs. sharefs then passes this list of >> shares to the appropriate protocol service where each share is >> [un]published individually. >> >> Each share definition is comprised of path, resource name >> and all other associated properties. Shares are uniquely >> identified by their path + resource name so these two properties >> must be present for all shares. >> >> Afshin >> >> On 05/11/10 04:39 PM, Darren Reed wrote: >>> In the document, it talks about sharing being per filesystem. >>> >>> Is that actually the case? >>> >>> Or does this interface only handle path names and is it >>> thus up to the file sharing protocol to determine whether >>> or not it will allow a directory shared vs a full file system? >>> >>> Darren >>> > From Afshin.Salek@Oracle.com Tue May 11 17:58:17 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4C0wHQi001870 for ; Tue, 11 May 2010 17:58:17 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4C0wG0Y003192 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 19:58:16 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2A00207814KF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 17:58:16 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2A00GVK813H0E0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 17:58:16 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4C0wF7R013229 for ; Wed, 12 May 2010 00:58:15 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4BNfJjj021177 for ; Wed, 12 May 2010 00:58:15 +0000 (GMT) Received: from abhmt016.oracle.com by acsmt354.oracle.com with ESMTP id 233423861273625887; Tue, 11 May 2010 17:58:07 -0700 Received: from [10.1.106.212] (/10.1.106.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 17:58:07 -0700 Date: Tue, 11 May 2010 17:57:56 -0700 From: Afshin Salek Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE9F7A7.10306@oracle.com> To: Darren Reed Cc: Tim Haley , PSARC-ext@sun.com, nfs-instance_ww@Oracle.com, libshare-team_ww@Oracle.com, mark.shellenbaum@Oracle.com Message-id: <4BE9FD14.3040905@Oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BE9FD27.00AA:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE9EAAD.7010706@oracle.com> <4BE9F4D4.7050609@Oracle.com> <4BE9F7A7.10306@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1423 Yes, it is possible to [un]share an individual directory within a file system without having to share the whole file system. Afshin On 05/11/10 05:34 PM, Darren Reed wrote: > You still haven't directly answered the question I asked. > > Maybe I'll be more direct. > > Can I share only a specific directory within a filesystem? > Or must I share the entire filesystem? > Or is the choice over what's allowed defined by what is > implementing the sharing? > > Darren > > On 11/05/10 05:22 PM, Afshin Salek wrote: >> What it means by sharing per filesystem is that libshare V2 builds >> a list of all shares defined on a filesystem (i.e. zfs dataset) and >> passes the whole list to sharefs. sharefs then passes this list of >> shares to the appropriate protocol service where each share is >> [un]published individually. >> >> Each share definition is comprised of path, resource name >> and all other associated properties. Shares are uniquely >> identified by their path + resource name so these two properties >> must be present for all shares. >> >> Afshin >> >> On 05/11/10 04:39 PM, Darren Reed wrote: >>> In the document, it talks about sharing being per filesystem. >>> >>> Is that actually the case? >>> >>> Or does this interface only handle path names and is it >>> thus up to the file sharing protocol to determine whether >>> or not it will allow a directory shared vs a full file system? >>> >>> Darren >>> > From barry.greenberg@oracle.com Tue May 11 18:04:43 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4C14gnF001995 for ; Tue, 11 May 2010 18:04:43 -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 o4C14gNO024403 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 18:04:42 -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 <0L2A0030F8BUU700@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 19:04:42 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2A00H9H8BU4X90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 19:04:42 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4C14ftN026066 for ; Wed, 12 May 2010 01:04:42 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4C149Ot007467 for ; Wed, 12 May 2010 01:04:41 +0000 (GMT) Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 256771331273626274; Tue, 11 May 2010 18:04:34 -0700 Received: from [192.168.1.113] (/76.219.227.229) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 18:04:34 -0700 Date: Tue, 11 May 2010 18:04:32 -0700 From: Barry Greenberg Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE9F7A7.10306@oracle.com> To: Darren Reed Cc: Afshin Salek , Tim Haley , PSARC-ext@sun.com, nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com Message-id: <4BE9FEA0.6050604@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BE9FEA9.015F:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE9EAAD.7010706@oracle.com> <4BE9F4D4.7050609@Oracle.com> <4BE9F7A7.10306@oracle.com> User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) Status: RO Content-Length: 370 Darren Reed wrote: > You still haven't directly answered the question I asked. > > Maybe I'll be more direct. > > Can I share only a specific directory within a filesystem? > Or must I share the entire filesystem? > Or is the choice over what's allowed defined by what is > implementing the sharing? > The user-visible behavior of sharing is completely unchanged. --bg From barry.greenberg@oracle.com Tue May 11 18:04:43 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4C14h6g001998 for ; Tue, 11 May 2010 18:04:43 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4C14gKa005839 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 20:04:43 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2A00M018BUL900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 18:04:42 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2A00L468BTQ820@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 18:04:41 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4C14fQ8016868 for ; Wed, 12 May 2010 01:04:41 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4C149Or007467 for ; Wed, 12 May 2010 01:04:40 +0000 (GMT) Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 256771331273626274; Tue, 11 May 2010 18:04:34 -0700 Received: from [192.168.1.113] (/76.219.227.229) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 18:04:34 -0700 Date: Tue, 11 May 2010 18:04:32 -0700 From: Barry Greenberg Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE9F7A7.10306@oracle.com> To: Darren Reed Cc: Afshin Salek , Tim Haley , PSARC-ext@sun.com, nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com Message-id: <4BE9FEA0.6050604@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BE9FEA9.001E:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE9EAAD.7010706@oracle.com> <4BE9F4D4.7050609@Oracle.com> <4BE9F7A7.10306@oracle.com> User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) Status: RO Content-Length: 370 Darren Reed wrote: > You still haven't directly answered the question I asked. > > Maybe I'll be more direct. > > Can I share only a specific directory within a filesystem? > Or must I share the entire filesystem? > Or is the choice over what's allowed defined by what is > implementing the sharing? > The user-visible behavior of sharing is completely unchanged. --bg From sebastien.roy@oracle.com Tue May 11 19:05:21 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4C25KhO002607 for ; Tue, 11 May 2010 19:05:21 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4C25KES045546 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 20:05:20 -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 <0L2A00903B4W0I00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 20:05:20 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2A00H1KB4W4UF0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 20:05:20 -0600 (MDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4C25Kfu023261 for ; Wed, 12 May 2010 02:05:20 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4C1svxp004271 for ; Wed, 12 May 2010 02:05:19 +0000 (GMT) Received: from abhmt020.oracle.com by acsmt354.oracle.com with ESMTP id 256876771273629911; Tue, 11 May 2010 19:05:11 -0700 Received: from [192.168.1.4] (/173.76.19.159) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 19:05:10 -0700 Date: Tue, 11 May 2010 22:05:08 -0400 From: Sebastien Roy Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE09ED2.6080505@oracle.com> To: Tim Haley Cc: PSARC-ext@sun.com, mark.shellenbaum@oracle.com, libshare-team_ww@oracle.com, nfs-instance_ww@oracle.com Message-id: <4BEA0CD4.9070107@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BEA0CDF.016F:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 762 On 05/ 4/10 06:25 PM, Tim Haley wrote: > Currently, two system calls and a door are used to publish shares: the > nfsys multi-purpose system call to export NFS shares, the sharefs system > call to update sharetab and an smbd door to publish SMB shares. libshare > has to call the NFS or SMB service once per file system and then it has > to call sharefs once per share, which results in 1000's of system calls > to publish 1000's of shares. > > This is a proposal to unify all file sharing via a single system call: > sharefs. It is also to support of PSARC 2010/124 (libshare V2), which > requires changes to NFS, SMB and ZFS. +1 I think it may be worthwhile to explicitly state that the solaris10 brand won't be impacted by this change (and why not). -Seb From sebastien.roy@oracle.com Tue May 11 19:05:22 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4C25Ltq002611 for ; Tue, 11 May 2010 19:05:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4C25LHX029325 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 May 2010 21:05:21 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2A00F07B4X9B00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 19:05:21 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2A006JLB4XCE20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 May 2010 19:05:21 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4C25KdC025872 for ; Wed, 12 May 2010 02:05:20 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4C1svxr004271 for ; Wed, 12 May 2010 02:05:20 +0000 (GMT) Received: from abhmt020.oracle.com by acsmt354.oracle.com with ESMTP id 256876771273629911; Tue, 11 May 2010 19:05:11 -0700 Received: from [192.168.1.4] (/173.76.19.159) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 19:05:10 -0700 Date: Tue, 11 May 2010 22:05:08 -0400 From: Sebastien Roy Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE09ED2.6080505@oracle.com> To: Tim Haley Cc: PSARC-ext@sun.com, mark.shellenbaum@oracle.com, libshare-team_ww@oracle.com, nfs-instance_ww@oracle.com Message-id: <4BEA0CD4.9070107@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BEA0CE0.0096:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 762 On 05/ 4/10 06:25 PM, Tim Haley wrote: > Currently, two system calls and a door are used to publish shares: the > nfsys multi-purpose system call to export NFS shares, the sharefs system > call to update sharetab and an smbd door to publish SMB shares. libshare > has to call the NFS or SMB service once per file system and then it has > to call sharefs once per share, which results in 1000's of system calls > to publish 1000's of shares. > > This is a proposal to unify all file sharing via a single system call: > sharefs. It is also to support of PSARC 2010/124 (libshare V2), which > requires changes to NFS, SMB and ZFS. +1 I think it may be worthwhile to explicitly state that the solaris10 brand won't be impacted by this change (and why not). -Seb From alan.wright@oracle.com Wed May 12 00:58:29 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4C7wSYG028022 for ; Wed, 12 May 2010 00:58:28 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4C7wSkw006695 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 00:58:28 -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 <0L2A00M03RHGKR00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 00:58:28 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2A00EOQRHG1AB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 00:58:28 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4C7wRfB027769 for ; Wed, 12 May 2010 07:58:28 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4C7Aums026182 for ; Wed, 12 May 2010 07:58:27 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt353.oracle.com with ESMTP id 257519561273651094; Wed, 12 May 2010 00:58:14 -0700 Received: from [10.1.106.211] (/10.1.106.211) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 00:58:13 -0700 Date: Wed, 12 May 2010 00:57:17 -0700 From: Alan Wright Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE9FC17.1080502@oracle.com> To: "thomas.h.poon" , Darren Reed Cc: Helen Chao , Afshin Salek , Tim Haley , PSARC-ext@sun.com, nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com Message-id: <4BEA5F5D.6000705@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BEA5FA3.00C2:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE9EAAD.7010706@oracle.com> <4BE9F4D4.7050609@Oracle.com> <4BE9F7A7.10306@oracle.com> <4BE9F8A1.9070801@oracle.com> <4BE9FC17.1080502@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Thunderbird/3.0.1 Status: RO Content-Length: 1059 On 05/11/10 05:53 PM, thomas.h.poon wrote: > Helen Chao wrote: >> On 05/11/10 17:34, Darren Reed wrote: >>> You still haven't directly answered the question I asked. >>> >>> Maybe I'll be more direct. >>> >>> Can I share only a specific directory within a filesystem? >> >> Yes for NFS, as long as the parent filesystem/directory >> has not been shared. > It is the same case for SMB. > You can map a share with specific directory in a filesystem. SMB is more flexible than that: you can share any directory/path multiple times anywhere in the hierarchy with no restriction on whether or not the parent directory is shared. The only rule for SMB is that each share must have a unique, case-insensitive name. >>> Or must I share the entire filesystem? >>> Or is the choice over what's allowed defined by what is >>> implementing the sharing? That's external to this case. The system call is simply a conduit between libshare and sharefs and is not cognizant of what is being shared/unshared or the rules about what can or cannot be shared/unshared. Alan From alan.wright@oracle.com Wed May 12 00:58:29 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4C7wTOJ028026 for ; Wed, 12 May 2010 00:58:29 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4C7wT4J016370 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 01:58:29 -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 <0L2A00G01RHHD500@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 01:58:29 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2A00D2QRHG8420@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 01:58:28 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4C7wS7n005402 for ; Wed, 12 May 2010 07:58:28 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4C7Aumu026182 for ; Wed, 12 May 2010 07:58:27 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt353.oracle.com with ESMTP id 257519561273651094; Wed, 12 May 2010 00:58:14 -0700 Received: from [10.1.106.211] (/10.1.106.211) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 00:58:13 -0700 Date: Wed, 12 May 2010 00:57:17 -0700 From: Alan Wright Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BE9FC17.1080502@oracle.com> To: "thomas.h.poon" , Darren Reed Cc: Helen Chao , Afshin Salek , Tim Haley , PSARC-ext@sun.com, nfs-instance_ww@oracle.com, libshare-team_ww@oracle.com, mark.shellenbaum@oracle.com Message-id: <4BEA5F5D.6000705@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BEA5FA4.0071:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BE9EAAD.7010706@oracle.com> <4BE9F4D4.7050609@Oracle.com> <4BE9F7A7.10306@oracle.com> <4BE9F8A1.9070801@oracle.com> <4BE9FC17.1080502@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Thunderbird/3.0.1 Status: RO Content-Length: 1059 On 05/11/10 05:53 PM, thomas.h.poon wrote: > Helen Chao wrote: >> On 05/11/10 17:34, Darren Reed wrote: >>> You still haven't directly answered the question I asked. >>> >>> Maybe I'll be more direct. >>> >>> Can I share only a specific directory within a filesystem? >> >> Yes for NFS, as long as the parent filesystem/directory >> has not been shared. > It is the same case for SMB. > You can map a share with specific directory in a filesystem. SMB is more flexible than that: you can share any directory/path multiple times anywhere in the hierarchy with no restriction on whether or not the parent directory is shared. The only rule for SMB is that each share must have a unique, case-insensitive name. >>> Or must I share the entire filesystem? >>> Or is the choice over what's allowed defined by what is >>> implementing the sharing? That's external to this case. The system call is simply a conduit between libshare and sharefs and is not cognizant of what is being shared/unshared or the rules about what can or cannot be shared/unshared. Alan From joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Wed May 12 04:59:06 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4CBx355002282 for ; Wed, 12 May 2010 04:59:05 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4CBx2sK016431 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 05:59:03 -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 <0L2B003112MET200@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 04:59:02 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B00M8I2MDK9C0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 04:59:01 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4CBpc9X023521 for ; Wed, 12 May 2010 11:59:01 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay44i.sun.com with ESMTP id BT-MMP-399963 for PSARC-ext@sun.com; Wed, 12 May 2010 11:58:56 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-148347385 for PSARC-ext@sun.com; Wed, 12 May 2010 11:58:55 +0000 (Z) Received: from relay03-haj2.antispameurope.com ([83.246.65.53] [83.246.65.53]) by relay4i.sun.com with ESMTP id BT-MMP-4894586 for PSARC-ext@sun.com; Wed, 12 May 2010 11:58:54 +0000 (Z) Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id B088F63C0A6; Wed, 12 May 2010 13:58:53 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 280C463C152; Wed, 12 May 2010 13:58:52 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o4CBwpUp010805; Wed, 12 May 2010 13:58:52 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 13:58:51 +0200 Date: Wed, 12 May 2010 13:58:51 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: Sender: joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: tim.haley@oracle.com, roland.mainz@nrubsig.org Cc: PSARC-ext@sun.com, nfs-instance_ww@oracle.com, mark.shellenbaum@oracle.com, libshare-team_ww@oracle.com Message-id: <4bea97fb.60qbNmXdtxQXPEB0%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.676sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BE09ED2.6080505@oracle.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 12 May 2010 11:58:51.0568 (UTC) FILETIME=[7CF63B00:01CAF1CA] Status: RO Content-Length: 1354 Roland Mainz wrote: > > The sharefs system call would be changed to accept: a protocol discriminator > > (NFS or SMB), an operation (publish or unpublish) and an opaque pointer to > > share data.  The opaque data passes transparently through sharefs between > > the protocol-specific libshare plugin and the protocol service per PSARC > > 2010/124.  The new prototype for sharefs would be of the form: > > > >    int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, > >        void *data, size_t datalen); > > Please do me a small favour and add a flags field, e.g. turn this > prototype into: > -- snip -- > int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, > void *data, size_t datalen, uint32_t flags); > -- snip -- > > The idea is that future consumers (e.g. AFS etc.) can use this for > _easy_ extensions without having to change this API again (and please > don't say this is not needed - see |fork()| vs. |forkx()|). Why do you believe, flags cannot be put into the "data" structure if really needed? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From garrett.damore@oracle.com Wed May 12 08:06:21 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4CF6LaC005728 for ; Wed, 12 May 2010 08:06:21 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4CF6KBP006406 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 08:06:21 -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 <0L2B00603BAKBI00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 09:06:20 -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 <0L2B00EA8BAKTJD0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 09:06:20 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4CF6KUq023725 for ; Wed, 12 May 2010 15:06:20 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4CEM4rL010683 for ; Wed, 12 May 2010 15:06:19 +0000 (GMT) Received: from abhmt004.oracle.com by acsmt355.oracle.com with ESMTP id 258686951273676776; Wed, 12 May 2010 08:06:16 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 08:06:14 -0700 Date: Wed, 12 May 2010 08:06:09 -0700 From: "Garrett D'Amore" Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4bea97fb.60qbNmXdtxQXPEB0%Joerg.Schilling@fokus.fraunhofer.de> To: Joerg.Schilling@fokus.fraunhofer.de Cc: tim.haley@oracle.com, roland.mainz@nrubsig.org, PSARC-ext@sun.com, nfs-instance_ww@oracle.com, mark.shellenbaum@oracle.com, libshare-team_ww@oracle.com Message-id: <4BEAC3E1.7040500@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BEAC3EB.0170:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4bea97fb.60qbNmXdtxQXPEB0%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 1359 On 05/12/10 04:58 AM, Joerg.Schilling@fokus.fraunhofer.de wrote: > Roland Mainz wrote: > > >>> The sharefs system call would be changed to accept: a protocol discriminator >>> (NFS or SMB), an operation (publish or unpublish) and an opaque pointer to >>> share data. The opaque data passes transparently through sharefs between >>> the protocol-specific libshare plugin and the protocol service per PSARC >>> 2010/124. The new prototype for sharefs would be of the form: >>> >>> int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, >>> void *data, size_t datalen); >>> >> Please do me a small favour and add a flags field, e.g. turn this >> prototype into: >> -- snip -- >> int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, >> void *data, size_t datalen, uint32_t flags); >> -- snip -- >> >> The idea is that future consumers (e.g. AFS etc.) can use this for >> _easy_ extensions without having to change this API again (and please >> don't say this is not needed - see |fork()| vs. |forkx()|). >> > Why do you believe, flags cannot be put into the "data" structure if really > needed? > Its a moot point. The API is private between the kernel and library, and thus can evolve in whatever way is necessary in the future without impacting other software. - Garrett From garrett.damore@oracle.com Wed May 12 08:06:23 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4CF6M5a005732 for ; Wed, 12 May 2010 08:06:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4CF6MF4000014 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 May 2010 09:06:22 -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 <0L2B0010JBAMRG00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 08:06:22 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B00GYFBAL55D0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 May 2010 08:06:21 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4CF6KhI027224 for ; Wed, 12 May 2010 15:06:20 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4CEM4rN010683 for ; Wed, 12 May 2010 15:06:20 +0000 (GMT) Received: from abhmt004.oracle.com by acsmt355.oracle.com with ESMTP id 258686951273676776; Wed, 12 May 2010 08:06:16 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 08:06:14 -0700 Date: Wed, 12 May 2010 08:06:09 -0700 From: "Garrett D'Amore" Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4bea97fb.60qbNmXdtxQXPEB0%Joerg.Schilling@fokus.fraunhofer.de> To: Joerg.Schilling@fokus.fraunhofer.de Cc: tim.haley@oracle.com, roland.mainz@nrubsig.org, PSARC-ext@sun.com, nfs-instance_ww@oracle.com, mark.shellenbaum@oracle.com, libshare-team_ww@oracle.com Message-id: <4BEAC3E1.7040500@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BEAC3EC.00CE:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4bea97fb.60qbNmXdtxQXPEB0%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 1359 On 05/12/10 04:58 AM, Joerg.Schilling@fokus.fraunhofer.de wrote: > Roland Mainz wrote: > > >>> The sharefs system call would be changed to accept: a protocol discriminator >>> (NFS or SMB), an operation (publish or unpublish) and an opaque pointer to >>> share data. The opaque data passes transparently through sharefs between >>> the protocol-specific libshare plugin and the protocol service per PSARC >>> 2010/124. The new prototype for sharefs would be of the form: >>> >>> int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, >>> void *data, size_t datalen); >>> >> Please do me a small favour and add a flags field, e.g. turn this >> prototype into: >> -- snip -- >> int sharefs(sharefs_proto_t proto, sharefs_op_t opcode, >> void *data, size_t datalen, uint32_t flags); >> -- snip -- >> >> The idea is that future consumers (e.g. AFS etc.) can use this for >> _easy_ extensions without having to change this API again (and please >> don't say this is not needed - see |fork()| vs. |forkx()|). >> > Why do you believe, flags cannot be put into the "data" structure if really > needed? > Its a moot point. The API is private between the kernel and library, and thus can evolve in whatever way is necessary in the future without impacting other software. - Garrett From tim.haley@oracle.com Thu May 13 08:10:04 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4DFA4JJ025262 for ; Thu, 13 May 2010 08:10:04 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4DFA15D016814 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 May 2010 10:10:04 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2D0000N64R9P00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 08:10:03 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2D00F6O64QCBD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 08:10:02 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4DFA200025328 for ; Thu, 13 May 2010 15:10:02 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4DEBPls010464 for ; Thu, 13 May 2010 15:10:00 +0000 (GMT) Received: from abhmt016.oracle.com by acsmt353.oracle.com with ESMTP id 262117511273763400; Thu, 13 May 2010 08:10:00 -0700 Received: from [172.20.25.27] (/10.85.25.27) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 May 2010 08:09:59 -0700 Date: Thu, 13 May 2010 09:09:59 -0600 From: Tim Haley Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BEA0CD4.9070107@oracle.com> To: PSARC-ext@sun.com Cc: mark.shellenbaum@oracle.com, libshare-team_ww@oracle.com, nfs-instance_ww@oracle.com Message-id: <4BEC1647.1010008@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BEC164A.0006:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BEA0CD4.9070107@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 77 This case received a +1 and has timed out. I have marked it approved. -tim From tim.haley@oracle.com Thu May 13 08:10:05 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4DFA5se025264 for ; Thu, 13 May 2010 08:10:05 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4DFA46A018119 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 May 2010 08:10:04 -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 <0L2D0002B64S9400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 08:10:04 -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 <0L2D00FT864RCEC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 May 2010 08:10:03 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4DFA3U7017848 for ; Thu, 13 May 2010 15:10:03 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4DEBPlu010464 for ; Thu, 13 May 2010 15:10:02 +0000 (GMT) Received: from abhmt016.oracle.com by acsmt353.oracle.com with ESMTP id 262117511273763400; Thu, 13 May 2010 08:10:00 -0700 Received: from [172.20.25.27] (/10.85.25.27) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 May 2010 08:09:59 -0700 Date: Thu, 13 May 2010 09:09:59 -0600 From: Tim Haley Subject: Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010] In-reply-to: <4BEA0CD4.9070107@oracle.com> To: PSARC-ext@sun.com Cc: mark.shellenbaum@oracle.com, libshare-team_ww@oracle.com, nfs-instance_ww@oracle.com Message-id: <4BEC1647.1010008@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BEC164A.0128:SCFMA4539814,ss=1,fgs=0 References: <4BE09ED2.6080505@oracle.com> <4BEA0CD4.9070107@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 77 This case received a +1 and has timed out. I have marked it approved. -tim