From Fri Jun 12 14:07:46 2009 Date: Fri, 12 Jun 2009 14:07:46 -0700 (PDT) From: Postmaster Subject: Message from mail server Content-Length: 94 Mime-Version: 1.0 Status: RO X-IMAP: 1244840866 15 Delete. This is a system message. --END+PSEUDO-- From sacadmin Wed Aug 8 14:31:09 2007 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l78LV98F028657; Wed, 8 Aug 2007 14:31:09 -0700 (PDT) Received: (from calum@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l78LV9YG028653; Wed, 8 Aug 2007 14:31:09 -0700 (PDT) Date: Wed, 8 Aug 2007 14:31:09 -0700 (PDT) From: Calum Mackay Message-Id: <200708082131.l78LV9YG028653@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: Vnode Specific Data [PSARC/2007/456 FastTrack timeout 08/15/2007] Content-Length: 554 Status: RO X-Status: $$$$ X-UID: 0000000001 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Vnode Specific Data 1.2. Name of Document Author/Supplier: Author: James Wahlig 1.3 Date of This Document: 08 August, 2007 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Calum.Mackay@sun.com Wed Aug 8 14:31:24 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 l78LVOQC028698 for ; Wed, 8 Aug 2007 14:31:24 -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 l78LT3ck018898 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 8 Aug 2007 14:29:04 -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 <0JMH00D0150GD700@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 08 Aug 2007 14:29:04 -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 <0JMH0055650FNZ90@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 08 Aug 2007 14:29:03 -0700 (PDT) Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l78LT2EA011279 for ; Wed, 08 Aug 2007 21:29:02 +0000 (GMT) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JMH00401509R100@d1-emea-10.sun.com> (original mail from Calum.Mackay@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 08 Aug 2007 22:29:02 +0100 (BST) Received: from [129.156.173.199] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMH006JF50ESL4L@d1-emea-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 08 Aug 2007 22:29:02 +0100 (BST) Date: Wed, 08 Aug 2007 22:29:02 +0100 From: Calum Mackay Subject: 2007/456 Vnode Specific Data Sender: Calum.Mackay@sun.com To: psarc-ext@sun.com, Jim Wahlig Message-id: <46BA359E.7090203@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 2.0.0.0 (X11/20070619) Content-Length: 3623 Status: RO X-Status: $$$$ X-UID: 0000000002 I'm sponsoring the following fast-track for Jim Wahlig. The case seeks Minor binding. I have set the timer to a week today, Weds 15th August. cheers, calum. Vnode Specific Data Problem Description Every time a project needs to keep some data in core that is associated with a file object, it has one of two choices. 1) create a database or hash table to store and lookup the data using the vnode as a key, or 2) add yet another field to the vnode data structure. Unfortunately, it seems like the vnode has become a dumping ground for all kinds of project specific data. Proposed Solution The solution is to provide a set of interfaces which will allow the caller to store and retrieve data on a per vnode basis. If this sounds familiar it is because the solution is just like Thread Specific Data. Only one new field is added to the vnode, void *v_vsd. The vsd structure looks like this: struct vsd_node { struct vsd_node *vs_next; /* vnodes with VSD */ struct vsd_node *vs_prev; /* vnodes with VSD */ uint_t vs_nkeys; /* entries in value array */ void **vs_value; /* array of value/key */ }; void vsd_create(uint_t *key, void (*destructor)(void *)) This function will create a key for all subsequent calls and stores the destructor function associated with the data to be stored. The destructor function is optional and can be NULL. int vsd_set(vnode_t *vp, uint_t key, void *value) This function will store the data on the specified vnode using the provided key. It will return EINVAL for a key == 0. void *vsd_get(vnode_t *vp, uint_tkey) This function will return the data on the specified vnode for the given key. void vsd_destroy(uint_t *key) This function will "destroy" a key. It will walk the list of vsd's and call the destructor function on the data for each vsd that has the given key. The value field is set to NULL as is the destructor for that key. The key is also set to zero. Used by unloadable modules. void vsd_free(vnode_t *vp) This function is called to free all VSD for the given vnode. The destructor functions are called for each VSD and then the vsd structure is freed and v_vsd in the vnode is set to NULL. This function is called from vn_recycle() and vn_free(). The first consumer of VSD will be the NFSv4 server. The server currently keeps a file state structure, one per vnode, in a database. We will use VSD to store the file structure with the vnode. These changes have been prototyped and tested. There are other fields in the vnode which could be converted to using VSD, but that is out of scope for this fast-track. However, future projects should use VSD instead of adding another field to the vnode, unless there is a strong justification otherwise. Exported Interfaces | | Interface Name | Classification | Comments ================================================================= | | vsd_create, | Consolidation | New interfaces for creating, vsd_destroy, | Private | destroying, vsd_get, | | getting a stored value from, vsd_set, | | setting a value into, vsd_free | | and freeing vnode specific data. From max@bruningsystems.com Wed Aug 8 15:19:34 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 l78MJXAK000456 for ; Wed, 8 Aug 2007 15:19:34 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l78MH8Iv010554; Thu, 9 Aug 2007 06:17:09 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JMH00I0N78I8000@nwk-avmta-1.sfbay.Sun.COM>; Wed, 08 Aug 2007 15:17:06 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMH00HZY78HW900@nwk-avmta-1.sfbay.Sun.COM>; Wed, 08 Aug 2007 15:17:05 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l78MCQ6r006052; Wed, 08 Aug 2007 22:17:05 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay41i.sun.com with ESMTP id BT-MMP-121195; Wed, 08 Aug 2007 22:17:04 +0000 (Z) Received: from relay43i.sun.com ([192.5.209.74] [192.5.209.74]) by mms48es.sun.com with ESMTP id BT-MMP-1560104; Wed, 08 Aug 2007 22:17:04 +0000 (Z) Received: from gator39.hostgator.com ([70.85.249.98] [70.85.249.98]) by relay4i.sun.com with ESMTP id BT-MMP-6045780; Wed, 08 Aug 2007 22:17:04 +0000 (Z) Received: from [62.181.52.43] (port=58434 helo=[192.168.1.10]) by gator39.hostgator.com with esmtpa (Exim 4.63) (envelope-from ) id 1IItpv-0007jq-PJ; Wed, 08 Aug 2007 17:17:04 -0500 Date: Thu, 09 Aug 2007 00:14:37 +0200 From: "max@bruningsystems.com" Subject: Re: 2007/456 Vnode Specific Data In-reply-to: <46BA359E.7090203@sun.com> To: Calum Mackay Cc: psarc-ext@Sun.COM, Jim Wahlig Message-id: <46BA404D.6090700@bruningsystems.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator39.hostgator.com X-AntiAbuse: Original Domain - sun.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - bruningsystems.com X-Source: X-Source-Args: X-Source-Dir: References: <46BA359E.7090203@sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061204) Content-Length: 4112 Status: RO X-Status: $$$$ X-UID: 0000000003 Hi Calum, Just curious. Why isn't this data being placed with the v_data field? I guess I don't know why there needs to be 2 pieces of data associated with a file object... thanks, max Calum Mackay wrote: > I'm sponsoring the following fast-track for Jim Wahlig. > > The case seeks Minor binding. I have set the timer to a week today, Weds > 15th August. > > cheers, > calum. > > > Vnode Specific Data > > Problem Description > > Every time a project needs to keep some data in core that is > associated > with a file object, it has one of two choices. 1) create a database > or hash table to store and lookup the data using the vnode as a > key, or > 2) add yet another field to the vnode data structure. Unfortunately, > it seems like the vnode has become a dumping ground for all kinds of > project specific data. > > Proposed Solution > > The solution is to provide a set of interfaces which will allow the > caller to store and retrieve data on a per vnode basis. If this > sounds > familiar it is because the solution is just like Thread Specific Data. > > Only one new field is added to the vnode, void *v_vsd. > The vsd structure looks like this: > struct vsd_node { > struct vsd_node *vs_next; /* vnodes with VSD */ > struct vsd_node *vs_prev; /* vnodes with VSD */ > uint_t vs_nkeys; /* entries in value array */ > void **vs_value; /* array of value/key */ > }; > > void vsd_create(uint_t *key, void (*destructor)(void *)) > This function will create a key for all subsequent calls and > stores the destructor function associated with the data to be > stored. > The destructor function is optional and can be NULL. > > int vsd_set(vnode_t *vp, uint_t key, void *value) > This function will store the data on the specified vnode using > the provided key. It will return EINVAL for a key == 0. > > void *vsd_get(vnode_t *vp, uint_tkey) > This function will return the data on the specified vnode for the > given key. > > void vsd_destroy(uint_t *key) > This function will "destroy" a key. It will walk the list of vsd's > and call the destructor function on the data for each vsd that has > the given key. The value field is set to NULL as is the > destructor for > that key. The key is also set to zero. Used by unloadable modules. > > void vsd_free(vnode_t *vp) > This function is called to free all VSD for the given vnode. The > destructor functions are called for each VSD and then the vsd > structure is freed and v_vsd in the vnode is set to NULL. This > function is called from vn_recycle() and vn_free(). > > The first consumer of VSD will be the NFSv4 server. The server > currently > keeps a file state structure, one per vnode, in a database. We will > use VSD to store the file structure with the vnode. These changes > have been prototyped and tested. > > There are other fields in the vnode which could be converted to using > VSD, but that is out of scope for this fast-track. However, future > projects should use VSD instead of adding another field to the vnode, > unless there is a strong justification otherwise. > > Exported Interfaces > > | | > Interface Name | Classification | Comments > ================================================================= > | | > vsd_create, | Consolidation | New interfaces for creating, > vsd_destroy, | Private | destroying, > vsd_get, | | getting a stored value from, > vsd_set, | | setting a value into, > vsd_free | | and freeing vnode specific data. > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > > From James.Wahlig@sun.com Wed Aug 8 15:34:38 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 l78MYbmg000779 for ; Wed, 8 Aug 2007 15:34:38 -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 l78MWEuv026820 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 8 Aug 2007 23:32:17 +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 <0JMH00A097XR6O00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Wed, 08 Aug 2007 15:32:15 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMH006247XR2GD0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Wed, 08 Aug 2007 15:32:15 -0700 (PDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l78MWFuI012521 for ; Wed, 08 Aug 2007 22:32:15 +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 <0JMH00A017CU0K00@mail-amer.sun.com> (original mail from James.Wahlig@Sun.COM) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 08 Aug 2007 16:32:15 -0600 (MDT) Received: from [129.153.131.87] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMH00E9T7XQLRM5@mail-amer.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 08 Aug 2007 16:32:15 -0600 (MDT) Date: Wed, 08 Aug 2007 17:32:14 -0500 From: james wahlig Subject: Re: 2007/456 Vnode Specific Data In-reply-to: <46BA404D.6090700@bruningsystems.com> Sender: James.Wahlig@sun.com To: "max@bruningsystems.com" Cc: Calum Mackay , psarc-ext@sun.com Reply-to: james.wahlig@central.sun.com Message-id: <46BA446E.5080301@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <46BA359E.7090203@sun.com> <46BA404D.6090700@bruningsystems.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20070109 Content-Length: 575 Status: RO X-Status: $$$$ X-UID: 0000000004 max@bruningsystems.com wrote: > Hi Calum, > Just curious. Why isn't this data being placed with the v_data > field? I guess I don't know > why there needs to be 2 pieces of data associated with a file object... > > thanks, > max The v_data fields is usually for the file system specific data (or node), like the inode in ufs and the rnode in nfs. VSD is more for project specific data. Generally, when a project wants to associate data with a vnode, it just adds another field to vnode. The vnode keeps growing (unnecessarily, IMO) and I'd like to stop that. Jim From Robert.Gittins@sun.com Thu Aug 9 07:50:47 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 l79Eolga018199 for ; Thu, 9 Aug 2007 07:50:47 -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 l79EmBi9024357 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 9 Aug 2007 15:48:25 +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 <0JMI00901H4MAY00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Aug 2007 08:48: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 <0JMI001UDH4MK260@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Aug 2007 08:48:22 -0600 (MDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l79EmMX5001579 for ; Thu, 09 Aug 2007 14:48: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 <0JMI00D01GWXYP00@mail-amer.sun.com> (original mail from Robert.Gittins@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Aug 2007 08:48:22 -0600 (MDT) Received: from Virtual-FC6.localdomain ([129.150.34.54]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMI00CRJH4JGUF9@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Aug 2007 08:48:21 -0600 (MDT) Date: Thu, 09 Aug 2007 08:48:15 -0600 From: Rob Gittins Subject: Re: 2007/456 Vnode Specific Data In-reply-to: <46BA359E.7090203@sun.com> Sender: Robert.Gittins@sun.com To: Calum Mackay Cc: PSARC-ext@sun.com, Jim Wahlig Reply-to: Robert.Gittins@sun.com Message-id: <46BB292F.7050503@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: <46BA359E.7090203@sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070326) Content-Length: 3999 Status: RO X-Status: $$$$ X-UID: 0000000005 Hi Jim, Would it be possible to extend vsd_create to take a key as well as create and return a key? This way a FS can have predefined key values for specific data elements. This might simplify the usage in some cases. Thanks, Rob Calum Mackay wrote: > I'm sponsoring the following fast-track for Jim Wahlig. > > The case seeks Minor binding. I have set the timer to a week today, > Weds 15th August. > > cheers, > calum. > > > Vnode Specific Data > > Problem Description > > Every time a project needs to keep some data in core that is > associated > with a file object, it has one of two choices. 1) create a database > or hash table to store and lookup the data using the vnode as a > key, or > 2) add yet another field to the vnode data structure. > Unfortunately, > it seems like the vnode has become a dumping ground for all kinds of > project specific data. > > Proposed Solution > > The solution is to provide a set of interfaces which will allow the > caller to store and retrieve data on a per vnode basis. If this > sounds > familiar it is because the solution is just like Thread Specific > Data. > > Only one new field is added to the vnode, void *v_vsd. > The vsd structure looks like this: > struct vsd_node { > struct vsd_node *vs_next; /* vnodes with VSD */ > struct vsd_node *vs_prev; /* vnodes with VSD */ > uint_t vs_nkeys; /* entries in value array */ > void **vs_value; /* array of value/key */ > }; > > void vsd_create(uint_t *key, void (*destructor)(void *)) > This function will create a key for all subsequent calls and > stores the destructor function associated with the data to be > stored. > The destructor function is optional and can be NULL. > > int vsd_set(vnode_t *vp, uint_t key, void *value) > This function will store the data on the specified vnode using > the provided key. It will return EINVAL for a key == 0. > > void *vsd_get(vnode_t *vp, uint_tkey) > This function will return the data on the specified vnode for the > given key. > > void vsd_destroy(uint_t *key) > This function will "destroy" a key. It will walk the list of > vsd's > and call the destructor function on the data for each vsd that has > the given key. The value field is set to NULL as is the > destructor for > that key. The key is also set to zero. Used by unloadable > modules. > > void vsd_free(vnode_t *vp) > This function is called to free all VSD for the given vnode. The > destructor functions are called for each VSD and then the vsd > structure is freed and v_vsd in the vnode is set to NULL. This > function is called from vn_recycle() and vn_free(). > > The first consumer of VSD will be the NFSv4 server. The server > currently > keeps a file state structure, one per vnode, in a database. We will > use VSD to store the file structure with the vnode. These changes > have been prototyped and tested. > > There are other fields in the vnode which could be converted to > using > VSD, but that is out of scope for this fast-track. However, future > projects should use VSD instead of adding another field to the > vnode, > unless there is a strong justification otherwise. > > Exported Interfaces > > | | > Interface Name | Classification | Comments > ================================================================= > | | > vsd_create, | Consolidation | New interfaces for creating, > vsd_destroy, | Private | destroying, > vsd_get, | | getting a stored value from, > vsd_set, | | setting a value into, > vsd_free | | and freeing vnode specific data. From sommerfeld@sun.com Thu Aug 9 08:43:46 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 l79FhjKX019622 for ; Thu, 9 Aug 2007 08:43:45 -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 l79FfH8Q024546; Thu, 9 Aug 2007 16:41:20 +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 <0JMI00C24JKT6300@brm-avmta-1.central.sun.com>; Thu, 09 Aug 2007 09:41:17 -0600 (MDT) Received: from localhost.east.sun.com ([129.148.19.3]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMI001O1JKRKF90@brm-avmta-1.central.sun.com>; Thu, 09 Aug 2007 09:41:16 -0600 (MDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l79Ff1BM004997; Thu, 09 Aug 2007 11:41:01 -0400 (EDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l79Ff0Dv004996; Thu, 09 Aug 2007 11:41:00 -0400 (EDT) Date: Thu, 09 Aug 2007 11:41:00 -0400 From: Bill Sommerfeld Subject: Re: 2007/456 Vnode Specific Data In-reply-to: <46BB292F.7050503@sun.com> To: Robert.Gittins@sun.com Cc: Calum Mackay , PSARC-ext@sun.com, Jim Wahlig Message-id: <1186674060.4971.2.camel@localhost> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46BA359E.7090203@sun.com> <46BB292F.7050503@sun.com> X-Authentication-warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Content-Length: 543 Status: RO X-Status: $$$$ X-UID: 0000000006 On Thu, 2007-08-09 at 08:48 -0600, Rob Gittins wrote: > Hi Jim, > > Would it be possible to extend vsd_create to take a key as well as > create and return a key? This way a FS can have predefined key values > for specific data elements. This might simplify the usage in some cases. as I understand it, this mechanism is intended to permit subsystems other than filesystems to tag vnodes with subsystem-specific data. if you were to do this, how would you preassign key values across all filesystems so they don't collide? - Bill From James.Wahlig@sun.com Thu Aug 9 08:50:47 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 l79Foleq019869 for ; Thu, 9 Aug 2007 08:50:47 -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 l79FmNCr027685 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 9 Aug 2007 16:48:25 +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 <0JMI00K01JWMQH00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Aug 2007 08:48:22 -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 <0JMI00FKSJWMQ250@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Aug 2007 08:48:22 -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 l79FmLCC007643 for ; Thu, 09 Aug 2007 15:48:21 +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 <0JMI00C01JOVGS00@mail-amer.sun.com> (original mail from James.Wahlig@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Aug 2007 09:48:21 -0600 (MDT) Received: from [129.153.131.87] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMI00FUXJWLVXJ4@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Aug 2007 09:48:21 -0600 (MDT) Date: Thu, 09 Aug 2007 10:48:21 -0500 From: james wahlig Subject: Re: 2007/456 Vnode Specific Data In-reply-to: <46BB292F.7050503@sun.com> Sender: James.Wahlig@sun.com To: Robert.Gittins@sun.com Cc: Calum Mackay , PSARC-ext@sun.com Reply-to: james.wahlig@central.sun.com Message-id: <46BB3745.9010204@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <46BA359E.7090203@sun.com> <46BB292F.7050503@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20070109 Content-Length: 1756 Status: RO X-Status: $$$$ X-UID: 0000000007 Rob Gittins wrote: > > Hi Jim, > > Would it be possible to extend vsd_create to take a key as well as > create and return a key? This way a FS can have predefined key values > for specific data elements. This might simplify the usage in some cases. > > Thanks, > Rob > I don't think so. Of course, anything is possible in software, but what I mean is that the keys are system wide. Once a vsd_create() is done, that key is gone until it is destroyed. There isn't a way to reserve a key. The key is only an index into the array of vsd's, starting at zero and incrementing for each vsd that is created The array grows dynamically with the key, there are no preinitialized entries. The user of VSD should not care what their key is. It should be opaque to the user, that is, the user of vsd doesn't need to know the value of the key or the order (or number) of vsd elements. Having a "predefined key" is no different than just using the key returned by vsd_create(). All the calls will be the same, having: uint_t MyFSvsdKey = 0; vsd_create(&MyFSvsdKey, NULL); is no different than #define MyFSvsdKey 1 (or some number) Also, you want the key to be the smallest available, since it determines how big of a vsd array needs to be allocated. You wouldn't want to use a big number because it may be the only vsd being used and we would be wasting space by allocating a large array. Lastly, how would the "reservation" of keys be managed? Who would control that so two different groups/projects don't claim the same key? Again, it is doable, but I don't think it is the right thing to do. Let me know if you still have questions. I could give you a pointer to the code, which may help in understanding how it works. Jim From James.Wahlig@Sun.COM Thu Aug 9 08:54:30 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 l79FsTij020412 for ; Thu, 9 Aug 2007 08:54:29 -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 l79Fq7jG003441; Thu, 9 Aug 2007 23:52:07 +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 <0JMI00C0FK2TUA00@brm-avmta-1.central.sun.com>; Thu, 09 Aug 2007 09:52:06 -0600 (MDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMI001EZK2TKBA0@brm-avmta-1.central.sun.com>; Thu, 09 Aug 2007 09:52:05 -0600 (MDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l79Fq4q3005272; Thu, 09 Aug 2007 15:52:04 +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 <0JMI00C01JOVGS00@mail-amer.sun.com> (original mail from James.Wahlig@Sun.COM); Thu, 09 Aug 2007 09:52:04 -0600 (MDT) Received: from [129.153.131.87] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMI00FBKK2SVUI3@mail-amer.sun.com>; Thu, 09 Aug 2007 09:52:04 -0600 (MDT) Date: Thu, 09 Aug 2007 10:52:04 -0500 From: james wahlig Subject: Re: 2007/456 Vnode Specific Data In-reply-to: <1186674060.4971.2.camel@localhost> Sender: James.Wahlig@Sun.COM To: Bill Sommerfeld Cc: Robert.Gittins@Sun.COM, Calum Mackay , psarc-ext@Sun.COM Reply-to: james.wahlig@central.sun.com Message-id: <46BB3824.1060805@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <46BA359E.7090203@sun.com> <46BB292F.7050503@sun.com> <1186674060.4971.2.camel@localhost> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20070109 Content-Length: 668 Status: RO X-Status: $$$$ X-UID: 0000000008 Bill Sommerfeld wrote: >On Thu, 2007-08-09 at 08:48 -0600, Rob Gittins wrote: > > >>Hi Jim, >> >>Would it be possible to extend vsd_create to take a key as well as >>create and return a key? This way a FS can have predefined key values >>for specific data elements. This might simplify the usage in some cases. >> >> > >as I understand it, this mechanism is intended to permit subsystems >other than filesystems to tag vnodes with subsystem-specific data. > >if you were to do this, how would you preassign key values across all >filesystems so they don't collide? > > - Bill > > > Thank you, a much shorter and easier to parse answer than mine. jim From johnz@domus.sfbay.sun.com Thu Aug 9 09:50:16 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 l79GoGdM021651 for ; Thu, 9 Aug 2007 09:50:16 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l79Gli9P029579 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 9 Aug 2007 10:47:46 -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 <0JMI00J0HMNUHO00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Aug 2007 09:47:54 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMI00I1QMNTIKC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Aug 2007 09:47:53 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l79GlpNF010511; Thu, 09 Aug 2007 09:47:51 -0700 (PDT) Received: (from johnz@localhost) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) id l79Glpq14975; Thu, 09 Aug 2007 09:47:51 -0700 (PDT) Date: Thu, 09 Aug 2007 09:47:51 -0700 (PDT) From: John Zolnowsky x69422/408-404-5064 Subject: Re: 2007/456 Vnode Specific Data To: PSARC-ext@sun.com, James.Wahlig@sun.com, Calum.Mackay@sun.com Message-id: <200708091647.l79Glpq14975@domus.sfbay.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Content-Length: 227 Status: RO X-Status: $$$$ X-UID: 0000000009 Are there locking constraints for this set of interfaces? In particular, can the caller use v_lock to guarantee atomicity of the value associated with a key: can one call vsd_set() and vsd_get() while holding v_lock? -JZ From James.Wahlig@Sun.COM Thu Aug 9 10:09:52 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 l79H9ptE022409 for ; Thu, 9 Aug 2007 10:09:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l79H7TGx015698 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 10 Aug 2007 01:07:29 +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 <0JMI00K10NKFEB00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Aug 2007 10:07:27 -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 <0JMI00JW7NKDSM00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Aug 2007 10:07: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 l79H7OE0027043 for ; Thu, 09 Aug 2007 17:07: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 <0JMI00H01NGEI300@mail-amer.sun.com> (original mail from James.Wahlig@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Aug 2007 11:07:24 -0600 (MDT) Received: from [129.153.131.87] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMI00C2JNK5GUI9@mail-amer.sun.com>; Thu, 09 Aug 2007 11:07:18 -0600 (MDT) Date: Thu, 09 Aug 2007 12:07:17 -0500 From: james wahlig Subject: Re: 2007/456 Vnode Specific Data In-reply-to: <200708091647.l79Glpq14975@domus.sfbay.sun.com> Sender: James.Wahlig@Sun.COM To: John Zolnowsky x69422/408-404-5064 Cc: PSARC-ext@Sun.COM, Calum.Mackay@Sun.COM Reply-to: james.wahlig@central.sun.com Message-id: <46BB49C5.5020904@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200708091647.l79Glpq14975@domus.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20070109 Content-Length: 529 Status: RO X-Status: $$$$ X-UID: 0000000010 John Zolnowsky x69422/408-404-5064 wrote: >Are there locking constraints for this set of interfaces? >In particular, can the caller use v_lock to guarantee atomicity >of the value associated with a key: can one call vsd_set() and >vsd_get() while holding v_lock? > > -JZ > > It is up to the caller to do the protection on vsd_set/get. The caller could use v_lock to protect it. v_lock is not used in or by vsd. If the caller wanted to always grab v_lock before doing a vsd_get() and vsd_get(), that would work. jim From Joerg.Schilling@fokus.fraunhofer.de Fri Aug 10 03:20:51 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 l7AAKk4b013681 for ; Fri, 10 Aug 2007 03:20:51 -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 l7AAIITM029186; Fri, 10 Aug 2007 11:18:22 +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 <0JMJ00A0BZAL7U00@brm-avmta-1.central.sun.com>; Fri, 10 Aug 2007 04:18:21 -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 <0JMJ00BYXZAJU2E0@brm-avmta-1.central.sun.com>; Fri, 10 Aug 2007 04:18:20 -0600 (MDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l7AAH3CG000350; Fri, 10 Aug 2007 10:18:19 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay42i.sun.com with ESMTP id BT-MMP-738074; Fri, 10 Aug 2007 10:18:19 +0000 (Z) Received: from relay41i.sun.com ([192.5.209.70] [192.5.209.70]) by mms48es.sun.com with ESMTP id BT-MMP-514332; Fri, 10 Aug 2007 10:18:19 +0000 (Z) Received: from mailgw1.fraunhofer.de ([153.96.1.18] [153.96.1.18]) by relay4i.sun.com with ESMTP id BT-MMP-2064332; Fri, 10 Aug 2007 10:18:18 +0000 (Z) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de (8.13.5+/8.13.4) with ESMTP id l7AAIHEH021904; Fri, 10 Aug 2007 12:18:17 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw1.fraunhofer.de (8.13.5+/8.13.4) with ESMTP id l7AAI6jt021298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Aug 2007 12:18:07 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id l7AAI5aP013410; Fri, 10 Aug 2007 12:18:06 +0200 (MEST) Received: from burner ([10.147.65.166]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Aug 2007 12:18:05 +0200 Date: Fri, 10 Aug 2007 12:15:10 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: 2007/456 Vnode Specific Data In-reply-to: <46BB3745.9010204@Sun.COM> To: Robert.Gittins@sun.com, james.wahlig@central.sun.com Cc: PSARC-ext@sun.com, Calum.Mackay@sun.com Message-id: <46bc3aae.ZfviroYQyp4Layj8%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.2.0.264296 X-Fraunhofer-Email-Policy: accepted References: <46BA359E.7090203@sun.com> <46BB292F.7050503@sun.com> <46BB3745.9010204@Sun.COM> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 10 Aug 2007 10:18:05.0456 (UTC) FILETIME=[BDA24100:01C7DB37] Content-Length: 1576 Status: RO X-Status: $$$$ X-UID: 0000000011 james wahlig wrote: > > Would it be possible to extend vsd_create to take a key as well as > > create and return a key? This way a FS can have predefined key values > > for specific data elements. This might simplify the usage in some cases. > > > > Thanks, > > Rob > > > I don't think so. Of course, anything is possible in software, but what > I mean is that the keys are system wide. Once a vsd_create() is done, > that key is gone until it is destroyed. There isn't a way to reserve a > key. The key is only an index into the array of vsd's, starting at zero > and incrementing for each vsd that is created The array grows > dynamically with the key, there are no preinitialized entries. > > The user of VSD should not care what their key is. It should be opaque > to the user, that is, the user of vsd doesn't need to know the value of > the key or the order (or number) of vsd elements. > > Having a "predefined key" is no different than just using the key > returned by vsd_create(). All the calls will be the same, having: > uint_t MyFSvsdKey = 0; > vsd_create(&MyFSvsdKey, NULL); > is no different than > #define MyFSvsdKey 1 (or some number) Will the keys not be thread specific but rather unique for every new call? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From James.Wahlig@Sun.COM Fri Aug 10 05:18:44 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 l7ACIiFd015367 for ; Fri, 10 Aug 2007 05:18:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7ACGDdl047323 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 10 Aug 2007 06:16:13 -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 <0JMK00F014R9D800@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 10 Aug 2007 05:16:21 -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 <0JMK00E5A4R8MC10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 10 Aug 2007 05:16:20 -0700 (PDT) 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 l7ACGK9t019549; Fri, 10 Aug 2007 12:16:20 +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 <0JMK00G013WFUA00@mail-amer.sun.com> (original mail from James.Wahlig@Sun.COM); Fri, 10 Aug 2007 06:16:20 -0600 (MDT) Received: from [129.153.131.87] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMK002K84R7CJ75@mail-amer.sun.com>; Fri, 10 Aug 2007 06:16:20 -0600 (MDT) Date: Fri, 10 Aug 2007 07:16:19 -0500 From: james wahlig Subject: Re: 2007/456 Vnode Specific Data In-reply-to: <46bc3aae.ZfviroYQyp4Layj8%Joerg.Schilling@fokus.fraunhofer.de> Sender: James.Wahlig@Sun.COM To: Joerg Schilling Cc: Robert.Gittins@Sun.COM, james.wahlig@central.sun.com, PSARC-ext@Sun.COM, Calum.Mackay@Sun.COM Reply-to: james.wahlig@central.sun.com Message-id: <46BC5712.9080400@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <46BA359E.7090203@sun.com> <46BB292F.7050503@sun.com> <46BB3745.9010204@Sun.COM> <46bc3aae.ZfviroYQyp4Layj8%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20070109 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sac.sfbay.sun.com id l7ACIiFd015367 Content-Length: 1414 Status: RO X-Status: $$$$ X-UID: 0000000012 Joerg Schilling wrote: >james wahlig wrote: > > > >>>Would it be possible to extend vsd_create to take a key as well as >>>create and return a key? This way a FS can have predefined key values >>>for specific data elements. This might simplify the usage in some cases. >>> >>>Thanks, >>>Rob >>> >>> >>> >>I don't think so. Of course, anything is possible in software, but what >>I mean is that the keys are system wide. Once a vsd_create() is done, >>that key is gone until it is destroyed. There isn't a way to reserve a >>key. The key is only an index into the array of vsd's, starting at zero >>and incrementing for each vsd that is created The array grows >>dynamically with the key, there are no preinitialized entries. >> >>The user of VSD should not care what their key is. It should be opaque >>to the user, that is, the user of vsd doesn't need to know the value of >>the key or the order (or number) of vsd elements. >> >>Having a "predefined key" is no different than just using the key >>returned by vsd_create(). All the calls will be the same, having: >> uint_t MyFSvsdKey = 0; >> vsd_create(&MyFSvsdKey, NULL); >>is no different than >> #define MyFSvsdKey 1 (or some number) >> >> > >Will the keys not be thread specific but rather unique for every new call? > >Jörg > > > Yes, every call to vsd_create() will provide a unique key. jim From pjd@garage.freebsd.pl Fri Aug 10 14:14:02 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 l7ALE1uY028147 for ; Fri, 10 Aug 2007 14:14:01 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l7ALBSms008621; Sat, 11 Aug 2007 05:11:34 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JMK00H01TJ73F00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 10 Aug 2007 14:11:31 -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 <0JMK00F5WTJ66L10@nwk-avmta-1.sfbay.Sun.COM>; Fri, 10 Aug 2007 14:11:31 -0700 (PDT) Received: from relay24.sun.com (ip192-12-251-74.block6.us.syntegra.com [192.12.251.74]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7ALBUkj028407; Fri, 10 Aug 2007 21:11:30 +0000 (GMT) Received: from mms23es.sun.com ([150.143.232.54] [150.143.232.54]) by relay24.sun.com with ESMTP id BT-MMP-114364; Fri, 10 Aug 2007 21:11:29 +0000 (Z) Received: from mms24bas.mms.us.syntegra.com (mms24bas.mms.us.syntegra.com [192.12.251.70]) by mms23es.sun.com with ESMTP id BT-MMP-1794249; Fri, 10 Aug 2007 21:11:29 +0000 (Z) Received: from mail.garage.freebsd.pl ([83.17.198.132] [83.17.198.132]) by relay24.sun.com with ESMTP id BT-MMP-1421533; Fri, 10 Aug 2007 21:11:28 +0000 (Z) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id E589D487FA; Fri, 10 Aug 2007 23:11:27 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 82BEA45CD9; Fri, 10 Aug 2007 23:11:23 +0200 (CEST) Date: Fri, 10 Aug 2007 23:10:32 +0200 From: Pawel Jakub Dawidek Subject: Re: 2007/456 Vnode Specific Data In-reply-to: <46BA359E.7090203@sun.com> Sender: pjd@garage.freebsd.pl To: Calum Mackay Cc: psarc-ext@Sun.COM, Jim Wahlig Message-id: <20070810211032.GA17093@garage.freebsd.pl> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=vtzGhvizbBRQ85DL Content-disposition: inline X-PMX-Version: 5.2.0.264296 X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl References: <46BA359E.7090203@sun.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Level: Content-Length: 2098 Status: RO X-Status: $$$$ X-UID: 0000000013 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 08, 2007 at 10:29:02PM +0100, Calum Mackay wrote: > Vnode Specific Data >=20 > Problem Description >=20 > Every time a project needs to keep some data in core that is=20 > associated > with a file object, it has one of two choices. 1) create a database > or hash table to store and lookup the data using the vnode as a=20 > key, or > 2) add yet another field to the vnode data structure. Unfortunatel= y, > it seems like the vnode has become a dumping ground for all kinds of > project specific data. >=20 > Proposed Solution >=20 > The solution is to provide a set of interfaces which will allow the > caller to store and retrieve data on a per vnode basis. If this=20 > sounds > familiar it is because the solution is just like Thread Specific Da= ta. ZFS recently started to use TSD, so I needed to implement something similar for the FreeBSD kernel, but because there are more places that need object specific data (in FreeBSD: threads, jails, network interfaces, maybe vnodes in the future), I just generalized the idea to avoid code duplication and called it Object Specific Data. In case you would like to see the actual code, here it is: http://perforce.freebsd.org/fileDownLoad.cgi?FSPC=3D//depot/user/pjd/zfs/sy= s/sys/osd.h&REV=3D1 http://perforce.freebsd.org/fileDownLoad.cgi?FSPC=3D//depot/user/pjd/zfs/sy= s/kern/kern%5fosd.c&REV=3D1 Maybe this is a better way to go? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGvNRIForvXbEpPzQRAs/lAJsEl596OYfZb47fiOSnE1s3IcJx8wCguGTI c/xenizterx+60ez/1V2dkM= =+u8E -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From Calum.Mackay@sun.com Wed Aug 15 16:34: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 l7FNYxLN028574 for ; Wed, 15 Aug 2007 16:34:59 -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 l7FNWTo5015579 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 16 Aug 2007 00:32:31 +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 <0JMU002059E5SN00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 15 Aug 2007 16:32:29 -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 <0JMU00GBD9E4JH50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 15 Aug 2007 16:32:29 -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 l7FNWSnd017650 for ; Wed, 15 Aug 2007 23:32:28 +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 <0JMU000019CMI700@d1-emea-09.sun.com> (original mail from Calum.Mackay@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 16 Aug 2007 00:32:28 +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 <0JMU009R69E1AIVR@d1-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 16 Aug 2007 00:32:27 +0100 (BST) Date: Thu, 16 Aug 2007 00:32:19 +0100 From: Calum Mackay Subject: Re: 2007/456 Vnode Specific Data In-reply-to: <46BA359E.7090203@sun.com> Sender: Calum.Mackay@sun.com To: Calum Mackay Cc: PSARC-ext@sun.com, Jim Wahlig Message-id: <46C38D03.4010506@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: <46BA359E.7090203@sun.com> User-Agent: Thunderbird 3.0a1pre (X11/2007081507) Content-Length: 66 Status: RO X-Status: $$$$ X-UID: 0000000014 This case was approved during today's PSARC meeting. cheers, c. From Calum.Mackay@sun.com Wed Aug 15 16:39: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 l7FNdjLf028606 for ; Wed, 15 Aug 2007 16:39: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.2) with ESMTP id l7FNb5QC062701 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 15 Aug 2007 17:37:05 -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 <0JMU007039M56Y00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Wed, 15 Aug 2007 16:37:17 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMU00MHI9M2Q880@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Wed, 15 Aug 2007 16:37:17 -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 l7FNbEml017725 for ; Wed, 15 Aug 2007 23:37: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 <0JMU001019KEAQ00@d1-emea-09.sun.com> (original mail from Calum.Mackay@Sun.COM) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Thu, 16 Aug 2007 00:37: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 <0JMU00ISH9M19J4Y@d1-emea-09.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Thu, 16 Aug 2007 00:37:14 +0100 (BST) Date: Thu, 16 Aug 2007 00:37:12 +0100 From: Calum Mackay Subject: Re: 2007/456 Vnode Specific Data In-reply-to: <20070810211032.GA17093@garage.freebsd.pl> Sender: Calum.Mackay@sun.com To: Pawel Jakub Dawidek Cc: psarc-ext@sun.com, Jim Wahlig Message-id: <46C38E28.2030404@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: <46BA359E.7090203@sun.com> <20070810211032.GA17093@garage.freebsd.pl> User-Agent: Thunderbird 3.0a1pre (X11/2007081507) Content-Length: 591 Status: RO X-Status: $$$$ X-UID: 0000000015 hi Pawel, thanks much for the comments. > ZFS recently started to use TSD, so I needed to implement something > similar for the FreeBSD kernel, but because there are more places that > need object specific data (in FreeBSD: threads, jails, network > interfaces, maybe vnodes in the future), I just generalized the idea to > avoid code duplication and called it Object Specific Data. This sounds very interesting, but I think this is providing more than we need just now, for this particular case. We will take a look at it, going forward. thanks again for the pointer. cheers, calum.