From Calum.Mackay@sun.com Tue Apr 24 08:26:09 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3OFQ8xh001437 for ; Tue, 24 Apr 2007 08:26:08 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3OFP3dD017498 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 24 Apr 2007 16:25:17 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JH000K01DI35H00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Apr 2007 08:25:15 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JH000EP2DI2JH80@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Apr 2007 08:25:15 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3OFPEDu018849 for ; Tue, 24 Apr 2007 15:25:14 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JH000801DCX8U00@d1-emea-09.sun.com> (original mail from Calum.Mackay@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Apr 2007 16:25:14 +0100 (BST) Received: from [192.168.254.1] ([62.24.230.83]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JH0005OCDHZNUE5@d1-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Apr 2007 16:25:14 +0100 (BST) Date: Tue, 24 Apr 2007 16:25:10 +0100 From: Calum Mackay Subject: 2007/227 VFS Feature Registration and ACL on Create Sender: Calum.Mackay@sun.com To: psarc-ext@sun.com Cc: Rich Brown Message-id: <462E2156.5000606@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 3.0a1 (X11/20070423) Status: RO Content-Length: 14919 I'm sponsoring the following fast-track for Rich Brown. The timer is set to next Weds, 2nd May. The case seeks Minor binding. cheers, calum. CONTEXT This fast-track was spun off of the CIFS Service (PSARC 2006/715) case along with: PSARC 2007/218 caller_context_t in all VOPs Although each of these changes are part of the bigger picture, they have been broken down into smaller pieces so each gets the attention it deserves. Note that the CIFS-related fast-tracks will describe changes to the signatures of vnode operations (VOPs). In some cases, these fast-tracks will describe multiple changes to the same VOPs. The project team intends to integrate all of these changes into ON in a single putback. NOTE: The VFSDEF_VERSION number in sys/vfs.h will be bumped from 3 to 4 in order to prevent unbundled file system kernel modules with the old signatures from loading. Once the unbundled file system modules are updated with the new signatures and recompiled, they will also pick up the new VFSDEF_VERSION number and be allowed to load. Minor binding is requested for these changes. INTRODUCTION This fast-track proposes two changes: 1) VFS Feature Registration - A new mechanism for file systems to register optional features at mount time. An interface for callers to query features is also provided. 2) ACL-on-create - A change to the vnode operations responsible for creation (VOP_CREATE() and VOP_MKDIR()) which will allow an ACL to be set atomically at create time Arguably, these changes could have been submitted separately. The reason for submitting them together is simple: - The VFS Feature Registration mechanism needs at least one feature to register. - The ACL-on-Create change needs to register this feature. VFS FEATURE REGISTRATION The CIFS Server project requires new features for any Solaris file system that intends to fully support CIFS. The initial features include ACL-on-Create, case-insensitive behavior, detection of case-insensitive file name conflicts, and support for new attributes. There is, however, no requirement that all Solaris file systems support all of these new features. The challenge is to support new, optional file system features without requiring all file systems (especially unbundled file systems) to support or even be aware of the new features. The solution is to provide a VFS Feature Registration mechanism. At mount time, a file system can register the set of features that it supports. A set of interfaces to register and query features is provided. The feature information is stored in the vfs which makes it file system independent. Savvy callers can query the features of a file system to make informed decisions on which behavior to request. Finally, the feature registration mechanism allows decisions to be made at the VOP/fop layer so that requests for features not supported by the mounted file system can be rejected. VFS FEATURE INTERFACES The following kernel interfaces are provided to manage vfs features. typedef uint64_t vfs_feature_t; Represents a 32 bit index (upper) and 32 bit mask (lower). See "VFS FEATURE REPRESENTATION" below for details. void vfs_set_feature(vfs_t *vfsp, vfs_feature_t feature) Set the feature in the vfs. int vfs_has_feature(vfs_t *vfsp, vfs_feature_t feature) Returns non-zero if the feature was previously set in the vfs. Returns 0 if the feature was not set. VFS FEATURES Several VFS Features will be defined for the initial implementation. This fast-track includes the following feature needed to support the optional ACL-on-create behavior (described below). /* File system supports setting an ACL on create atomically */ #define VFSFT_ACLONCREATE 0x100000001 The following are additional features that will be fully described in subsequent fast-tracks. DISCLAIMER: The names below are subject to change. VFSFT_XVATTR - File system (FS) supports extensible vattr structure VFSFT_CASEINSENSITIVE - FS supports case insensitive behavior VFSFT_NOCASESENSITIVE - FS does not support case-sensitive behavior VFSFT_DIRENTFLAGS - FS supports flags on directory entries USE OF VFS FEATURE REGISTRATION INTERFACES "VFS features" are intended to represent optional features that mounted file systems may support. Examples of optional features are listed in the "VFS FEATURES" section (above). Not all file system types support all features. (Initially, only ZFS will support these features.) In addition, not all mounted file systems of a given type will necessarily support the same features. For example, a file system may choose to enable a feature based on a property or mount option. The purpose of registering an optional feature is to allow consumers to determine if that feature exists. In most cases, there will be specific parameters in a vfs/vnode operation that need to be set in order to take advantage of the optional behavior. There are three consumers of the VFS Feature Registration interfaces: 1) File systems which support the specific, optional feature. A file system registers a feature by calling vfs_set_feature() in its mount routine. This information is stored in the vfs structure for the mounted file system. 2) Potential consumers of the feature offered by the file system If caller want to take advantage of a feature the caller must first determine if that feature is available for a mounted file system (vfs). This is done by calling vfs_has_feature() and passing the vfs and the desired feature. If vfs_has_feature() returns non-zero, then the feature is available to the caller. In practice, a registered feature will likely have one or more associated arguments in one or more vfs/vnode operations. If the feature is available to the caller, the caller sets those associated parameters accordingly. 3) VFS/vnode routines A request for an optional feature is made typically made by setting certain arguments in the call to the VOP/VFS routines. The intermediate fop/fsop routines (called via the VOP_*/VFS_* macros) will detect if a feature is requested via the associated arguments, then will use vfs_has_feature() to determine if the underlying file system provides the feature and can handle the feature-related arguments. If so, the fop/fsop calls through to the file system. Otherwise, an error is returned to the caller. Callers shall use vfs_has_feature() to determine if the underlying file system supports the optional feature. Double-checking this in the fop/fsop layer protects uncooperative callers from unexpected/undersirable behavior. NOTE: The ACL-on-create text below describes this usage in greater detail. VFS FEATURE REPRESENTATION Features are binary entities: They're either present or not and are best represented by a single bit. However, the number of features could grow very rapidly and allocating a single word (even 64 bits) may not be enough. The challenge is to choose a representation which is easily extensible. The solution is to use a counted array of 32-bit words. Element 0 of the array contains the number of elements in the array. Each element contains 32 bits which are used to represent features. Each feature is represented as a 64 bit word: The most significant 32 bits represent an index into the counted array, starting at 1. The least significant 32 bits contain a single bit which represents the bit corresponding to the feature in that particular element of the array. Examples: 0x100000001 represents the least significant bit of element 1. 0x500000001 represents the least significant bit of element 5. 0x200000008 represents the 0x8 bit of element 2. 0xf00000020 represents the 0x20 bit of element 15. VFS STRUCTURE AND INTERFACE CHANGES Since this mechanism uses a counted array and is associated with the vfs structure of a mounted file system, we need modifications to the vfs and associated structures (vfs_impl_t, which was introduced with PSARC/2006/270 "vfs_femhead change to vfs_implp"): - Add vfs_alloc() and vfs_free() (described below) - Move vi_femhead out of vfs_impl_t and back to the vfs as vfs_femhead where it belongs. - Add a new member to vfs_impl_t: uint32_t vi_featureset[VFS_FEATURE_MAXSZ]; This member implements the counted array of 32-bit words needed to store the vfs features described above. Why are we keeping the vfs_impl_t rather than putting everything in the vfs_t? Ideally, the vfs_t should be completely opaque (See RFE 6506186). This requires more work than is scoped for this project. With this change, vfs_impl_t will contain the structures (featureset, vopstats, and friends) which could grow/change in an update/patch. In order to properly manage the memory associated with the vfs feature array, we need to add a vfs_alloc() and vfs_free() routine which is responsible for allocation/initialization and deallocation, respectively. This will also be helpful to unbundled file systems such as PxFS and MVFS (ClearCase) which currently allocate and manipulate their own vfs structures using kmem_alloc(). The new interfaces are: vfs_t *vfs_alloc(int kmflag) Allocates a new vfs structure and associated vfs_impl_t. Also provides basic initialization. The caller supplies kmflag as one of the kmem_alloc(9F) flags (e.g, KM_SLEEP, KM_NOSLEEP). void vfs_free(vfs_t *vfsp) Tears down the vfs structure and deallocates associated memory. Under normal circumstances, this will not be called directly but as a result of a VFS_RELE(). The existing vfs_init() routine will remain to initialize the operations vector and the data pointer. ACL ON CREATE The CIFS server requires the ability to atomically create files and directories with an ACL (Access Control List). This is to prevent someone accessing that file or directory before the ACL can be added. The obvious solution is to add a new parameter, a pointer to a vsecattr_t structure, to the the fop_* routines that create those objects. The VFS Registration system (described above) will allow file systems to register the "ACL on create" feature using: VFSFT_ACLONCREATE. Potential users of this feature will call the following (with 'vfsp' representing the pointer to the vfs structure for this mounted file system): vfs_has_feature(vfsp, VFSFT_ACLONCREATE) A non-zero return indicates that the caller can pass an ACL to either VOP_CREATE/fop_create or VOP_MKDIR/fop_mkdir and have the ACL set atomically. The proposed interfaces changes are as follows: int fop_create( vnode_t *dvp, char *name, vattr_t *vap, vcexcl_t excl, int mode, vnode_t **vpp, cred_t *cr, int flag, caller_context_t *ctp, /* See PSARC/2007/218 */ vsecattr_t *vsecp) /* ACL to be atomically set */ int fop_mkdir( vnode_t *dvp, char *dirname, vattr_t *vap, vnode_t **vpp, cred_t *cr, caller_context_t *ctp, /* See PSARC/2007/218 */ vsecattr_t *vsecp) /* ACL to be atomically set */ The following applies to both fop_create() and fop_mkdir(): If vsecp is non-NULL, then fop_mkdir/fop_create will each check to see if the mounted file system supports the ACL-on-Create feature using: vfs_has_feature(dvp->v_vfsp, VFSFT_ACLONCREATE) If vsecp is non-NULL and the file system supports ACL-on-Create, then an ACL represented by vsecp will be created for that object by the file system. If vsecp is non-NULL and the file system does *not* support ACL-on-Create, then the EINVAL will be returned from the fop layer. CONSUMER AND FILE SYSTEM SUPPORT: Initially, the only consumer of the ACL-on-Create feature will be the CIFS server. No other consumers (including user-level interfaces) have been planned or funded. The only file system scheduled to support ACL-on-Create is ZFS. ZFS will be modified to set an ACL on the object when the ZFS implementations of VOP_CREATE() and VOP_MKDIR() are called. Calls to vfs_has_feature(vfsp, VFSFT_ACLONCREATE) using a vfs that hasn't registered this feature will return zero. Callers should then pass NULL for vsecp to VOP_CREATE()/VOP_MKDIR(). FUTURE CONCERNS w.r.t VFS FEATURES The project team was advised to discuss some of the issues surrounding the evolution and use of the VFS Feature Registration system: Particularly around name space management and policy for adding new features. Ultimately, these issues need to be discussed in an opensolaris community dedicated to file system framework issues. There is a proposal in the opensolaris governing board to reorganize (among other things) the file system area. The project team will work with the governing board to determine the appropriate forum to discuss general file system issues such as VFS Registration. In the meantime, we ask that the ARC work with project teams to ensure the names used for proposed features are reasonable. This project team will be monitoring both the opensolaris and PSARC aliases for related projects. Until an opensolaris community is up and running, project teams and PSARC are welcome to forward feature-related questions to fs-framework@sun.com. EXPORTED INTERFACES: |Proposed |Specified | |Stability |in what | Interface Name |Classification |Document? | Comments =============================================================================== vfs_feature_t |Consolidation |This | VFS vfs_set_feature() |Private |Document | Feature Registration vfs_has_feature() | | | Interfaces | | | VFSFT_ACLONCREATE | | | VFS Feature #define | | | vfs_alloc()/vfs_free() | | | VFS memory mgmt I/F | | | vfs_femhead | | | Member of vfs_t. | | | Changed back from | | | vi_femhead (member | | | of vfs_impl_t) | | | ------------------------+---------------+---------------+---------------------- vi_featureset[] |Project |This | New member of |Private |Document | vfs_impl_t | | | ------------------------+---------------+---------------+---------------------- |Contracted | | VOP_CREATE, fop_create, |Consolidation |This | Add new parameter: VOP_MKDIR, fop_mkdir, |Private |Document | vsecattr_t *vsecp | | | ------------------------+---------------+---------------+---------------------- RELATED CONTRACTS PSARC 2001/599 (FS related interfaces for SAM-QFS) PSARC 2004/177 (FS related interfaces for Sun Cluster) From sommerfeld@sun.com Tue Apr 24 10:57:01 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3OHv1Vn010896 for ; Tue, 24 Apr 2007 10:57:01 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3OHuBWT021340; Tue, 24 Apr 2007 10:56:11 -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 <0JH000A03KHND700@brm-avmta-1.central.sun.com>; Tue, 24 Apr 2007 11:56:11 -0600 (MDT) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JH000MY2KHMJC60@brm-avmta-1.central.sun.com>; Tue, 24 Apr 2007 11:56:10 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3OHu7UV004852; Tue, 24 Apr 2007 13:56:07 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3OHu7Vq007656; Tue, 24 Apr 2007 13:56:07 -0400 (EDT) Date: Tue, 24 Apr 2007 13:56:06 -0400 From: Bill Sommerfeld Subject: Re: 2007/227 VFS Feature Registration and ACL on Create In-reply-to: <462E2156.5000606@sun.com> To: Calum Mackay Cc: psarc-ext@sun.com, Rich Brown Message-id: <1177437366.7085.11.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <462E2156.5000606@sun.com> Status: RO Content-Length: 798 On Tue, 2007-04-24 at 16:25 +0100, Calum Mackay wrote: > Initially, the only consumer of the ACL-on-Create feature will be the > CIFS server. No other consumers (including user-level interfaces) > have been planned or funded. The lack of a syscall/user-level interface to this bothers me, from a couple standpoints: 0) continues our tradition of acls as second-class citizens. 1) no way to unit-test the feature short of writing custom kernel code or firing up a CIFS server. 2) no easy way for user-space consumers to start using it. > The only file system scheduled to support ACL-on-Create is ZFS. ZFS > will be modified to set an ACL on the object when the ZFS > implementations of VOP_CREATE() and VOP_MKDIR() are called. by contrast, this is fine.. - Bill From Nicolas.Williams@sun.com Tue Apr 24 12:08:04 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3OJ83kg015357 for ; Tue, 24 Apr 2007 12:08:04 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3OJ6uQe029407; Tue, 24 Apr 2007 20:07:11 +0100 (BST) 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 <0JH000101NRXPL00@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Apr 2007 12:07:09 -0700 (PDT) Received: from binky.central.sun.com ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JH000FD0NRXUJF0@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Apr 2007 12:07:09 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3OJ66OR018126; Tue, 24 Apr 2007 14:06:06 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3OJ667g018125; Tue, 24 Apr 2007 14:06:06 -0500 (CDT) Date: Tue, 24 Apr 2007 14:06:06 -0500 From: Nicolas Williams Subject: Re: 2007/227 VFS Feature Registration and ACL on Create In-reply-to: <1177437366.7085.11.camel@thunk> To: Bill Sommerfeld Cc: Calum Mackay , psarc-ext@sun.com, Rich Brown Message-id: <20070424190605.GH17711@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <462E2156.5000606@sun.com> <1177437366.7085.11.camel@thunk> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 526 On Tue, Apr 24, 2007 at 01:56:06PM -0400, Bill Sommerfeld wrote: > On Tue, 2007-04-24 at 16:25 +0100, Calum Mackay wrote: > > Initially, the only consumer of the ACL-on-Create feature will be the > > CIFS server. No other consumers (including user-level interfaces) > > have been planned or funded. > > The lack of a syscall/user-level interface to this bothers me, from a > couple standpoints: Also, NFSv4 too has a ACL on create feature. It'd be nice to see support for it using this new VFS feature. Nico -- From Rich.Brown@sun.com Tue Apr 24 13:32:18 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3OKWHx2019719 for ; Tue, 24 Apr 2007 13:32:17 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3OKVJDB024274; Tue, 24 Apr 2007 21:31:26 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JH00020DROBLY00@brm-avmta-1.central.sun.com>; Tue, 24 Apr 2007 14:31:23 -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 <0JH00025UROBC100@brm-avmta-1.central.sun.com>; Tue, 24 Apr 2007 14:31:23 -0600 (MDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3OKVM0D019575; Tue, 24 Apr 2007 20:31:22 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JH000C01RJFVL00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM); Tue, 24 Apr 2007 14:31:22 -0600 (MDT) Received: from [129.147.9.49] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JH0005N3RO81EJ4@mail-amer.sun.com>; Tue, 24 Apr 2007 14:31:22 -0600 (MDT) Date: Tue, 24 Apr 2007 15:31:20 -0500 From: Rich Brown Subject: Re: 2007/227 VFS Feature Registration and ACL on Create In-reply-to: <1177437366.7085.11.camel@thunk> Sender: Rich.Brown@sun.com To: Bill Sommerfeld Cc: Calum Mackay , psarc-ext@sun.com Message-id: <462E6918.3090901@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <462E2156.5000606@sun.com> <1177437366.7085.11.camel@thunk> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 1222 Bill Sommerfeld wrote: > On Tue, 2007-04-24 at 16:25 +0100, Calum Mackay wrote: > >> Initially, the only consumer of the ACL-on-Create feature will be the >> CIFS server. No other consumers (including user-level interfaces)wekk >> have been planned or funded. > > The lack of a syscall/user-level interface to this bothers me, from a > couple standpoints: > 0) continues our tradition of acls as second-class citizens. I think the situation is getting better given that ZFS has ACLs on all files, but that's just my perception. > 1) no way to unit-test the feature short of writing custom kernel code > or firing up a CIFS server. Yes, the developer testing has been done using custom code. The CIFS test team will be doing end-to-end testing since they are currently the only consumer. If/when NFS starts using this interface, there will be test coverage there also. > 2) no easy way for user-space consumers to start using it. True. Of course, there are existing interfaces to set and retrieve ACLs but there isn't a way in user-space to set these atomically. FWIW, I've shopped this around as a good project for an intern but haven't gotten any bites from any managers, so far. Rich From Rich.Brown@sun.com Tue Apr 24 13:37:18 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3OKbHHb019862 for ; Tue, 24 Apr 2007 13:37:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3OKaNML025525; Tue, 24 Apr 2007 21:36:27 +0100 (BST) 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 <0JH00050HRWQJZ00@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Apr 2007 13:36:26 -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 <0JH0003XYRWP1E20@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Apr 2007 13:36:25 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3OKaP33012289; Tue, 24 Apr 2007 20:36:25 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JH000M01RPWJ900@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM); Tue, 24 Apr 2007 14:36:25 -0600 (MDT) Received: from [129.147.9.49] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JH0003XMRWALQE8@mail-amer.sun.com>; Tue, 24 Apr 2007 14:36:14 -0600 (MDT) Date: Tue, 24 Apr 2007 15:36:10 -0500 From: Rich Brown Subject: Re: 2007/227 VFS Feature Registration and ACL on Create In-reply-to: <462E6918.3090901@Sun.COM> Sender: Rich.Brown@sun.com To: Bill Sommerfeld Cc: Calum Mackay , psarc-ext@sun.com Message-id: <462E6A3A.8080306@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <462E2156.5000606@sun.com> <1177437366.7085.11.camel@thunk> <462E6918.3090901@Sun.COM> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 1387 BTW, I'll submit an RFE for this so that it's in the queue. Rich Rich Brown wrote: > Bill Sommerfeld wrote: > > On Tue, 2007-04-24 at 16:25 +0100, Calum Mackay wrote: > > > >> Initially, the only consumer of the ACL-on-Create feature will be > the > >> CIFS server. No other consumers (including user-level > interfaces)wekk > >> have been planned or funded. > > > > The lack of a syscall/user-level interface to this bothers me, from a > > couple standpoints: > > 0) continues our tradition of acls as second-class citizens. > > I think the situation is getting better given that ZFS has ACLs on all > files, > but that's just my perception. > > > 1) no way to unit-test the feature short of writing custom kernel code > > or firing up a CIFS server. > > Yes, the developer testing has been done using custom code. > > The CIFS test team will be doing end-to-end testing since they are > currently > the only consumer. If/when NFS starts using this interface, there will be > test coverage there also. > > > 2) no easy way for user-space consumers to start using it. > > True. Of course, there are existing interfaces to set and retrieve ACLs > but there isn't a way in user-space to set these atomically. > > FWIW, I've shopped this around as a good project for an intern but haven't > gotten any bites from any managers, so far. > > Rich From Rich.Brown@sun.com Tue Apr 24 13:39:07 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3OKd6b3020030 for ; Tue, 24 Apr 2007 13:39:07 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l3OKc8Gq020242 for <@newsunmail1brm.central.sun.com:psarc-ext@sun.com>; Wed, 25 Apr 2007 04:38:15 +0800 (SGT) 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 <0JH000307RZQ9M00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Apr 2007 14:38:14 -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 <0JH0002LIRZPC900@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Apr 2007 14:38:13 -0600 (MDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3OKcDKD008466 for ; Tue, 24 Apr 2007 20:38:13 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JH000M01RPWJ900@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Apr 2007 14:38:13 -0600 (MDT) Received: from [129.147.9.49] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JH000JC5RZL3YL4@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Apr 2007 14:38:12 -0600 (MDT) Date: Tue, 24 Apr 2007 15:38:09 -0500 From: Rich Brown Subject: Re: 2007/227 VFS Feature Registration and ACL on Create In-reply-to: <20070424190605.GH17711@Sun.COM> Sender: Rich.Brown@sun.com To: Nicolas Williams Cc: Calum Mackay , psarc-ext@sun.com Message-id: <462E6AB1.2090006@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <462E2156.5000606@sun.com> <1177437366.7085.11.camel@thunk> <20070424190605.GH17711@Sun.COM> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 596 Nicolas Williams wrote: > On Tue, Apr 24, 2007 at 01:56:06PM -0400, Bill Sommerfeld wrote: >> On Tue, 2007-04-24 at 16:25 +0100, Calum Mackay wrote: >>> Initially, the only consumer of the ACL-on-Create feature will be the >>> CIFS server. No other consumers (including user-level interfaces) >>> have been planned or funded. >> The lack of a syscall/user-level interface to this bothers me, from a >> couple standpoints: > > Also, NFSv4 too has a ACL on create feature. It'd be nice to see > support for it using this new VFS feature. > > Nico Agreed. I'll submit an RFE. Rich From sommerfeld@sun.com Tue Apr 24 13:44:20 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3OKiJ7U020312 for ; Tue, 24 Apr 2007 13:44:19 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3OKhRj9027562; Tue, 24 Apr 2007 21:43:28 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JH000005S8F2300@nwk-avmta-1.sfbay.Sun.COM>; Tue, 24 Apr 2007 13:43:27 -0700 (PDT) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JH000A3VS8BJIC0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 24 Apr 2007 13:43:23 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3OKhLfX003810; Tue, 24 Apr 2007 16:43:21 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3OKhLQT001385; Tue, 24 Apr 2007 16:43:21 -0400 (EDT) Date: Tue, 24 Apr 2007 16:43:20 -0400 From: Bill Sommerfeld Subject: Re: 2007/227 VFS Feature Registration and ACL on Create In-reply-to: <20070424190605.GH17711@Sun.COM> To: Nicolas Williams Cc: Calum Mackay , psarc-ext@sun.com, Rich Brown Message-id: <1177447400.1083.24.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <462E2156.5000606@sun.com> <1177437366.7085.11.camel@thunk> <20070424190605.GH17711@Sun.COM> Status: RO Content-Length: 529 On Tue, 2007-04-24 at 14:06 -0500, Nicolas Williams wrote: > > The lack of a syscall/user-level interface to this bothers me, from a > > couple standpoints: > > Also, NFSv4 too has a ACL on create feature. It'd be nice to see > support for it using this new VFS feature. so we could have two immediate providers (NFSv4 client and ZFS) and two possible consumers (CIFS and NFSv4 server). I think the tricky part is getting the syscall function signature right; the rest should be relatively straightforward. - Bill From gww@eng.sun.com Tue Apr 24 15:57:24 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3OMvNEP025387 for ; Tue, 24 Apr 2007 15:57:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3OMuVRY004519 for <@newsunmail1brm.central.sun.com:psarc-ext@sun.com>; Tue, 24 Apr 2007 23:56:32 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JH000G01YE59600@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Apr 2007 16:56:29 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JH0002J5YE4CF70@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Apr 2007 16:56:29 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3OMuR0f017267; Tue, 24 Apr 2007 15:56:27 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l3OMvlbK009653; Tue, 24 Apr 2007 15:57:47 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l3OMvkt0009652; Tue, 24 Apr 2007 15:57:46 -0700 (PDT) Date: Tue, 24 Apr 2007 15:57:46 -0700 (PDT) From: Gary Winiger Subject: Re: 2007/227 VFS Feature Registration and ACL on Create To: Calum.Mackay@sun.com, psarc-ext@sun.com Cc: Rich.Brown@sun.com Message-id: <200704242257.l3OMvkt0009652@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 369 > 2) ACL-on-create - A change to the vnode operations responsible for > creation (VOP_CREATE() and VOP_MKDIR()) which will allow an ACL to > be set atomically at create time I presume this ACL/ACE will override any inherited ACL terms / ACEs Is that correct? How will it interact with the modes? Will an RFE for a userland call be created? Gary.. From Mark.Shellenbaum@sun.com Tue Apr 24 16:00:45 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3ON0jlt025735 for ; Tue, 24 Apr 2007 16:00:45 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3OMxs9w045285 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 24 Apr 2007 16:59:54 -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 <0JH000C0FYJSEQ00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Apr 2007 15:59:52 -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 <0JH0004IHYJSCH50@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Apr 2007 15:59:52 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3OMxqDY005775 for ; Tue, 24 Apr 2007 22:59:52 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JH000501YA2NF00@mail-amer.sun.com> (original mail from Mark.Shellenbaum@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Apr 2007 16:59:52 -0600 (MDT) Received: from [172.20.25.34] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JH0003VRYJSLTD8@mail-amer.sun.com>; Tue, 24 Apr 2007 16:59:52 -0600 (MDT) Date: Tue, 24 Apr 2007 16:59:52 -0600 From: Mark Shellenbaum Subject: Re: 2007/227 VFS Feature Registration and ACL on Create In-reply-to: <200704242257.l3OMvkt0009652@marduk.eng.sun.com> Sender: Mark.Shellenbaum@sun.com To: Gary Winiger Cc: Calum.Mackay@sun.com, psarc-ext@sun.com, Rich.Brown@sun.com Message-id: <462E8BE8.6040407@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704242257.l3OMvkt0009652@marduk.eng.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070212) Status: RO Content-Length: 602 Gary Winiger wrote: >> 2) ACL-on-create - A change to the vnode operations responsible for >> creation (VOP_CREATE() and VOP_MKDIR()) which will allow an ACL to >> be set atomically at create time > > I presume this ACL/ACE will override any inherited ACL terms / ACEs > Is that correct? How will it interact with the modes? > Yes, this will override any inheritance. It is the equivalent of setting an explicit ACL via acl(2). > Will an RFE for a userland call be created? > > Gary.. > 6549833 RFE: system call to create a file and set the ACL atomically Has been opened. From Spencer.Shepler@sun.com Tue Apr 24 16:21:41 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3ONLePn026286 for ; Tue, 24 Apr 2007 16:21:41 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3ONKiHM011503 for <@newsunmail1brm.central.sun.com:psarc-ext@sun.com>; Wed, 25 Apr 2007 00:20:49 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JH000I05ZINV200@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Apr 2007 17:20:47 -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 <0JH00027SZIMC980@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Apr 2007 17:20:46 -0600 (MDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3ONKkoe013011 for ; Tue, 24 Apr 2007 23:20:46 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JH000L01ZG5K600@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Apr 2007 17:20:46 -0600 (MDT) Received: from [129.153.128.161] (scaea-socks-2.sun.com [192.18.43.17]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JH000A3AZIL4F50@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Apr 2007 17:20:46 -0600 (MDT) Date: Tue, 24 Apr 2007 18:20:44 -0500 From: Spencer Shepler Subject: Re: 2007/227 VFS Feature Registration and ACL on Create In-reply-to: <462E2156.5000606@sun.com> Sender: Spencer.Shepler@sun.com To: Calum Mackay Cc: psarc-ext@sun.com, Rich Brown Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <462E2156.5000606@sun.com> Status: RO Content-Length: 1258 > > VFS FEATURES > > Several VFS Features will be defined for the initial implementation. > This fast-track includes the following feature needed to support the > optional ACL-on-create behavior (described below). > > /* File system supports setting an ACL on create atomically */ > #define VFSFT_ACLONCREATE 0x100000001 So this applies to exclusive and non-exclusive creates. As has been noted, NFSv4 provides for specification of file attributes on file system object creation. This includes all file system object types (e.g. files, directories) and the list of attributes that may be specified are any defined in the protocol and supported by the server. This email isn't to affirm that functionality but to point out a protocol flaw in NFSv4. The problem is with exclusive creates. That mechanism in the protocol does not allow for the specification of file attributes. While we have been discussing methods of overcoming this flaw in NFSv4.1, the solution will not be absolute. Given the discussion of providing a system call addition or modification to provide exposure to this functionality, I would suggest that some thought be given to allowing the NFSv4 client the ability to say "supported except for exclusive create". Spencer From Rich.Brown@sun.com Sat Apr 28 13:46:05 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3SKk4rU029817 for ; Sat, 28 Apr 2007 13:46:04 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3SKjC25010890 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Sat, 28 Apr 2007 13:45:12 -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 <0JH8004056ZCLV00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sat, 28 Apr 2007 13:45:12 -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 <0JH8003326ZCXZ20@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sat, 28 Apr 2007 13:45:12 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3SKjBvk021465 for ; Sat, 28 Apr 2007 20:45:11 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JH800M016S8VA00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sat, 28 Apr 2007 14:45:11 -0600 (MDT) Received: from [129.147.9.49] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JH800JS36Z5O8YE@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sat, 28 Apr 2007 14:45:11 -0600 (MDT) Date: Sat, 28 Apr 2007 15:45:05 -0500 From: Rich Brown Subject: Re: 2007/227 VFS Feature Registration and ACL on Create In-reply-to: <462E2156.5000606@sun.com> Sender: Rich.Brown@sun.com To: rlhamil@smart.net Cc: psarc-ext@sun.com Message-id: <4633B251.3010009@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <462E2156.5000606@sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 824 Richard L. Hamilton (rlhamil@smart.net) sent the following on the opensolaris-arc@opensolaris.org alias. Unfortunately, I'm not on that alias and didn't see this. Thanks to Calum for forwarding: And where a UFS default ACL would be applicable to a newly created object, surely that should also be applied atomically (unless UFS takes care of that itself somehow). Richard, I'm not sure if you're asking a question or looking for clarification. Perhaps this would help: UFS already has default ACLs that are inherited when a file is created. In order to have a default ACL the parent directory would have to have such an ACL created prior to a child being created. If there's a default ACL to be inherited, then that work is done during the ufs_create(). That has always been the case with UFS ACLs. Rich From Afshin.Ardakani@sun.com Sat Apr 28 15:02:41 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3SM2eKM004018 for ; Sat, 28 Apr 2007 15:02:41 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l3SM1f3B010330 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Sun, 29 Apr 2007 06:01:47 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JH800803AIYDE00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Sat, 28 Apr 2007 15:01:46 -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 <0JH80089FAIYA600@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Sat, 28 Apr 2007 15:01:46 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3SM1kRa009363 for ; Sat, 28 Apr 2007 22:01:46 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JH800601AIX5I00@mail-amer.sun.com> (original mail from Afshin.Ardakani@Sun.COM) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Sat, 28 Apr 2007 16:01:45 -0600 (MDT) Received: from [192.168.1.101] ([68.4.1.51]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JH80066BAIWR062@mail-amer.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Sat, 28 Apr 2007 16:01:44 -0600 (MDT) Date: Sat, 28 Apr 2007 15:01:23 -0700 From: Afshin Salek Subject: Re: 2007/227 VFS Feature Registration and ACL on Create In-reply-to: <4633B251.3010009@Sun.COM> Sender: Afshin.Ardakani@sun.com To: Rich Brown Cc: rlhamil@smart.net, psarc-ext@sun.com Message-id: <4633C433.6@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <462E2156.5000606@sun.com> <4633B251.3010009@Sun.COM> User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) Status: RO Content-Length: 1560 I think the point here is that now that an ACL can be specified upon creation, should UFS default ACL (or ZFS inheritable ACEs for that matter) be also applied to the new object or they should be ignored, since the creator already specified the desired ACL. And if it needs to be applied, then what Richard is saying is that it should happen atomically. I need to double check this but I think in Windows when a security descriptor is specified at creation time, ACL inheritance won't happen. I'll double check this and let you know. What I've already double checked is that if the file already exists the specified ACL in the create should be ignored. Afshin Rich Brown wrote: > Richard L. Hamilton (rlhamil@smart.net) sent the following on the > opensolaris-arc@opensolaris.org alias. Unfortunately, I'm not on that > alias and didn't see this. Thanks to Calum for forwarding: > > And where a UFS default ACL would be applicable to a newly created > object, surely that should > also be applied atomically (unless UFS takes care of that itself > somehow). > > > Richard, > > I'm not sure if you're asking a question or looking for clarification. > Perhaps this would help: > > UFS already has default ACLs that are inherited when a file is created. > In order to have a default ACL the parent directory would have to have > such > an ACL created prior to a child being created. If there's a default ACL > to be inherited, then that work is done during the ufs_create(). That > has always been the case with UFS ACLs. > > Rich > > From Rich.Brown@sun.com Tue May 1 06:57:47 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l41DvlHi002090 for ; Tue, 1 May 2007 06:57:47 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l41DupZR014276 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Tue, 1 May 2007 06:56:52 -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 <0JHD0050D82R7L00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 01 May 2007 06:56:51 -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 <0JHD00KU882RFTE0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 01 May 2007 06:56:51 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l41DupbJ016589 for ; Tue, 01 May 2007 13:56:51 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHD00M017MI1G00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 01 May 2007 07:56:51 -0600 (MDT) Received: from [129.147.9.49] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHD00A6S82POYE0@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 01 May 2007 07:56:50 -0600 (MDT) Date: Tue, 01 May 2007 08:56:48 -0500 From: Rich Brown Subject: Re: 2007/227 VFS Feature Registration and ACL on Create In-reply-to: <4633B251.3010009@Sun.COM> Sender: Rich.Brown@sun.com To: Rich Brown , psarc-ext@sun.com Message-id: <46374720.3000005@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <462E2156.5000606@sun.com> <4633B251.3010009@Sun.COM> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 672 I was looking through this case to make sure it had converged before the next PSARC meeting. The out come of the discussions resulted in the following RFEs being created. That additional work is not funded at this time. 6549833 RFE: system call to create a file and set the ACL atomically 6549936 RFE: Teach NFSv4 client and server how to create ACLs atomically when creating objects Also, the discussion touched on UFS ACLs. As stated in the case, ZFS is the only file system funded to support this feature. However, I've created an RFE requesting that UFS support this feature. 6552022 RFE: UFS support for ACL-on-CREATE (PSARC 2007/227) Thanks, Rich From Calum.Mackay@sun.com Wed May 2 10:13:26 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l42HDPo5021682 for ; Wed, 2 May 2007 10:13:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l42HCB63018571 for <@newsunmail1brm.central.sun.com:psarc-ext@sun.com>; Wed, 2 May 2007 18:12:28 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHF00903BSPKU00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 02 May 2007 11:12:25 -0600 (MDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHF00JQEBSNZ7A0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 02 May 2007 11:12:24 -0600 (MDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l42HCNZh021755 for ; Wed, 02 May 2007 17:12:23 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHF00I01BQZ5000@d1-emea-09.sun.com> (original mail from Calum.Mackay@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 02 May 2007 18:12:23 +0100 (BST) Received: from [192.168.254.1] ([62.24.230.83]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHF004MPBSL8740@d1-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 02 May 2007 18:12:22 +0100 (BST) Date: Wed, 02 May 2007 18:12:20 +0100 From: Calum Mackay Subject: Re: 2007/227 VFS Feature Registration and ACL on Create In-reply-to: <462E2156.5000606@sun.com> Sender: Calum.Mackay@sun.com To: Calum Mackay Cc: psarc-ext@sun.com, Rich Brown Message-id: <4638C674.1010701@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <462E2156.5000606@sun.com> User-Agent: Thunderbird 3.0a1 (X11/20070502) Status: RO Content-Length: 99 In response to requests for more time, I've extended the timer to next Weds, 9th May. cheers, c. From glenn.skinner@sun.com Wed May 2 15:06:53 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l42M6qVU010160 for ; Wed, 2 May 2007 15:06:53 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l42M5njC008595; Wed, 2 May 2007 23:05:55 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHF00F01PDTL900@brm-avmta-1.central.sun.com>; Wed, 02 May 2007 16:05:53 -0600 (MDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHF008UNPDS3R40@brm-avmta-1.central.sun.com>; Wed, 02 May 2007 16:05:53 -0600 (MDT) Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l42M5p49024387; Wed, 02 May 2007 15:05:51 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id l42M3OP6025818; Wed, 02 May 2007 15:03:24 -0700 (PDT) Date: Wed, 02 May 2007 15:03:24 -0700 (PDT) From: Glenn Skinner Subject: Re: 2007/227 VFS Feature Registration and ACL on Create To: psarc-ext@sun.com, Rich Brown Cc: Alan.M.Wright@sun.com, Timothy.Haley@sun.com, maybee@sac.sfbay.sun.com, Ienup.Sung@sun.com, cifs-vfs-team@sun.com Reply-to: Glenn Skinner Message-id: <200705022203.l42M3OP6025818@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: DHToEBWXUUmN2eesJETrCw== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2225 Bringing some discussion back out into the open that had crept off alias... In discussing 2007/244 [ZFS case-insensitive support], concern arose that the CIFS project wouldn't be able to work properly when faced with a file system that presented a particular combination of features (specifically, allowing both case insensitive name matching and mixed case sensitivity, but not supporting per-directory-entry flags). Since the CIFS server doesn't necessarily get to control how a file system that it's being asked to export (in NFS parlance) is mounted in its local file system name space, the server will have to devise some strategy for handling file systems that don't meet its requirements (such as refusing to export them). But this issue does raise the question of whether the feature registration facility has a design flaw. There are two problems. First, the path by which a mount option controlling a given feature ends up enabling or disabling the feature isn't specified. To be concrete, let's consider the specific feature included in this case. What does one utter on the mount command line to enable the acl-on-create feature? Is there (or should there be) a common syntactic form that mount options controlling file system features should follow? What's the machinery that turns this syntax into a call to vfs_set_feature()? Is there common support code that we should be providing for file system implementations (including their userland support utilities) to use? Given the possibility of configurability, the second problem arises. It's the issue of when and how incompatible feature combinations are detected and reported. The proposed design stores features in the mount's vfs structure, which implies that a mount must be largely completed before requested features are checked for compatibility. If they turn out to be incompatible, the mount has to be backed out, running the risk of an error occurring during the backout. If feature compatibility could be checked up front before any work that might have to be undone was accomplished, I'd be a lot happier about the design. So is there any possibility of revising the design to allow feature checking to be done up front? -- Glenn From Rich.Brown@sun.com Thu May 3 16:20:36 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l43NKadl006882 for ; Thu, 3 May 2007 16:20:36 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l43NJYVn020818; Thu, 3 May 2007 16:19:35 -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 <0JHH00I09NGN5P00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 03 May 2007 16:19:35 -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 <0JHH000O4NGJYDB0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 03 May 2007 16:19:31 -0700 (PDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l43NJVDq026850; Thu, 03 May 2007 23:19:31 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHH00E01MFDR700@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM); Thu, 03 May 2007 17:19:31 -0600 (MDT) Received: from [129.147.9.49] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHH000C4NGHDB92@mail-amer.sun.com>; Thu, 03 May 2007 17:19:31 -0600 (MDT) Date: Thu, 03 May 2007 18:19:29 -0500 From: Rich Brown Subject: Re: 2007/227 VFS Feature Registration and ACL on Create In-reply-to: <200705022203.l42M3OP6025818@ivrel.sfbay.sun.com> Sender: Rich.Brown@sun.com To: Glenn Skinner Cc: psarc-ext@sun.com, Alan.M.Wright@sun.com, Timothy.Haley@sun.com, maybee@sac.sfbay.sun.com, Ienup.Sung@sun.com, cifs-vfs-team@sun.com Message-id: <463A6E01.1020202@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705022203.l42M3OP6025818@ivrel.sfbay.sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 2613 Glenn Skinner wrote: ... > > > > There are two problems. > > > > First, the path by which a mount option controlling a given feature > > ends up enabling or disabling the feature isn't specified. To be > > concrete, let's consider the specific feature included in this case. > > What does one utter on the mount command line to enable the > > acl-on-create feature? There is no mount option for ACL-on-create. Either the file system supports it (e.g., ZFS) via its (file system specific) xxx_create() and xxx_mkdir() vnode operations or it doesn't. If it does, it registers the feature (VFSFT_ACLONCREATE). > Is there (or should there be) a common > > syntactic form that mount options controlling file system features > > should follow? What's the machinery that turns this syntax into a call > > to vfs_set_feature()? Is there common support code that we should be > > providing for file system implementations (including their userland > > support utilities) to use? A project team may propose a new behavior that includes both a mount option and a new, registerable "vfs feature". The enablement of that behavior would happen in the file system's mount operation (called via VFS_MOUNT()). If the behavior is enabled, the file system calls vfs_set_feature(). I don't think it needs to be any more complicated than that. > > Given the possibility of configurability, the second problem arises. > > It's the issue of when and how incompatible feature combinations are > > detected and reported. The proposed design stores features in the > > mount's vfs structure, which implies that a mount must be largely > > completed before requested features are checked for compatibility. If > > they turn out to be incompatible, the mount has to be backed out, > > running the risk of an error occurring during the backout. If feature > > compatibility could be checked up front before any work that might have > > to be undone was accomplished, I'd be a lot happier about the design. > > So is there any possibility of revising the design to allow feature > > checking to be done up front? > > I'm not quite sure what you're asking for. Are you suggesting that the VFS Feature Registration facility make decisions on which features are and are not compatible? If so, then I strongly disagree. It is not the responsibility of the VFS layer to presume what mix of features consumers should be able to handle. A file system presents a set of features for consumers to use. A consumer chooses whether or not it can handle that set. Rich From glenn.skinner@sun.com Fri May 4 13:25:29 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44KPSXV016838 for ; Fri, 4 May 2007 13:25:28 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l44KOUDA002368; Fri, 4 May 2007 14:24:30 -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 <0JHJ00K01A0U2P00@brm-avmta-1.central.sun.com>; Fri, 04 May 2007 14:24:30 -0600 (MDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHJ00BGKA0TSX50@brm-avmta-1.central.sun.com>; Fri, 04 May 2007 14:24:30 -0600 (MDT) Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l44KOSHM015972; Fri, 04 May 2007 13:24:28 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id l44KM08f017991; Fri, 04 May 2007 13:22:00 -0700 (PDT) Date: Fri, 04 May 2007 13:22:00 -0700 (PDT) From: Glenn Skinner Subject: Re: 2007/227 VFS Feature Registration and ACL on Create To: Rich.Brown@sun.com Cc: PSARC-EXT@sun.com, Alan.M.Wright@sun.com, Timothy.Haley@sun.com, maybee@sac.sfbay.sun.com, Ienup.Sung@sun.com, cifs-vfs-team@sun.com Reply-to: Glenn Skinner Message-id: <200705042022.l44KM08f017991@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: Gy5MfPjONu5MLue5pX5jvA== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2311 Date: Thu, 03 May 2007 18:19:29 -0500 From: Rich Brown Subject: Re: 2007/227 VFS Feature Registration and ACL on Create Glenn Skinner wrote: ... > > Given the possibility of configurability, the second problem > > arises. It's the issue of when and how incompatible feature > > combinations are detected and reported. The proposed design > > stores features in the mount's vfs structure, which implies > > that a mount must be largely completed before requested > > features are checked for compatibility. If they turn out to > > be incompatible, the mount has to be backed out, running the > > risk of an error occurring during the backout. If feature > > compatibility could be checked up front before any work that > > might have to be undone was accomplished, I'd be a lot happier > > about the design. So is there any possibility of revising the > > design to allow feature checking to be done up front? I'm not quite sure what you're asking for. Are you suggesting that the VFS Feature Registration facility make decisions on which features are and are not compatible? If so, then I strongly disagree. It is not the responsibility of the VFS layer to presume what mix of features consumers should be able to handle. That's not what I'm suggesting. I'm worried about the possibility of features that have dependency relationships among them, e.g., enabling feature A precludes enabling feature B. One could argue that features shouldn't be designed that way, and that might turn out to be a sufficiently practical answer. But before we cast this design in concrete I want to make sure we've done due diligence in exploring the design space. Now, it's certainly true that the VFS layer shouldn't be responsible for understanding and enforcing the detailed semantics of various file system-specific features; that's obviously the responsibility of the file systems that provide them. But if we have a design that forces substantial up front work to occur before a file system gets a chance to check its options (and then set its features based on them), an alternative design that allows the file system to do its checking beforehand would be superior. -- Glenn From Calum.Mackay@sun.com Fri May 4 15:56:05 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44Mu57j022395 for ; Fri, 4 May 2007 15:56:05 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l44Mt2bf034384; Fri, 4 May 2007 16:55:06 -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 <0JHJ00C17GZTAY00@brm-avmta-1.central.sun.com>; Fri, 04 May 2007 16:55:05 -0600 (MDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHJ00BCOGZRP700@brm-avmta-1.central.sun.com>; Fri, 04 May 2007 16:55:04 -0600 (MDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l44Mt3wA019654; Fri, 04 May 2007 22:55:03 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHJ00101GWKA100@d1-emea-09.sun.com> (original mail from Calum.Mackay@Sun.COM); Fri, 04 May 2007 23:55:03 +0100 (BST) Received: from [192.168.254.1] ([62.24.230.83]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHJ007O7GZPP69A@d1-emea-09.sun.com>; Fri, 04 May 2007 23:55:02 +0100 (BST) Date: Fri, 04 May 2007 23:55:01 +0100 From: Calum Mackay Subject: Re: 2007/227 VFS Feature Registration and ACL on Create In-reply-to: <200705042022.l44KM08f017991@ivrel.sfbay.sun.com> Sender: Calum.Mackay@sun.com To: Glenn Skinner Cc: Rich.Brown@sun.com, maybee@sac.sfbay.sun.com, Ienup.Sung@sun.com, PSARC-EXT@sun.com, Alan.M.Wright@sun.com, Timothy.Haley@sun.com, cifs-vfs-team@sun.com Message-id: <463BB9C5.2000502@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705042022.l44KM08f017991@ivrel.sfbay.sun.com> User-Agent: Thunderbird 3.0a1 (X11/20070504) Status: RO Content-Length: 4094 hi Glenn, > I'm not quite sure what you're asking for. Are you suggesting that > the VFS Feature Registration facility make decisions on which > features are and are not compatible? > > If so, then I strongly disagree. It is not the responsibility of > the VFS layer to presume what mix of features consumers should be > able to handle. > > That's not what I'm suggesting. I'm worried about the possibility of > features that have dependency relationships among them, e.g., enabling > feature A precludes enabling feature B. You're referring here to features *within* one particular filesystem? That would seem to be just broken design on the part of that filesystem, as you suggest. e.g. a filesystem might claim to support neither case-sensitive nor case-insensitive behaviour. That's probably broken. But should the VFS layer detect and refuse this? I don't believe so. If the consumer finds it unpalatable - as is likely - the consumer should refuse to play. > Now, it's certainly true that the VFS layer shouldn't be responsible > for understanding and enforcing the detailed semantics of various file > system-specific features; that's obviously the responsibility of the > file systems that provide them. But if we have a design that forces > substantial up front work to occur before a file system gets a chance > to check its options (and then set its features based on them), an > alternative design that allows the file system to do its checking > beforehand would be superior. I'm not sure I understand where the problem is. At mount-time, the filesystem (i.e. the feature provider) checks its mount options, work out what features that maps into, and then sets its features accordingly, registering them with the VFS. But there is no failure mode here: the feature registration succeeds, and the mount succeeds. There is no reason why it would fail, nor is there any real incompatibility (yet). Subsequently, a feature consumer comes along, which wants to work with this feature-providing filesystem. The consumer knows what sets of features it requires, and it queries for these from the VFS using the proposed interface. If the consumer then discovers - as a result of its query - that the providing-filesystem in question does not support the features the consumer requires, or supports features that the *consumer* considers incompatible with its (the consumer's) own operation, then the consumer decides not to work with that providing-filesystem. But the filesystem remains mounted, of course: there may be other consumers that are not so picky. To use your earlier example: consider a filesystem that provides both case insensitive name matching and mixed case sensitivity, but not supporting per-directory-entry flags). At mount-time, this filesystem registers this combination of features. The mount succeeds. Subsequently, CIFS comes along and wishes to export the contents of this providing-filesystem. Note that CIFS is a feature-consumer, not a providing-filesystem. CIFS queries the features supported by this filesystem, and notices that it (CIFS) cannot work properly with this combination of features. CIFS then refuses to export this filesystem's contents. But another consumer - not CIFS - may not find this particular combination of features so abhorrent, and may choose to proceed to work with this filesystem. Of course, if a filesystem were to provide a set of features, in such a combination that no consumer would ever want to use it, then that would be silly. But that would be either a filesystem design flaw, or a documentation/administration issue. Another way to put it might be that beauty is in the eye of the beholder: "compatibility" is really subjective from the perspective of the consumer. There's no reason for the providing-filesystem to fail to mount just because one consumer might not like its wares. There may be other less picky consumers along in a minute. Forgive me if the above is all obvious to you, and I've entirely missed the point? :( cheers, c. From Rich.Brown@sun.com Tue May 8 00:46:59 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l487kwAh023371 for ; Tue, 8 May 2007 00:46:58 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l487jQr5005414; Tue, 8 May 2007 08:45:54 +0100 (BST) 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 <0JHP00709PKGBP00@nwk-avmta-2.sfbay.sun.com>; Tue, 08 May 2007 00:45:52 -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 <0JHP00HDPPKF4E80@nwk-avmta-2.sfbay.sun.com>; Tue, 08 May 2007 00:45:51 -0700 (PDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l487jp93005636; Tue, 08 May 2007 07:45:51 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHP00201P2BRS00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM); Tue, 08 May 2007 01:45:51 -0600 (MDT) Received: from [10.1.98.220] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHP00L3XPKDJEO2@mail-amer.sun.com>; Tue, 08 May 2007 01:45:51 -0600 (MDT) Date: Tue, 08 May 2007 02:45:49 -0500 From: Rich Brown Subject: Re: 2007/227 VFS Feature Registration and ACL on Create In-reply-to: <200705042022.l44KM08f017991@ivrel.sfbay.sun.com> Sender: Rich.Brown@sun.com To: Glenn Skinner Cc: psarc-ext@sun.com, Alan.M.Wright@sun.com, Timothy.Haley@sun.com, maybee@sac.sfbay.sun.com, Ienup.Sung@sun.com, cifs-vfs-team@sun.com Message-id: <46402AAD.2010704@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705042022.l44KM08f017991@ivrel.sfbay.sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 3049 Glenn Skinner wrote: > Date: Thu, 03 May 2007 18:19:29 -0500 > From: Rich Brown > Subject: Re: 2007/227 VFS Feature Registration and ACL on Create > > Glenn Skinner wrote: > ... > > > > Given the possibility of configurability, the second problem > > > arises. It's the issue of when and how incompatible feature > > > combinations are detected and reported. The proposed design > > > stores features in the mount's vfs structure, which implies > > > that a mount must be largely completed before requested > > > features are checked for compatibility. If they turn out to > > > be incompatible, the mount has to be backed out, running the > > > risk of an error occurring during the backout. If feature > > > compatibility could be checked up front before any work that > > > might have to be undone was accomplished, I'd be a lot happier > > > about the design. So is there any possibility of revising the > > > design to allow feature checking to be done up front? > > I'm not quite sure what you're asking for. Are you suggesting that > the VFS Feature Registration facility make decisions on which > features are and are not compatible? > > If so, then I strongly disagree. It is not the responsibility of > the VFS layer to presume what mix of features consumers should be > able to handle. > > That's not what I'm suggesting. I'm worried about the possibility of > features that have dependency relationships among them, e.g., enabling > feature A precludes enabling feature B. > > One could argue that features shouldn't be designed that way, and that > might turn out to be a sufficiently practical answer. But before we > cast this design in concrete I want to make sure we've done due > diligence in exploring the design space. > > Now, it's certainly true that the VFS layer shouldn't be responsible > for understanding and enforcing the detailed semantics of various file > system-specific features; that's obviously the responsibility of the > file systems that provide them. But if we have a design that forces > substantial up front work to occur before a file system gets a chance > to check its options (and then set its features based on them), an > alternative design that allows the file system to do its checking > beforehand would be superior. > > -- Glenn > Calum's description (see previous e-mail) is consistent with the team's view. With regard to your point about exploring the design space: We've discussed various possibilities and believe that the FS-specific mount routine is the appropriate place to do feature checking. This is the point at which all of the information is available to properly assess the feature set and determine if there are any inconsistencies or conflicts which would cause the mount to fail. As Calum points out, it's up to consumers to determine whether or not they can live with the set of features offered by a mounted file system. Rich From Calum.Mackay@sun.com Thu May 10 06:53:21 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4ADrK38006954 for ; Thu, 10 May 2007 06:53:20 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l4ADqF0B011680 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 10 May 2007 07:52:16 -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 <0JHT00807VV3WP00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 10 May 2007 06:52:15 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHT005QQVV1AF20@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 10 May 2007 06:52:14 -0700 (PDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4ADqDhG013150 for ; Thu, 10 May 2007 13:52:13 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHT00I01VCNSI00@d1-emea-09.sun.com> (original mail from Calum.Mackay@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 10 May 2007 14:52:13 +0100 (BST) Received: from [192.168.254.1] ([62.24.230.83]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHT005WQVU0WQM0@d1-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 10 May 2007 14:51:37 +0100 (BST) Date: Thu, 10 May 2007 14:51:35 +0100 From: Calum Mackay Subject: Re: 2007/227 VFS Feature Registration and ACL on Create In-reply-to: <462E2156.5000606@sun.com> Sender: Calum.Mackay@sun.com To: Calum Mackay Cc: psarc-ext@sun.com, Rich Brown Message-id: <46432367.7010606@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <462E2156.5000606@sun.com> User-Agent: Thunderbird 3.0a1 (X11/20070504) Status: RO Content-Length: 106 This fast-track was approved during yesterday's PSARC meeting, as originally specified. cheers, calum.