From sacadmin Thu May 18 17:25:47 2006 Received: from aja.sfbay.sun.com (aja.SFBay.Sun.COM [129.146.228.101]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4J0PlEx025689; Thu, 18 May 2006 17:25:47 -0700 (PDT) Received: from aja.sfbay.sun.com (localhost [127.0.0.1]) by aja.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4J0RuNU232702; Thu, 18 May 2006 17:27:56 -0700 (PDT) Received: (from artem@localhost) by aja.sfbay.sun.com (8.13.6+Sun/8.13.6/Submit) id k4J0RuhS232685; Thu, 18 May 2006 17:27:56 -0700 (PDT) Date: Thu, 18 May 2006 17:27:56 -0700 (PDT) From: Artem Kachitchkine Message-Id: <200605190027.k4J0RuhS232685@aja.sfbay.sun.com> To: PSARC@sac.sfbay.sun.com Subject: fstyp(1M) extensions [PSARC/2006/337 Timeout: 05/25/2006] Status: RO Content-Length: 7128 Subject: PSARC FastTrack [05/25/2006]: fstyp(1M) extensions Template Version: @(#)sac_nextcase 1.56 10/26/05 SMI This information is Copyright 2006 Sun Microsystems, Inc. 1. Introduction 1.1. Project/Component Working Name: fstyp(1M) extensions 1.2. Name of Document Author/Supplier: Author: Artem Kachitchkine 1.3 Date of This Document: 18 May, 2006 4. Technical Description 4.1 Proposal summary We propose to move filesystem identification code from fstyp(1M) back-ends to shared objects and make it accessible through a new library API, libfstyp. Rewrite fstyp(1M) to use libfstyp while preserving backwards compatibility. Patch binding is requested. 4.2 Problem Solaris offers one CLI and one API for unmounted filesystem identification that are inconsistent, incompatible and duplicate code: - fstyp(1M) command with back-ends in /usr/lib/fs/*/fstyp - ident_fs library for vold(1M), with back-ends /in usr/lib/fs/*/ident* Moreover, vold(1M) will be replaced soon and ident_fs lacks important features. fstyp(1M) is more up to the task, but it lacks a library API. 4.3 Proposal details 4.3.1 libfstyp This is a new library API, libfstyp, for unmounted filesystem identification, with features similar to fstyp(1M). The following functions are provided: int fstyp_init(int fd, off64_t offset, char *module_dir, fstyp_handle_t *handle); void fstyp_fini(fstyp_handle_t handle); Initialize and finalize an opaque handle to be used in subsequent calls. An application must provide an open file descriptor of a block or raw device, an offset in bytes and optional module directory. See fstyp_init(3FSTYP) man page in the materials for more details. int fstyp_ident(fstyp_handle_t handle, const char *fstype, char **ident); Identify a filesystem. If function succeeds, filesystem name is returned in 'ident'. Optionally, the caller can specify 'fstype' to try identify only that filesystem. int fstyp_get_attr(fstyp_handle_t handle, nvlist_t **attrp); Return a name-value list of attributes for an identified filesystem. Each filesystem has its own set of attributes. There are also reserved names for generic attributes, which may also be returned should they make sense for this FSType: gen_clean (DATA_TYPE_BOOLEAN_VALUE) If false, fsck is needed. gen_guid (DATA_TYPE_STRING) Globally unique identifier or its approximation. gen_version (DATA_TYPE_STRING) Filesystem version. gen_volume_label (DATA_TYPE_STRING) Volume label, a human-readable string. int fstyp_dump(fstyp_handle_t handle, FILE *fout, FILE *ferr); Dump filesystem-specific information in arbitrary format. This function exists to provide backwards compatibility for the fstyp(1M) -v option. const char *fstyp_strerror(fstyp_handle_t handle, int error); Get error message string. All of the above functions return 0 on success and a non-zero error code otherwise. See fstyp_strerror(3FSTYP) man page for the list of error codes. 4.3.2 libfstyp modules Today fstyp(1M) is a script that executes filesystem-specific modules located in /usr/lib/fs/*/fstyp. This proposal moves the code from executable modules to shared objects /usr/lib/fs/*/fstyp.so.1 (where 1 is current interface version). Libfstyp will locate and dlopen() these modules. Modules must provide the following interfaces: int fstyp_mod_init(int fd, off64_t offset, fstyp_mod_handle_t *handle); void fstyp_mod_fini(fstyp_mod_handle_t handle); int fstyp_mod_ident(fstyp_mod_handle_t handle); int fstyp_mod_get_attr(fstyp_mod_handle_t handle, nvlist_t **attr); int fstyp_mod_dump(fstyp_mod_handle_t handle, FILE *fout, FILE *ferr); The functions directly match those of libfstyp. All entry points are mandatory except fstyp_mod_dump. If fstyp_mod_dump is NULL, then fstyp(1M) -v output will be identical to -a output. See also fstyp_mod_init(3FSTYP) man page in the materials. 4.3.3 fstyp command fstyp(1M) device specification will now support pcfs-style :N suffixes. A new command-line option is added, "-a", to print all attributes. The format is based on the format used currently by /usr/lib/fs/zfs/fstyp, only the name-value separator is ": " instead of "=", for consistency with existing Solaris and 3rd party fstyp modules. See file outputs.txt in the materials for examples. See also the new fstyp(1M) man page in the materials. 4.3.4 Backwards compatibility fstyp -v output for all filesystems except zfs remains exactly the same. fstyp has been around for a long time and customer scripts might rely on this output, especially for UFS. By the same token, we feel that a slight change in -v output for ZFS should not be a problem. Hardlinks /usr/lib/fs/*/fstyp -> /usr/sbin/fstyp will be created for supported filesystem types. When invoked like that, only the respective filesystem will be identified, just like today. Existing 3rd party executable fstyp modules, e.g. vxfs, will continue to work with fstyp(1M). fstyp(1M) will first look for fstyp.so.1 or fstyp.so module in the /usr/lib/fs/* directories. If a libfstyp module is not found, it will attempt to locate an old-style module and execute it. However, application access through libfstyp(3LIB) will not be available for these legacy modules. The only currently documented fstyp(1M) exit statuses and messages are: exit status 1: "unknown_fstyp (no matches)" exis status 2: "unknown_fstyp (multiple matches)" This proposal preserves these two, but also adds new ones that map directly to libfstyp(3LIB) error codes and messages. 4.4 Interface table Interface Stability Description -------------------------------------------------------------------------- fstyp(1M) Evolving Filesystem identification command libfstyp(3LIB) Evolving Filesystem identification library fstyp_init(3FSTYP) Evolving libfstyp function fstyp_fini(3FSTYP) Evolving libfstyp function fstyp_ident(3FSTYP) Evolving libfstyp function fstyp_get_attr(3FSTYP) Evolving libfstyp function fstyp_dump(3FSTYP) Evolving libfstyp function fstyp_strerror(3FSTYP) Evolving libfstyp function FSTYP_ERR_* Evolving libfstyp error codes fstyp_mod_init(3FSTYP) Evolving libfstyp module function fstyp_mod_fini(3FSTYP) Evolving libfstyp module function fstyp_mod_ident(3FSTYP) Evolving libfstyp module function fstyp_mod_get_attr(3FSTYP) Evolving libfstyp module function fstyp_mod_dump(3FSTYP) Evolving libfstyp module function gen_clean Evolving generic attribute name gen_guid Evolving generic attribute name gen_version Evolving generic attribute name gen_volume_label Evolving generic attribute name fs-specific attributes Cons.Priv. filesystem-specific attribute names -------------------------------------------------------------------------- Release Binding: Patch 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack From sacadmin Thu May 18 17:31:06 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4J0V6ad025710 for ; Thu, 18 May 2006 17:31:06 -0700 (PDT) Received: from nwkea-pix-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4J0V6TF003838 for ; Thu, 18 May 2006 17:31:06 -0700 (PDT) Received: from d1-sfbay-05.sun.com ([192.18.39.115]) by nwkea-pix-1.sun.com (8.12.10+Sun/8.12.9) with ESMTP id k4J0V0ba021968 for ; Thu, 18 May 2006 17:31:00 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-05.sun.com by d1-sfbay-05.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZH00L01LE0QJ00@d1-sfbay-05.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC@sac.sfbay.sun.com; Thu, 18 May 2006 17:31:00 -0700 (PDT) Received: from [129.146.228.101] by d1-sfbay-05.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZH00KJRLFO4W10@d1-sfbay-05.sun.com> for PSARC@sac.sfbay.sun.com; Thu, 18 May 2006 17:31:00 -0700 (PDT) Date: Thu, 18 May 2006 17:33:09 -0700 From: Artem Kachitchkine Subject: Re: fstyp(1M) extensions [PSARC/2006/337 Timeout: 05/25/2006] In-reply-to: <200605190027.k4J0RuhS232685@aja.sfbay.sun.com> Sender: Artem.Kachitchkin@Sun.COM To: PSARC@sac.sfbay.sun.com Message-id: <446D1245.8060500@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200605190027.k4J0RuhS232685@aja.sfbay.sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 7769 (Though I asked sac_nextcase not to email psarc, it apparently did) I am sponsoring this case to myself. Timer is set to 05/25/2006. There are man pages (that need more work, yes) and sample outputs in the materials directory. -Artem. Artem Kachitchkine wrote: > Subject: PSARC FastTrack [05/25/2006]: fstyp(1M) extensions > > > Template Version: @(#)sac_nextcase 1.56 10/26/05 SMI > This information is Copyright 2006 Sun Microsystems, Inc. > 1. Introduction > 1.1. Project/Component Working Name: > fstyp(1M) extensions > 1.2. Name of Document Author/Supplier: > Author: Artem Kachitchkine > 1.3 Date of This Document: > 18 May, 2006 > 4. Technical Description > 4.1 Proposal summary > > We propose to move filesystem identification code from fstyp(1M) back-ends > to shared objects and make it accessible through a new library API, libfstyp. > Rewrite fstyp(1M) to use libfstyp while preserving backwards compatibility. > Patch binding is requested. > > > 4.2 Problem > > Solaris offers one CLI and one API for unmounted filesystem identification > that are inconsistent, incompatible and duplicate code: > > - fstyp(1M) command with back-ends in /usr/lib/fs/*/fstyp > - ident_fs library for vold(1M), with back-ends /in usr/lib/fs/*/ident* > > Moreover, vold(1M) will be replaced soon and ident_fs lacks important > features. fstyp(1M) is more up to the task, but it lacks a library API. > > > 4.3 Proposal details > > 4.3.1 libfstyp > > This is a new library API, libfstyp, for unmounted filesystem identification, > with features similar to fstyp(1M). The following functions are provided: > > int fstyp_init(int fd, off64_t offset, char *module_dir, > fstyp_handle_t *handle); > void fstyp_fini(fstyp_handle_t handle); > > Initialize and finalize an opaque handle to be used in subsequent calls. > An application must provide an open file descriptor of a block > or raw device, an offset in bytes and optional module directory. > See fstyp_init(3FSTYP) man page in the materials for more details. > > int fstyp_ident(fstyp_handle_t handle, const char *fstype, char **ident); > > Identify a filesystem. If function succeeds, filesystem name is returned > in 'ident'. Optionally, the caller can specify 'fstype' to try identify > only that filesystem. > > int fstyp_get_attr(fstyp_handle_t handle, nvlist_t **attrp); > > Return a name-value list of attributes for an identified filesystem. > Each filesystem has its own set of attributes. There are also > reserved names for generic attributes, which may also be returned > should they make sense for this FSType: > > gen_clean (DATA_TYPE_BOOLEAN_VALUE) > > If false, fsck is needed. > > gen_guid (DATA_TYPE_STRING) > > Globally unique identifier or its approximation. > > gen_version (DATA_TYPE_STRING) > > Filesystem version. > > gen_volume_label (DATA_TYPE_STRING) > > Volume label, a human-readable string. > > > int fstyp_dump(fstyp_handle_t handle, FILE *fout, FILE *ferr); > > Dump filesystem-specific information in arbitrary format. > This function exists to provide backwards compatibility > for the fstyp(1M) -v option. > > const char *fstyp_strerror(fstyp_handle_t handle, int error); > > Get error message string. All of the above functions return 0 > on success and a non-zero error code otherwise. See > fstyp_strerror(3FSTYP) man page for the list of error codes. > > > 4.3.2 libfstyp modules > > Today fstyp(1M) is a script that executes filesystem-specific > modules located in /usr/lib/fs/*/fstyp. This proposal > moves the code from executable modules to shared objects > /usr/lib/fs/*/fstyp.so.1 (where 1 is current interface version). > Libfstyp will locate and dlopen() these modules. > > Modules must provide the following interfaces: > > int fstyp_mod_init(int fd, off64_t offset, fstyp_mod_handle_t *handle); > void fstyp_mod_fini(fstyp_mod_handle_t handle); > int fstyp_mod_ident(fstyp_mod_handle_t handle); > int fstyp_mod_get_attr(fstyp_mod_handle_t handle, nvlist_t **attr); > int fstyp_mod_dump(fstyp_mod_handle_t handle, FILE *fout, FILE *ferr); > > The functions directly match those of libfstyp. All entry points are > mandatory except fstyp_mod_dump. If fstyp_mod_dump is NULL, > then fstyp(1M) -v output will be identical to -a output. > > See also fstyp_mod_init(3FSTYP) man page in the materials. > > > 4.3.3 fstyp command > > fstyp(1M) device specification will now support pcfs-style :N suffixes. > > A new command-line option is added, "-a", to print all attributes. The > format is based on the format used currently by /usr/lib/fs/zfs/fstyp, > only the name-value separator is ": " instead of "=", for consistency > with existing Solaris and 3rd party fstyp modules. See file outputs.txt > in the materials for examples. See also the new fstyp(1M) man page in > the materials. > > > 4.3.4 Backwards compatibility > > fstyp -v output for all filesystems except zfs remains exactly the same. > fstyp has been around for a long time and customer scripts might rely > on this output, especially for UFS. By the same token, we feel that > a slight change in -v output for ZFS should not be a problem. > > Hardlinks /usr/lib/fs/*/fstyp -> /usr/sbin/fstyp will be created for > supported filesystem types. When invoked like that, only the respective > filesystem will be identified, just like today. > > Existing 3rd party executable fstyp modules, e.g. vxfs, will continue > to work with fstyp(1M). fstyp(1M) will first look for fstyp.so.1 or > fstyp.so module in the /usr/lib/fs/* directories. If a libfstyp module > is not found, it will attempt to locate an old-style module and execute it. > However, application access through libfstyp(3LIB) will not be available > for these legacy modules. > > The only currently documented fstyp(1M) exit statuses and messages are: > > exit status 1: "unknown_fstyp (no matches)" > exis status 2: "unknown_fstyp (multiple matches)" > > This proposal preserves these two, but also adds new ones that map > directly to libfstyp(3LIB) error codes and messages. > > > 4.4 Interface table > > Interface Stability Description > -------------------------------------------------------------------------- > fstyp(1M) Evolving Filesystem identification command > libfstyp(3LIB) Evolving Filesystem identification library > fstyp_init(3FSTYP) Evolving libfstyp function > fstyp_fini(3FSTYP) Evolving libfstyp function > fstyp_ident(3FSTYP) Evolving libfstyp function > fstyp_get_attr(3FSTYP) Evolving libfstyp function > fstyp_dump(3FSTYP) Evolving libfstyp function > fstyp_strerror(3FSTYP) Evolving libfstyp function > FSTYP_ERR_* Evolving libfstyp error codes > fstyp_mod_init(3FSTYP) Evolving libfstyp module function > fstyp_mod_fini(3FSTYP) Evolving libfstyp module function > fstyp_mod_ident(3FSTYP) Evolving libfstyp module function > fstyp_mod_get_attr(3FSTYP) Evolving libfstyp module function > fstyp_mod_dump(3FSTYP) Evolving libfstyp module function > gen_clean Evolving generic attribute name > gen_guid Evolving generic attribute name > gen_version Evolving generic attribute name > gen_volume_label Evolving generic attribute name > fs-specific attributes Cons.Priv. filesystem-specific attribute names > -------------------------------------------------------------------------- > > Release Binding: Patch > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack From sacadmin Thu May 18 17:49:17 2006 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4J0nG3T025878 for ; Thu, 18 May 2006 17:49:16 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4J0nFTh000450; Thu, 18 May 2006 20:49:15 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4J0nEuS005191; Thu, 18 May 2006 20:49:14 -0400 (EDT) Subject: Re: fstyp(1M) extensions [PSARC/2006/337 Timeout: 05/25/2006] From: Bill Sommerfeld To: Artem Kachitchkine Cc: PSARC@sac.sfbay.sun.com In-Reply-To: <446D1245.8060500@sun.com> References: <200605190027.k4J0RuhS232685@aja.sfbay.sun.com> <446D1245.8060500@sun.com> Content-Type: text/plain Message-Id: <1147999754.1557.322.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Date: Thu, 18 May 2006 20:49:14 -0400 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 195 So, how does this interact with zfs? What happens if the device only contains part of a pool? Is the version you report for zfs the same as the version reported/managed by "zpool upgrade" From sacadmin Thu May 18 17:57:24 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4J0vO3g026472 for ; Thu, 18 May 2006 17:57:24 -0700 (PDT) Received: from nwkea-pix-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4J0vOoc009046 for ; Thu, 18 May 2006 17:57:24 -0700 (PDT) Received: from d1-sfbay-03.sun.com ([192.18.39.113]) by nwkea-pix-1.sun.com (8.12.10+Sun/8.12.9) with ESMTP id k4J0vJpK010766 for ; Thu, 18 May 2006 17:57:19 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-03.sun.com by d1-sfbay-03.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZH00C01L29X100@d1-sfbay-03.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC@sac.sfbay.sun.com; Thu, 18 May 2006 17:57:19 -0700 (PDT) Received: from [129.146.228.101] by d1-sfbay-03.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZH00BUJMNJO800@d1-sfbay-03.sun.com>; Thu, 18 May 2006 17:57:19 -0700 (PDT) Date: Thu, 18 May 2006 17:59:28 -0700 From: Artem Kachitchkine Subject: Re: fstyp(1M) extensions [PSARC/2006/337 Timeout: 05/25/2006] In-reply-to: <1147999754.1557.322.camel@thunk> Sender: Artem.Kachitchkin@Sun.COM To: Bill Sommerfeld Cc: PSARC@sac.sfbay.sun.com Message-id: <446D1870.4010702@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200605190027.k4J0RuhS232685@aja.sfbay.sun.com> <446D1245.8060500@sun.com> <1147999754.1557.322.camel@thunk> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 538 > So, how does this interact with zfs? > > What happens if the device only contains part of a pool? > > Is the version you report for zfs the same as the version > reported/managed by "zpool upgrade" This case does not change fstyp/ZFS interaction. Today the fstyp backend for ZFS uses libzfs function zpool_read_label() which returns an nvlist_t of attributes. With this case, four new attributes will be appended at the end of the list (gen_clean, gen_guid, gen_version, gen_volume_label) and passed to the caller. -Artem. From sacadmin Thu May 18 18:04:19 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4J14JkR026514 for ; Thu, 18 May 2006 18:04:19 -0700 (PDT) Received: from nwkea-pix-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4J14JTF013504 for ; Thu, 18 May 2006 18:04:19 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwkea-pix-1.sun.com (8.12.10+Sun/8.12.9) with ESMTP id k4J14DpK011401 for ; Thu, 18 May 2006 18:04:13 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZH00G01MXDON00@d1-sfbay-10.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC@sac.sfbay.sun.com; Thu, 18 May 2006 18:04:13 -0700 (PDT) Received: from [129.146.228.101] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZH0099DMZ1DJ50@d1-sfbay-10.sun.com> for PSARC@sac.sfbay.sun.com; Thu, 18 May 2006 18:04:13 -0700 (PDT) Date: Thu, 18 May 2006 18:06:23 -0700 From: Artem Kachitchkine Subject: Re: fstyp(1M) extensions [PSARC/2006/337 Timeout: 05/25/2006] In-reply-to: <446D1870.4010702@sun.com> Sender: Artem.Kachitchkin@Sun.COM To: PSARC@sac.sfbay.sun.com Message-id: <446D1A0F.7030801@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200605190027.k4J0RuhS232685@aja.sfbay.sun.com> <446D1245.8060500@sun.com> <1147999754.1557.322.camel@thunk> <446D1870.4010702@sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 437 > This case does not change fstyp/ZFS interaction. Today the fstyp backend > for ZFS uses libzfs function zpool_read_label() which returns an > nvlist_t of attributes. With this case, four new attributes will be > appended at the end of the list (gen_clean, gen_guid, gen_version, > gen_volume_label) and passed to the caller. To clarify: not change to libzfs. The four new attributes are only visible through libfstyp. -Artem. From sacadmin Thu May 18 19:20:19 2006 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4J2KJeK027400 for ; Thu, 18 May 2006 19:20:19 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4J2KIdP009620; Thu, 18 May 2006 22:20:18 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4J2KHuD005514; Thu, 18 May 2006 22:20:17 -0400 (EDT) Subject: Re: fstyp(1M) extensions [PSARC/2006/337 Timeout: 05/25/2006] From: Bill Sommerfeld To: Artem Kachitchkine Cc: PSARC@sac.sfbay.sun.com In-Reply-To: <446D1870.4010702@sun.com> References: <200605190027.k4J0RuhS232685@aja.sfbay.sun.com> <446D1245.8060500@sun.com> <1147999754.1557.322.camel@thunk> <446D1870.4010702@sun.com> Content-Type: text/plain Message-Id: <1148005216.1557.528.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Date: Thu, 18 May 2006 22:20:17 -0400 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 287 On Thu, 2006-05-18 at 20:59, Artem Kachitchkine wrote: > This case does not change fstyp/ZFS interaction. I can't find anything in the case repository which documents fstyp/ZFS interaction. (Just a minor oversight in a large case). Since you're in the neighborhood.. - Bill From sacadmin Fri May 19 05:54:26 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4JCsPEd007234 for ; Fri, 19 May 2006 05:54:25 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k4JCsnJ8017909; Fri, 19 May 2006 08:54:49 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k4JCsnWc017906; Fri, 19 May 2006 08:54:49 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17517.49177.306146.972576@gargle.gargle.HOWL> Date: Fri, 19 May 2006 08:54:49 -0400 From: James Carlson To: Artem Kachitchkine Cc: PSARC@sac.sfbay.sun.com Subject: Re: fstyp(1M) extensions [PSARC/2006/337 Timeout: 05/25/2006] In-Reply-To: Artem Kachitchkine's message of 18 May 2006 17:33:09 References: <200605190027.k4J0RuhS232685@aja.sfbay.sun.com> <446D1245.8060500@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1671 Artem Kachitchkine writes: > > 4.3 Proposal details What's the usage model for fstyp_get_attr? Does the caller pass in a pointer to an uninitialized nvlist_t *, and then do nvlist_free when done? Or must the caller provide an empty nvlist_t * (using nvlist_alloc) that is then used by libfstyp? If it's the former (which I think it is), then this means that the user can't invoke his own nv_alloc_t, right? Either way, who disposes of the contents of the list? For fstyp_ident, what about the storage of char **ident? Is that _always_ a static string? (Nit: consider const char * for module_dir in fstyp_init.) > > fstyp(1M) device specification will now support pcfs-style :N suffixes. > > > > A new command-line option is added, "-a", to print all attributes. The > > format is based on the format used currently by /usr/lib/fs/zfs/fstyp, > > only the name-value separator is ": " instead of "=", for consistency > > with existing Solaris and 3rd party fstyp modules. See file outputs.txt > > in the materials for examples. See also the new fstyp(1M) man page in > > the materials. Are we trying to phase out "fstyp -v"? I'm confused by materials/outputs.txt. Why does this say it has the same output for zfs -a and -v, but the -a output doesn't conform to the specification in the updated man page? The zfs "fstyp -a" output seems much more complex than specified in the documentation: it includes nested and indented components. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Fri May 19 08:36:46 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4JFajQd010405 for ; Fri, 19 May 2006 08:36:45 -0700 (PDT) Received: from nwkea-pix-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4JFajoc012921 for ; Fri, 19 May 2006 08:36:45 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwkea-pix-1.sun.com (8.12.10+Sun/8.12.9) with ESMTP id k4JFaepK028379 for ; Fri, 19 May 2006 08:36:40 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZI00401RCFUW00@d1-sfbay-09.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC@sac.sfbay.sun.com; Fri, 19 May 2006 08:36:40 -0700 (PDT) Received: from [129.150.26.5] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZI00MCLRD40890@d1-sfbay-09.sun.com> for PSARC@sac.sfbay.sun.com; Fri, 19 May 2006 08:36:40 -0700 (PDT) Date: Fri, 19 May 2006 08:34:38 -0700 From: Artem Kachitchkine Subject: Re: fstyp(1M) extensions [PSARC/2006/337 Timeout: 05/25/2006] In-reply-to: <17517.49177.306146.972576@gargle.gargle.HOWL> Sender: Artem.Kachitchkin@Sun.COM To: James Carlson Cc: PSARC@sac.sfbay.sun.com Message-id: <446DE58E.1000700@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200605190027.k4J0RuhS232685@aja.sfbay.sun.com> <446D1245.8060500@sun.com> <17517.49177.306146.972576@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 1283 > What's the usage model for fstyp_get_attr? Does the caller pass in a > pointer to an uninitialized nvlist_t *, and then do nvlist_free when > done? Yes. > If it's the former (which I think it is), then this means that the > user can't invoke his own nv_alloc_t, right? Right. > Either way, who disposes of the contents of the list? The caller. > For fstyp_ident, what about the storage of char **ident? Is that > _always_ a static string? The caller must free() the returned string. > (Nit: consider const char * for module_dir in fstyp_init.) OK. > Are we trying to phase out "fstyp -v"? It's been around for so long I don't think we can get rid of it. But I do think that we shouldn't force new modules to implement fstyp_mod_dump(), in which case -v will print the same data as -a. > I'm confused by materials/outputs.txt. Why does this say it has the > same output for zfs -a and -v, but the -a output doesn't conform to > the specification in the updated man page? The zfs "fstyp -a" output > seems much more complex than specified in the documentation: it > includes nested and indented components. Nesting happens when the nvlist contains another nvlist in it. The updated fstyp(1M) man page should describe the output format a little better. -Artem. From sacadmin Fri May 19 09:01:47 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4JG1lGN011453 for ; Fri, 19 May 2006 09:01:47 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k4JG2BdC019993; Fri, 19 May 2006 12:02:11 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k4JG2BEv019990; Fri, 19 May 2006 12:02:11 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17517.60419.913581.741687@gargle.gargle.HOWL> Date: Fri, 19 May 2006 12:02:11 -0400 From: James Carlson To: Artem Kachitchkine Cc: PSARC@sac.sfbay.sun.com Subject: Re: fstyp(1M) extensions [PSARC/2006/337 Timeout: 05/25/2006] In-Reply-To: Artem Kachitchkine's message of 19 May 2006 08:34:38 References: <200605190027.k4J0RuhS232685@aja.sfbay.sun.com> <446D1245.8060500@sun.com> <17517.49177.306146.972576@gargle.gargle.HOWL> <446DE58E.1000700@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1699 Artem Kachitchkine writes: > > Either way, who disposes of the contents of the list? > > The caller. How exactly does the caller do that? > > For fstyp_ident, what about the storage of char **ident? Is that > > _always_ a static string? > > The caller must free() the returned string. Oh. That needs to be in the documentation for the interface. (Not sure why it needs to be that way, though.) > > Are we trying to phase out "fstyp -v"? > > It's been around for so long I don't think we can get rid of it. But I > do think that we shouldn't force new modules to implement > fstyp_mod_dump(), in which case -v will print the same data as -a. We can certainly mark it as "Obsolete" without ever removing it. Doing so means that new applications (scripts) built on top of fstyp that need detailed information should be using "-a" instead. > > I'm confused by materials/outputs.txt. Why does this say it has the > > same output for zfs -a and -v, but the -a output doesn't conform to > > the specification in the updated man page? The zfs "fstyp -a" output > > seems much more complex than specified in the documentation: it > > includes nested and indented components. > > Nesting happens when the nvlist contains another nvlist in it. The > updated fstyp(1M) man page should describe the output format a little > better. For that syntax to be "Evolving" (as described in the interface table), I think we're going to need a tighter definition of the syntax. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Fri May 19 09:10:31 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4JGAVhL011696 for ; Fri, 19 May 2006 09:10:31 -0700 (PDT) Received: from nwkea-pix-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4JGAVoc001451 for ; Fri, 19 May 2006 09:10:31 -0700 (PDT) Received: from d1-sfbay-05.sun.com ([192.18.39.115]) by nwkea-pix-1.sun.com (8.12.10+Sun/8.12.9) with ESMTP id k4JGAQba016516 for ; Fri, 19 May 2006 09:10:26 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-05.sun.com by d1-sfbay-05.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZI00L01SW9EO00@d1-sfbay-05.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC@sac.sfbay.sun.com; Fri, 19 May 2006 09:10:26 -0700 (PDT) Received: from [129.150.26.5] by d1-sfbay-05.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZI00DFNSXD9Q20@d1-sfbay-05.sun.com> for PSARC@sac.sfbay.sun.com; Fri, 19 May 2006 09:10:26 -0700 (PDT) Date: Fri, 19 May 2006 09:08:24 -0700 From: Artem Kachitchkine Subject: Re: fstyp(1M) extensions [PSARC/2006/337 Timeout: 05/25/2006] In-reply-to: <17517.60419.913581.741687@gargle.gargle.HOWL> Sender: Artem.Kachitchkin@Sun.COM To: James Carlson Cc: PSARC@sac.sfbay.sun.com Message-id: <446DED78.5020008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200605190027.k4J0RuhS232685@aja.sfbay.sun.com> <446D1245.8060500@sun.com> <17517.49177.306146.972576@gargle.gargle.HOWL> <446DE58E.1000700@sun.com> <17517.60419.913581.741687@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 964 >>> Either way, who disposes of the contents of the list? >> The caller. > > How exactly does the caller do that? Using nvlist_free(). >>> For fstyp_ident, what about the storage of char **ident? Is that >>> _always_ a static string? >> The caller must free() the returned string. > > Oh. That needs to be in the documentation for the interface. > > (Not sure why it needs to be that way, though.) I doesn't have to. I thought it was more flexible. But if it seems counterintuitive, I can change it to const. > We can certainly mark it as "Obsolete" without ever removing it. This sounds reasonable to me. > For that syntax to be "Evolving" (as described in the interface > table), I think we're going to need a tighter definition of the > syntax. Sure, I will update the man page. The interface table, btw, does not explicitly classify fstyp *output format* - it probably should, and it probably be less than Evolving. What do you think? -Artem. From sacadmin Fri May 19 09:27:05 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4JGR55i011952 for ; Fri, 19 May 2006 09:27:05 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k4JGRQ3f020143; Fri, 19 May 2006 12:27:26 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k4JGRQG5020140; Fri, 19 May 2006 12:27:26 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17517.61933.866109.400943@gargle.gargle.HOWL> Date: Fri, 19 May 2006 12:27:25 -0400 From: James Carlson To: Artem Kachitchkine Cc: PSARC@sac.sfbay.sun.com Subject: Re: fstyp(1M) extensions [PSARC/2006/337 Timeout: 05/25/2006] In-Reply-To: Artem Kachitchkine's message of 19 May 2006 09:08:24 References: <200605190027.k4J0RuhS232685@aja.sfbay.sun.com> <446D1245.8060500@sun.com> <17517.49177.306146.972576@gargle.gargle.HOWL> <446DE58E.1000700@sun.com> <17517.60419.913581.741687@gargle.gargle.HOWL> <446DED78.5020008@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1822 Artem Kachitchkine writes: > >>> Either way, who disposes of the contents of the list? > >> The caller. > > > > How exactly does the caller do that? > > Using nvlist_free(). OK. > >>> For fstyp_ident, what about the storage of char **ident? Is that > >>> _always_ a static string? > >> The caller must free() the returned string. > > > > Oh. That needs to be in the documentation for the interface. > > > > (Not sure why it needs to be that way, though.) > > I doesn't have to. I thought it was more flexible. But if it seems > counterintuitive, I can change it to const. It doesn't matter much to me either way, but it needs to be documented. The only reason I added that parenthetic note is that I couldn't think of a reason why returning a constant string to name the file system in use ("ufs") would ever involve variable data that needs to be allocated. Call it failure of imagination. > > For that syntax to be "Evolving" (as described in the interface > > table), I think we're going to need a tighter definition of the > > syntax. > > Sure, I will update the man page. The interface table, btw, does not > explicitly classify fstyp *output format* - it probably should, and it > probably be less than Evolving. What do you think? It's mostly up to you. I think it'd be nice to commit to a higher stability level for the output format itself (tag+data and indenting) and at least some of the important tags that other utilities such as Explorer/EKE will need to grok. Including an output format stability, though, so you can distinguish these would be a good first step. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Fri May 19 10:33:13 2006 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4JHXCjw015300 for ; Fri, 19 May 2006 10:33:13 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4JHXAS6028024; Fri, 19 May 2006 13:33:10 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4JHXAZb008510; Fri, 19 May 2006 13:33:10 -0400 (EDT) Subject: Re: fstyp(1M) extensions [PSARC/2006/337 Timeout: 05/25/2006] From: Bill Sommerfeld To: James Carlson Cc: Artem Kachitchkine , PSARC@sac.sfbay.sun.com In-Reply-To: <17517.61933.866109.400943@gargle.gargle.HOWL> References: <200605190027.k4J0RuhS232685@aja.sfbay.sun.com> <446D1245.8060500@sun.com> <17517.49177.306146.972576@gargle.gargle.HOWL> <446DE58E.1000700@sun.com> <17517.60419.913581.741687@gargle.gargle.HOWL> <446DED78.5020008@sun.com> <17517.61933.866109.400943@gargle.gargle.HOWL> Content-Type: text/plain Message-Id: <1148059990.8446.5.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Date: Fri, 19 May 2006 13:33:10 -0400 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 801 On Fri, 2006-05-19 at 12:27, James Carlson wrote: > It's mostly up to you. I think it'd be nice to commit to a higher > stability level for the output format itself (tag+data and indenting) > and at least some of the important tags that other utilities such as > Explorer/EKE will need to grok. IMHO stability of the specific list of attributes included (which is inevitably going to change as filesystems involve) is significantly less important than stability of the overall syntax. That said, some attributes are important enough to warrant higher stability -- as an example, the "version" attribute in ZFS seems like it could be critical to proper handling of ZFS on removable media, especially since the ZFS on-disk format will continue to evolve for the forseeable future. - Bill From sacadmin Mon May 22 15:32:10 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4MMWAd9006852 for ; Mon, 22 May 2006 15:32:10 -0700 (PDT) Received: from nwkea-pix-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4MMWATF025698 for ; Mon, 22 May 2006 15:32:10 -0700 (PDT) Received: from d1-sfbay-05.sun.com ([192.18.39.115]) by nwkea-pix-1.sun.com (8.12.10+Sun/8.12.9) with ESMTP id k4MMW5pK008523 for ; Mon, 22 May 2006 15:32:05 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-05.sun.com by d1-sfbay-05.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZO00201U93QB00@d1-sfbay-05.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC@sac.sfbay.sun.com; Mon, 22 May 2006 15:32:05 -0700 (PDT) Received: from [129.146.228.101] by d1-sfbay-05.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZO00524ULGF940@d1-sfbay-05.sun.com> for PSARC@sac.sfbay.sun.com; Mon, 22 May 2006 15:32:04 -0700 (PDT) Date: Mon, 22 May 2006 15:34:20 -0700 From: Artem Kachitchkine Subject: Re: fstyp(1M) extensions [PSARC/2006/337 Timeout: 05/25/2006] In-reply-to: <200605190027.k4J0RuhS232685@aja.sfbay.sun.com> Sender: Artem.Kachitchkin@Sun.COM To: PSARC@sac.sfbay.sun.com Message-id: <44723C6C.9090104@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200605190027.k4J0RuhS232685@aja.sfbay.sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 7927 Included below is the updated proposal with changebars. fstyp.1m.txt in the materials now describes the output format in more detail. Also for the record, Eric Schrock's answers to Bill's ZFS questions: The label contents are project private. > -- What happens/how do you tell if the device only contains part of a > pool? You can't. Every device is always "part of a pool". Theoretically, the degenerate case of a single-disk pool could be identified if you knew the GUID sum stored in the uberblock, but I'm not sure what value this has or how it applies to fstyp(1M) output. 'zpool import' contains all the logic for assembling pools and determining whether devices are missing, etc. > -- Is the version you report for zfs the same as the version > reported/managed by "zpool upgrade"? Yes. -Artem. 4.1 Proposal summary We propose to move filesystem identification code from fstyp(1M) back-ends to shared objects and make it accessible through a new library API, libfstyp. Rewrite fstyp(1M) to use libfstyp while preserving backwards compatibility. Patch binding is requested. 4.2 Problem Solaris offers one CLI and one API for unmounted filesystem identification that are inconsistent, incompatible and duplicate code: - fstyp(1M) command with back-ends in /usr/lib/fs/*/fstyp - ident_fs library for vold(1M), with back-ends /in usr/lib/fs/*/ident* Moreover, vold(1M) will be replaced soon and ident_fs lacks important features. fstyp(1M) is more up to the task, but it lacks a library API. 4.3 Proposal details 4.3.1 libfstyp This is a new library API, libfstyp, for unmounted filesystem identification, with features similar to fstyp(1M). The following functions are provided: int fstyp_init(int fd, off64_t offset, char *module_dir, fstyp_handle_t *handle); void fstyp_fini(fstyp_handle_t handle); Initialize and finalize an opaque handle to be used in subsequent calls. An application must provide an open file descriptor of a block or raw device, an offset in bytes and optional module directory. See fstyp_init(3FSTYP) man page in the materials for more details. | int fstyp_ident(fstyp_handle_t handle, const char *fstype, | const char **ident); Identify a filesystem. If function succeeds, filesystem name is returned in 'ident'. Optionally, the caller can specify 'fstype' to try identify only that filesystem. int fstyp_get_attr(fstyp_handle_t handle, nvlist_t **attrp); Return a name-value list of attributes for an identified filesystem. | The caller is responsible for freeing the list using nvlist_free(). Each filesystem has its own set of attributes. There are also reserved names for generic attributes, which may also be returned should they make sense for this FSType: gen_clean (DATA_TYPE_BOOLEAN_VALUE) If false, fsck is needed. gen_guid (DATA_TYPE_STRING) Globally unique identifier or its approximation. gen_version (DATA_TYPE_STRING) Filesystem version. gen_volume_label (DATA_TYPE_STRING) Volume label, a human-readable string. int fstyp_dump(fstyp_handle_t handle, FILE *fout, FILE *ferr); Dump filesystem-specific information in arbitrary format. This function exists to provide backwards compatibility for the fstyp(1M) -v option. const char *fstyp_strerror(fstyp_handle_t handle, int error); Get error message string. All of the above functions return 0 on success and a non-zero error code otherwise. See fstyp_strerror(3FSTYP) man page for the list of error codes. 4.3.2 libfstyp modules Today fstyp(1M) is a script that executes filesystem-specific modules located in /usr/lib/fs/*/fstyp. This proposal moves the code from executable modules to shared objects /usr/lib/fs/*/fstyp.so.1 (where 1 is current interface version). Libfstyp will locate and dlopen() these modules. Modules must provide the following interfaces: int fstyp_mod_init(int fd, off64_t offset, fstyp_mod_handle_t *handle); void fstyp_mod_fini(fstyp_mod_handle_t handle); int fstyp_mod_ident(fstyp_mod_handle_t handle); int fstyp_mod_get_attr(fstyp_mod_handle_t handle, nvlist_t **attr); int fstyp_mod_dump(fstyp_mod_handle_t handle, FILE *fout, FILE *ferr); The functions directly match those of libfstyp. All entry points are mandatory except fstyp_mod_dump. If fstyp_mod_dump is NULL, then fstyp(1M) -v output will be identical to -a output. See also fstyp_mod_init(3FSTYP) man page in the materials. 4.3.3 fstyp command fstyp(1M) device specification will now support pcfs-style :N suffixes. A new command-line option is added, "-a", to print all attributes. The format is based on the format used currently by /usr/lib/fs/zfs/fstyp, only the name-value separator is ": " instead of "=", for consistency with existing Solaris and 3rd party fstyp modules. See file outputs.txt in the materials for examples. See also the new fstyp(1M) man page in the materials. 4.3.4 Backwards compatibility fstyp -v output for all filesystems except zfs remains exactly the same. fstyp has been around for a long time and customer scripts might rely on this output, especially for UFS. By the same token, we feel that a slight change in -v output for ZFS should not be a problem. Hardlinks /usr/lib/fs/*/fstyp -> /usr/sbin/fstyp will be created for supported filesystem types. When invoked like that, only the respective filesystem will be identified, just like today. Existing 3rd party executable fstyp modules, e.g. vxfs, will continue to work with fstyp(1M). fstyp(1M) will first look for fstyp.so.1 or fstyp.so module in the /usr/lib/fs/* directories. If a libfstyp module is not found, it will attempt to locate an old-style module and execute it. However, application access through libfstyp(3LIB) will not be available for these legacy modules. The only currently documented fstyp(1M) exit statuses and messages are: exit status 1: "unknown_fstyp (no matches)" exis status 2: "unknown_fstyp (multiple matches)" This proposal preserves these two, but also adds new ones that map directly to libfstyp(3LIB) error codes and messages. 4.4 Interface table Interface Stability Description -------------------------------------------------------------------------- | fstyp(1M) Filesystem identification command | command-line syntax Evolving | output format Evolving | attributes Proj.Priv. except the following | gen_clean Evolving generic attribute | gen_guid Evolving generic attribute | gen_version Evolving generic attribute | gen_volume_label Evolving generic attribute | ZFS 'version' Evolving ZFS attribute | libfstyp(3LIB) Evolving Filesystem identification library fstyp_init(3FSTYP) Evolving libfstyp function fstyp_fini(3FSTYP) Evolving libfstyp function fstyp_ident(3FSTYP) Evolving libfstyp function fstyp_get_attr(3FSTYP) Evolving libfstyp function fstyp_dump(3FSTYP) Evolving libfstyp function fstyp_strerror(3FSTYP) Evolving libfstyp function FSTYP_ERR_* Evolving libfstyp error codes fstyp_mod_init(3FSTYP) Evolving libfstyp module function fstyp_mod_fini(3FSTYP) Evolving libfstyp module function fstyp_mod_ident(3FSTYP) Evolving libfstyp module function fstyp_mod_get_attr(3FSTYP) Evolving libfstyp module function fstyp_mod_dump(3FSTYP) Evolving libfstyp module function -------------------------------------------------------------------------- Release Binding: Patch From sacadmin Wed May 24 19:09:32 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4P29Wla004920 for ; Wed, 24 May 2006 19:09:32 -0700 (PDT) Received: from nwkea-pix-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4P29Vtx008458 for ; Wed, 24 May 2006 19:09:31 -0700 (PDT) Received: from d1-sfbay-05.sun.com ([192.18.39.115]) by nwkea-pix-1.sun.com (8.12.10+Sun/8.12.9) with ESMTP id k4P29QkY001170 for ; Wed, 24 May 2006 19:09:26 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-05.sun.com by d1-sfbay-05.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZS00601SW97I00@d1-sfbay-05.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC@sac.sfbay.sun.com; Wed, 24 May 2006 19:09:26 -0700 (PDT) Received: from [129.146.228.101] by d1-sfbay-05.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZS00DXYTZQOO20@d1-sfbay-05.sun.com>; Wed, 24 May 2006 19:09:26 -0700 (PDT) Date: Wed, 24 May 2006 19:11:46 -0700 From: Artem Kachitchkine Subject: Re: fstyp(1M) extensions [PSARC/2006/337 Timeout: 05/25/2006] In-reply-to: <44723C6C.9090104@sun.com> Sender: Artem.Kachitchkin@Sun.COM To: PSARC@sac.sfbay.sun.com Cc: tamarack@Sun.COM Message-id: <44751262.6040805@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200605190027.k4J0RuhS232685@aja.sfbay.sun.com> <44723C6C.9090104@sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 60 This case was approved at today's PSARC meeting. -Artem.