From sacadmin Fri Mar 17 10:42:26 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2HIgQIQ027850 for ; Fri, 17 Mar 2006 10:42:26 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k2HIgOa22340 for <@sunmail2.sfbay.sun.com:psarc@sun.com>; Fri, 17 Mar 2006 10:42:24 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0IWA00F0LBYFTS00@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Fri, 17 Mar 2006 10:42:15 -0800 (PST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IWA00FXVBYFCVA0@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Fri, 17 Mar 2006 10:42:15 -0800 (PST) Received: from snowdog.eng.sun.com (snowdog.SFBay.Sun.COM [129.146.228.213]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2HIgBJv009935; Fri, 17 Mar 2006 10:42:14 -0800 (PST) Received: from snowdog.eng.sun.com (localhost [127.0.0.1]) by snowdog.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2HIgA3V019122; Fri, 17 Mar 2006 10:42:10 -0800 (PST) Received: (from dp@localhost) by snowdog.eng.sun.com (8.13.5+Sun/8.13.5/Submit) id k2HIgA9n019121; Fri, 17 Mar 2006 10:42:10 -0800 (PST) Date: Fri, 17 Mar 2006 10:42:10 -0800 From: Dan Price Subject: PSARC/2006/180 fsstat(1m) stability update and interface tweak To: psarc@sun.com Cc: Jeff Bonwick , Richard Brown , Dan Price Message-id: <20060317184210.GS5479@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.1.2.240295 User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 5037 I am sponsoring the following case for myself. I am also representing the fsstat team, the zones team and the ZFS team. This case tweaks the user interface of fsstat and lowers its overall stability to unstable. The release binding is unaffected from PSARC/2006/034 (Patch binding). Many thanks to Rich Brown and Jeff Bonwick for their help in preparing this case. Please make sure they are CCed on all mail related to this case. -dp ------------------------------------------------------------------------------- fsstat(1m) stability update and interface tweak Dan Price (dp@eng) Advising: Rich Brown (Rich.Brown@Sun.COM), Jeff Bonwick (bonwick@eng) Introduction ------------ Early feedback on and experience with the fsstat [1] utility has shown that it is in need of further refinements, particularly with respect to non-global Zones [2]. This case seeks to make room in fsstat for future improvements in Solaris Update releases, as well as in future minor releases. Interface Table --------------- Entity Current Stability Proposed Stability -------------------------------------------------------------------------- fsstat(1m) CLI Evolving Unstable fsstat(1m) Output Unstable Unstable (no change) vopstats_{fstype|fsid} Cons Private Cons Private (no change) (Note that the current fsstat man page in build 35 incorrectly documents the stability of the command. This is being fixed.) Background ---------- The concerns about fsstat raised thus far are listed later in this case. We are *not* asking for architectural feedback on these concerns; rather illustrating that they exist and that the parties involved have acknowledged and discussed them. Due to intense time to market pressure communicated by the ZFS team, fsstat has not undergone the usual long Solaris beta cycle, and will ship in Update 2. The ZFS team has emphasized that the utility of the fsstat command justifies its presence in the product even though we expect its output to change. We believe that this is one of the most important changes to observability in Solaris Nevada, and thus deserves leeway to soak and mature further. After further review from the project team, the ZFS team, and the Zones team, it was decided that we seek PSARC approval to note to customers that this utility may change substantially in a future update release, and to remove the default output of the command so that it can be populated at a later date, as well as to remove the parseable output. We have discovered that we lack sufficient customer feedback to know exactly what "mode" default output should reflect. Proposal -------- Members of the project team, the ZFS team, and the Zones team have cooperated to reach this agreement. This solution represents the best compromise of architectural flexibility and time-to-market needs. - Change the default output of fsstat to print the usage message. Move the current default behavior (an aggregated view by filesystem module name) to a new -F option. - Remove the parseable output of fsstat until we have greater experience with the command. - Document in that man page that fsstat is not suitable for the construction of higher level software tools at this time (i.e. don't parse its output). - Alter CLI stability of fsstat to Unstable [3] to allow maximum flexibility in future updates. The kstats which fsstat consumes are not altered in any way by this case. fsstat(1m) Concerns ------------------- Concerns registered thus far are documented in this section. These are for informational purposes; we don't want to debate them here as we have not yet had time to study them in depth: - The default output is unsuitable in current form for Solaris Zones, since it reveals system-wide activity. While not a security problem, the output is essentially nonsensical for non-global zones. - The zones team has provided the advice that at least for zones, admins are going to want to understand how each mount is behaving; they are less likely to be concerned about UFS vs. ZFS activity levels. - The default output of the command may yield information that is difficult for admins to make sense of (the theory is that most admins do not think in terms of filesystem module type). - A more suitable default output may be to follow the model of prstat, and sort the output by activity. Further study and prototyping are needed. - Use of human-readable numbers (i.e. 1.1M, 2.5K, 9.9G) actually obscures which numbers are big or small. References ---------- [1] PSARC 2006/034 fsstat [2] PSARC 2002/174 Virtualization and Namespace Isolation in Solaris [3] PSARC 2005/185 "Enabling Serendipitous Discovery." Opinion, section 4.3. ------------------------------------------------------------------------------- -- Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp From sacadmin Fri Mar 17 11:06:52 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2HJ6pIQ029196 for ; Fri, 17 Mar 2006 11:06:52 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k2HJ6SoQ024650; Sat, 18 Mar 2006 03:06:48 +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 <0IWA0081DD37Z200@nwk-avmta-2.sfbay.sun.com>; Fri, 17 Mar 2006 11:06:43 -0800 (PST) Received: from phorcys.East.Sun.COM ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IWA005LFD36ZV50@nwk-avmta-2.sfbay.sun.com>; Fri, 17 Mar 2006 11:06:42 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k2HJ6fuO005995; Fri, 17 Mar 2006 14:06:41 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k2HJ6exU005992; Fri, 17 Mar 2006 14:06:40 -0500 (EST) Date: Fri, 17 Mar 2006 14:06:40 -0500 From: James Carlson Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak In-reply-to: Dan Price's message of 17 March 2006 10:42:10 To: Dan Price Cc: psarc@sun.com, Jeff Bonwick , Richard Brown Message-id: <17435.2240.805280.25902@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.2.240295 References: <20060317184210.GS5479@eng.sun.com> Status: RO Content-Length: 1060 Dan Price writes: > - Alter CLI stability of fsstat to Unstable [3] to allow maximum > flexibility in future updates. I think it's great that we're trying to give customers good advice about the stability of the OS components, but I don't think Unstable really does what you want here. "Unstable" means that we may change it incompatibly without warning in a Minor release, and compatibly in a Micro release. It doesn't mean we can change it incompatibly in a patch -- which is what Solaris Update releases really are. So if the plan is to release this command now in an update (patch) and then revamp it in some incompatible way in a future update (patch), the Unstable classification won't actually let you do that. The closest match I can find in our taxonomy (other than in Joe's long-awaited rewrite ;-}) is "External." -- 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 Mar 17 11:27:25 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2HJROIQ029440 for ; Fri, 17 Mar 2006 11:27:25 -0800 (PST) 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 k2HJR3IY010718 for <@sunmail1brm.central.sun.com:psarc@sun.com>; Sat, 18 Mar 2006 03:27:23 +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 <0IWA00005E1HDG00@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Fri, 17 Mar 2006 12:27:17 -0700 (MST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IWA00HB7E1GZL90@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Fri, 17 Mar 2006 12:27:16 -0700 (MST) Received: from snowdog.eng.sun.com (snowdog.SFBay.Sun.COM [129.146.228.213]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2HJRFJv022590; Fri, 17 Mar 2006 11:27:15 -0800 (PST) Received: from snowdog.eng.sun.com (localhost [127.0.0.1]) by snowdog.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2HJRFBn019309; Fri, 17 Mar 2006 11:27:15 -0800 (PST) Received: (from dp@localhost) by snowdog.eng.sun.com (8.13.5+Sun/8.13.5/Submit) id k2HJRFna019308; Fri, 17 Mar 2006 11:27:15 -0800 (PST) Date: Fri, 17 Mar 2006 11:27:14 -0800 From: Dan Price Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak In-reply-to: <17435.2240.805280.25902@gargle.gargle.HOWL> To: James Carlson Cc: psarc@sun.com, Jeff Bonwick , Richard Brown Message-id: <20060317192714.GX5479@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.1.2.240295 References: <20060317184210.GS5479@eng.sun.com> <17435.2240.805280.25902@gargle.gargle.HOWL> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 2079 On Fri 17 Mar 2006 at 02:06PM, James Carlson wrote: > Dan Price writes: > > - Alter CLI stability of fsstat to Unstable [3] to allow maximum > > flexibility in future updates. > > I think it's great that we're trying to give customers good advice > about the stability of the OS components, but I don't think Unstable > really does what you want here. > > "Unstable" means that we may change it incompatibly without warning in > a Minor release, and compatibly in a Micro release. It doesn't mean > we can change it incompatibly in a patch -- which is what Solaris > Update releases really are. > > So if the plan is to release this command now in an update (patch) and > then revamp it in some incompatible way in a future update (patch), > the Unstable classification won't actually let you do that. > > The closest match I can find in our taxonomy (other than in Joe's > long-awaited rewrite ;-}) is "External." I did consider this; we also discussed a variety of other options to mitigate this problem (unbundle fsstat, put it in /usr/demo, et cetera), and gauged that each of them would be unacceptable either to the primary requestor (ZFS) or to the ARC. If the ARC thinks "External" is appropriate, I am open to changing it if Rich and Jeff also sign off. This consideration contributed to our choice to remove the default output-- I feel that in patches, we can compatibly rev the command to add a default output and new output modes. Additionally, I wanted the freedom to make more drastic changes in Nevada should we choose to do so. Also, could I request clarification about the notion of "compatible" change in an output format useful only for human beings? Part of what we want to make clear here is that the output should not be consumed by higher level software. Is there some documentation about what this means, which I can review? (In a nutshell, could we alter the output columns or add a sort order, or alter the output formatting in a patch?) -dp -- Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp From sacadmin Fri Mar 17 11:35:58 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2HJZwIQ029527 for ; Fri, 17 Mar 2006 11:35:58 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k2HJZva22964; Fri, 17 Mar 2006 11:35:57 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0IWA00L0DEFW6C00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 17 Mar 2006 11:35:56 -0800 (PST) Received: from phorcys.East.Sun.COM ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IWA00FRIEFVCUE0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 17 Mar 2006 11:35:56 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k2HJZsHE006104; Fri, 17 Mar 2006 14:35:54 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k2HJZscX006101; Fri, 17 Mar 2006 14:35:54 -0500 (EST) Date: Fri, 17 Mar 2006 14:35:54 -0500 From: James Carlson Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak In-reply-to: Dan Price's message of 17 March 2006 11:27:14 To: Dan Price Cc: psarc@sun.com, Jeff Bonwick , Richard Brown Message-id: <17435.3994.826487.754984@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.2.240295 References: <20060317184210.GS5479@eng.sun.com> <17435.2240.805280.25902@gargle.gargle.HOWL> <20060317192714.GX5479@eng.sun.com> Status: RO Content-Length: 1733 Dan Price writes: > I did consider this; we also discussed a variety of other options to > mitigate this problem (unbundle fsstat, put it in /usr/demo, et cetera), > and gauged that each of them would be unacceptable either to the primary > requestor (ZFS) or to the ARC. If the ARC thinks "External" is > appropriate, I am open to changing it if Rich and Jeff also sign off. It might be ... but I'd like to know more about what's intended here. Will the command line be expected to change in incompatible ways in S10 Updates? If so, then Unstable just won't do it. Only External matches all the criteria (publicly available and can be broken by patch). If the plan doesn't include breaking the command line options until Nevada releases, then Unstable sounds like the right answer. > Also, could I request clarification about the notion of "compatible" > change in an output format useful only for human beings? Part of what > we want to make clear here is that the output should not be consumed by > higher level software. Is there some documentation about what this > means, which I can review? (In a nutshell, could we alter the output > columns or add a sort order, or alter the output formatting in a patch?) We usually just call that "Project Private" or informally "not an interface." The point is that, unlike the public stability levels, we don't document the actual output format in any man page and (if possible) we warn people away from trying to depend on it by reverse engineering. -- 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 Sun Mar 19 19:27:54 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2K3RrIQ023669 for ; Sun, 19 Mar 2006 19:27:54 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k2K3Rlff024436; Mon, 20 Mar 2006 11:27:50 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0IWE00803PM89300@nwk-avmta-2.sfbay.sun.com>; Sun, 19 Mar 2006 19:27:44 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.68.130]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IWE002H8PM70830@nwk-avmta-2.sfbay.sun.com>; Sun, 19 Mar 2006 19:27:43 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6.Gamma0+Sun/8.13.5) with SMTP id k2K3RbT5670515; Sun, 19 Mar 2006 19:27:42 -0800 (PST) Date: Sun, 19 Mar 2006 17:26:11 -1000 (HST) From: Joseph Kowalski Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak To: psarc@Sun.Com, dp@eng.sun.com Cc: bonwick@eng.sun.com, Rich.Brown@Sun.Com, dp@eng.sun.com Reply-to: Joseph Kowalski Message-id: <200603200327.k2K3RbT5670515@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: 6GRp8NYxd2vba0O9zTQLwA== X-PMX-Version: 5.1.2.240295 Status: RO Content-Length: 891 > From: Dan Price ... > > Entity Current Stability Proposed Stability > -------------------------------------------------------------------------- > fsstat(1m) CLI Evolving Unstable > fsstat(1m) Output Unstable Unstable (no change) > vopstats_{fstype|fsid} Cons Private Cons Private (no change) Which as Jim said, doesn't accomplish the goal. Unstable locks thinks down until the next Minor release. Since you removed the option for machine parsable output, the output should simply be declared as "human parsable only". This seem easy. IMHO, if you can't call the CLI at least unstable, the best place for this is in your home directory. Seriously, if this hasn't been work out to the degree where some commitment can be made for it, deliver it as a demo. - jek3 From sacadmin Sun Mar 19 21:48:49 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2K5mmIQ025645 for ; Sun, 19 Mar 2006 21:48:49 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k2K5mkhG025296 for <@sunmail2.sfbay.sun.com:psarc@sun.com>; Mon, 20 Mar 2006 13:48:47 +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 (built Dec 2 2004)) id <0IWE00G01W5A5Z00@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Sun, 19 Mar 2006 21:48:46 -0800 (PST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IWE00HZLW5AFR80@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Sun, 19 Mar 2006 21:48:46 -0800 (PST) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2K5mjJv020667; Sun, 19 Mar 2006 21:48:46 -0800 (PST) Received: from unknown (vpn-129-150-16-38.SFBay.Sun.COM [129.150.16.38]) by zion.eng.sun.com (8.13.3+Sun/8.13.3) with SMTP id k2K5mi23026309; Sun, 19 Mar 2006 21:48:45 -0800 (PST) Date: Sun, 19 Mar 2006 21:48:21 -0800 (PST) From: Jeff Bonwick Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak To: psarc@sun.com, dp@eng.sun.com, Joseph.Kowalski@eng.sun.com Cc: bonwick@eng.sun.com, Rich.Brown@sun.com, dp@eng.sun.com Reply-to: Jeff Bonwick Message-id: <200603200548.k2K5mi23026309@zion.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_35 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: BH9QBUB8wYGwLHdJNTKOlg== X-PMX-Version: 5.1.2.240295 Status: RO Content-Length: 416 > Unstable locks things down until the next Minor release. Hmmm... then we need "Ephemeral" or "Experimental" or "Actinide Series". I understand your point about shipping in /usr/demo. But as a practical matter, I don't think the path is any more of a deterrent than the advertised commitment level. People can create dependencies on *anything* if they're so inclined. It's just more of a hassle to type. Jeff From sacadmin Sun Mar 19 22:24:01 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2K6O0IQ026626 for ; Sun, 19 Mar 2006 22:24:01 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k2K6NOWh012616; Mon, 20 Mar 2006 14:23:57 +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 (built Dec 2 2004)) id <0IWE00J01XRWQM00@nwk-avmta-1.sfbay.Sun.COM>; Sun, 19 Mar 2006 22:23:56 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.228.50]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IWE00HG1XRWFNA0@nwk-avmta-1.sfbay.Sun.COM>; Sun, 19 Mar 2006 22:23:56 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6.Gamma0+Sun/8.13.5) with SMTP id k2K6Njsp791290; Sun, 19 Mar 2006 22:23:54 -0800 (PST) Date: Sun, 19 Mar 2006 20:22:23 -1000 (HST) From: Joseph Kowalski Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak To: psarc@sun.com, dp@eng.sun.com, Joseph.Kowalski@eng.sun.com, bonwick@zion.eng.sun.com Cc: bonwick@eng.sun.com, Rich.Brown@sun.com, dp@eng.sun.com Reply-to: Joseph Kowalski Message-id: <200603200623.k2K6Njsp791290@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: 4oBJgdQe0jZaQgfAKH0gvA== X-PMX-Version: 5.1.2.240295 Status: RO Content-Length: 1069 > From: Jeff Bonwick ... > > Unstable locks things down until the next Minor release. > > Hmmm... then we need "Ephemeral" or "Experimental" or "Actinide Series". > > I understand your point about shipping in /usr/demo. But as > a practical matter, I don't think the path is any more of a > deterrent than the advertised commitment level. People can > create dependencies on *anything* if they're so inclined. > It's just more of a hassle to type. > > Jeff Understood. I'n my late rewrite, we have "Volatile". ("Ephemeral was seriously suggested".) Unfortunately, its not yet in force. That said, I'd only approve of "Volatile" for this, if it had an automatic promotion clause, perhaps moving to Stable with S10 GA. We've had too many things request temporarily low bindings only to never raise them. Let's be pragmatic. Maybe we can just put some appropriate text on the man page and have the ARC approve that. An internal caviate would be that as far as Sun is concerned, it's consoldation private. Sound possible? - jek3 From sacadmin Sun Mar 19 22:28:19 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2K6SHIQ026693 for ; Sun, 19 Mar 2006 22:28:18 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k2K6SEa2015091; Mon, 20 Mar 2006 14:28:14 +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 (built Dec 2 2004)) id <0IWE00K01XYY7Q00@nwk-avmta-1.sfbay.Sun.COM>; Sun, 19 Mar 2006 22:28:10 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.108.38]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IWE00H25XYYFUA0@nwk-avmta-1.sfbay.Sun.COM>; Sun, 19 Mar 2006 22:28:10 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6.Gamma0+Sun/8.13.5) with SMTP id k2K6S0cM792017; Sun, 19 Mar 2006 22:28:08 -0800 (PST) Date: Sun, 19 Mar 2006 20:26:38 -1000 (HST) From: Joseph Kowalski Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak To: psarc@sun.com, dp@eng.sun.com, Joseph.Kowalski@eng.sun.com, bonwick@zion.eng.sun.com Cc: bonwick@eng.sun.com, Rich.Brown@sun.com, dp@eng.sun.com Reply-to: Joseph Kowalski Message-id: <200603200628.k2K6S0cM792017@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: h/0x1hZAsFDJQlU22knjIw== X-PMX-Version: 5.1.2.240295 Status: RO Content-Length: 927 More.... > From: Jeff Bonwick ... > I understand your point about shipping in /usr/demo. But as > a practical matter, I don't think the path is any more of a > deterrent than the advertised commitment level. People can > create dependencies on *anything* if they're so inclined. > It's just more of a hassle to type. Actually, I disagree. I've never heard anyone actually complain when we change something in demo. Its pretty obvious what they are getting. The reason I don't like the /usr/demo suggestion is because this clearly isn't really a demo, and I'd rather put it where it belongs long term. Moving stuff around makes nobody happy. Seriously, would it be that hard to agree not to change the CLI incompatably? Seems like continuing to support everything there wouldn't be too hard (now that machine parseable output has been dropped). You can always add more options. - jek3 From sacadmin Mon Mar 20 07:52:40 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2KFqcIQ009570 for ; Mon, 20 Mar 2006 07:52:40 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k2KFqcv18032 for <@sunmail1brm.central.sun.com:psarc@sun.com>; Mon, 20 Mar 2006 07:52:38 -0800 (PST) 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 <0IWF0050FO3PVB00@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 20 Mar 2006 08:52:37 -0700 (MST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IWF004SEO3O3SA0@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 20 Mar 2006 08:52:37 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2KFqaJv007896; Mon, 20 Mar 2006 07:52:36 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k2KFpcvi026833; Mon, 20 Mar 2006 07:51:38 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k2KFpcMH026832; Mon, 20 Mar 2006 07:51:38 -0800 (PST) Date: Mon, 20 Mar 2006 07:51:38 -0800 (PST) From: Gary Winiger Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak To: psarc@sun.com, dp@eng.sun.com, Joseph.Kowalski@eng.sun.com, bonwick@zion.eng.sun.com Cc: bonwick@eng.sun.com, Rich.Brown@sun.com Message-id: <200603201551.k2KFpcMH026832@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.1.2.240295 Status: RO Content-Length: 654 >> Understood. > > I'n my late rewrite, we have "Volatile". ("Ephemeral was seriously > suggested".) Unfortunately, its not yet in force. I thought the taxonomy case had converged. Perhaps we can still use Volatile before the final gets published. It does seem to apply to what this case is asking for. > That said, I'd only approve of "Volatile" for this, if it had an > automatic promotion clause, perhaps moving to Stable with S10 GA. > We've had too many things request temporarily low bindings only to > never raise them. This seems to me to be the real discussion point. "What's the future stability and when will it occur?" Gary.. From sacadmin Mon Mar 20 09:53:07 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2KHr6IQ012502 for ; Mon, 20 Mar 2006 09:53:07 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k2KHqcNA004291; Tue, 21 Mar 2006 01:53:03 +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 (built Dec 2 2004)) id <0IWF00K05TOBU300@nwk-avmta-1.sfbay.Sun.COM>; Mon, 20 Mar 2006 09:52:59 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.228.50]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IWF007VWTOBRT80@nwk-avmta-1.sfbay.Sun.COM>; Mon, 20 Mar 2006 09:52:59 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6.Gamma0+Sun/8.13.5) with SMTP id k2KHqriZ335522; Mon, 20 Mar 2006 09:52:58 -0800 (PST) Date: Mon, 20 Mar 2006 07:51:25 -1000 (HST) From: Joseph Kowalski Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak To: psarc@sun.com, dp@eng.sun.com, Joseph.Kowalski@eng.sun.com, bonwick@zion.eng.sun.com, gww@eng.sun.com Cc: bonwick@eng.sun.com, Rich.Brown@sun.com Reply-to: Joseph Kowalski Message-id: <200603201752.k2KHqriZ335522@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: flqE64e4UCpt4iUJoybIKA== X-PMX-Version: 5.1.2.240295 Status: RO Content-Length: 874 > From: Gary Winiger ... > >> Understood. > > > > In my late rewrite, we have "Volatile". ("Ephemeral was seriously > > suggested".) Unfortunately, its not yet in force. > > I thought the taxonomy case had converged. Perhaps we can still > use Volatile before the final gets published. It does seem to > apply to what this case is asking for. > > > That said, I'd only approve of "Volatile" for this, if it had an > > automatic promotion clause, perhaps moving to Stable with S10 GA. > > We've had too many things request temporarily low bindings only to > > never raise them. > > This seems to me to be the real discussion point. "What's the > future stability and when will it occur?" > > Gary.. Right. Let's work out what we want and then figure out how to do the paperwork. We shouldn't be overly constrained by terminology. - jek3 From sacadmin Mon Mar 20 15:23:11 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2KNNAIQ025017 for ; Mon, 20 Mar 2006 15:23:11 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k2KNMqZn025242 for <@sunmail3.sfbay.sun.com:psarc@sun.com>; Tue, 21 Mar 2006 07:23:09 +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 <0IWG009078YIP300@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 20 Mar 2006 15:23:06 -0800 (PST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IWG001ZW8YHJY90@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 20 Mar 2006 15:23:05 -0800 (PST) Received: from snowdog.eng.sun.com (snowdog.SFBay.Sun.COM [129.146.228.213]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2KNN4Jv029373; Mon, 20 Mar 2006 15:23:05 -0800 (PST) Received: from snowdog.eng.sun.com (localhost [127.0.0.1]) by snowdog.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2KNN49p006502; Mon, 20 Mar 2006 15:23:04 -0800 (PST) Received: (from dp@localhost) by snowdog.eng.sun.com (8.13.5+Sun/8.13.5/Submit) id k2KNN4Ux006501; Mon, 20 Mar 2006 15:23:04 -0800 (PST) Date: Mon, 20 Mar 2006 15:23:04 -0800 From: Dan Price Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak In-reply-to: <200603201752.k2KHqriZ335522@jurassic.eng.sun.com> To: Joseph Kowalski Cc: psarc@sun.com, bonwick@zion.eng.sun.com, gww@eng.sun.com, bonwick@eng.sun.com, Rich.Brown@sun.com Message-id: <20060320232304.GR5479@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.1.2.240295 References: <200603201752.k2KHqriZ335522@jurassic.eng.sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 2048 On Mon 20 Mar 2006 at 07:51AM, Joseph Kowalski wrote: > > > From: Gary Winiger > ... > > >> Understood. > > > > > > In my late rewrite, we have "Volatile". ("Ephemeral was seriously > > > suggested".) Unfortunately, its not yet in force. > > > > I thought the taxonomy case had converged. Perhaps we can still > > use Volatile before the final gets published. It does seem to > > apply to what this case is asking for. > > > > > That said, I'd only approve of "Volatile" for this, if it had an > > > automatic promotion clause, perhaps moving to Stable with S10 GA. > > > We've had too many things request temporarily low bindings only to > > > never raise them. > > > > This seems to me to be the real discussion point. "What's the > > future stability and when will it occur?" > > > > Gary.. > > Right. > > Let's work out what we want and then figure out how to do the paperwork. > We shouldn't be overly constrained by terminology. Rich and I just got off the phone. We know what we, at least, want: CLI: - We want to modify the CLI compatibly throughout the S10U* train (patches, and micro releases if applicable) - We want to be able to incompatibly modify the CLI, if really needed, in the current minor release (Nevada). Output: - We want to be able to modify the output in future S10U* patches; this may involve altering the sort order, changing the columns, etc. - We want to be able to modify the output in Nevada, and in future minor releases beyond. We anticipate the return of the parseable output mode once things settle. Whatever PSARC wants to call these designations is OK with us :) We have agreement among the iteams that this represents the best engineering/business balance. So, if PSARC could issue us a ruling on what we should call these things, I'll update the case, and maybe we can wrap up :) -dp -- Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp From sacadmin Mon Mar 20 15:30:41 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2KNUeIQ025099 for ; Mon, 20 Mar 2006 15:30:40 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k2KNUec04964 for <@sunmail2.sfbay.sun.com:psarc@sun.com>; Mon, 20 Mar 2006 16:30:40 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0IWG008019B3W100@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 20 Mar 2006 15:30:39 -0800 (PST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IWG001279B2NP50@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 20 Mar 2006 15:30:38 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2KNUcJv000802; Mon, 20 Mar 2006 15:30:38 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k2KNTf1X027518; Mon, 20 Mar 2006 15:29:41 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k2KNTfsb027517; Mon, 20 Mar 2006 15:29:41 -0800 (PST) Date: Mon, 20 Mar 2006 15:29:41 -0800 (PST) From: Gary Winiger Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak To: Joseph.Kowalski@eng.sun.com, dp@eng.sun.com Cc: psarc@sun.com, bonwick@zion.eng.sun.com, gww@eng.sun.com, bonwick@eng.sun.com, Rich.Brown@sun.com Message-id: <200603202329.k2KNTfsb027517@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.1.2.240295 Status: RO Content-Length: 1635 > > Right. > > > > Let's work out what we want and then figure out how to do the paperwork. > > We shouldn't be overly constrained by terminology. > > Rich and I just got off the phone. We know what we, at least, want: > > CLI: > - We want to modify the CLI compatibly throughout the S10U* > train (patches, and micro releases if applicable) > > - We want to be able to incompatibly modify the CLI, if really > needed, in the current minor release (Nevada). In today's terms, this is call Unstable. In the new terms, Uncommitted. > Output: > - We want to be able to modify the output in future S10U* patches; > this may involve altering the sort order, changing the columns, etc. > > - We want to be able to modify the output in Nevada, and in > future minor releases beyond. We anticipate the return of the > parseable output mode once things settle. In today's terms we note in the stability section that this is only for human consumption -- until y'all make it parseable then it becomes stable. In the new terms, Not An Interface > > > Whatever PSARC wants to call these designations is OK with us :) > > We have agreement among the iteams that this represents the best > engineering/business balance. > > So, if PSARC could issue us a ruling on what we should call these > things, I'll update the case, and maybe we can wrap up :) Seems fine to me. CLI is Unstable (can change incompatible in a minor). Output is for human consumption only as described in the ATTRIBUTES section that points to a NOTES section. Gary.. From sacadmin Mon Mar 20 15:32:56 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2KNWtIQ025141 for ; Mon, 20 Mar 2006 15:32:55 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k2KNWrEO000732 for <@sunmail2.sfbay.sun.com:psarc@sun.com>; Tue, 21 Mar 2006 07:32:54 +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 (built Dec 2 2004)) id <0IWG0090D9EQ4Y00@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 20 Mar 2006 15:32:50 -0800 (PST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IWG001M49EPNQ50@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 20 Mar 2006 15:32:50 -0800 (PST) Received: from snowdog.eng.sun.com (snowdog.SFBay.Sun.COM [129.146.228.213]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2KNWnJv001117; Mon, 20 Mar 2006 15:32:49 -0800 (PST) Received: from snowdog.eng.sun.com (localhost [127.0.0.1]) by snowdog.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2KNWnUE006512; Mon, 20 Mar 2006 15:32:49 -0800 (PST) Received: (from dp@localhost) by snowdog.eng.sun.com (8.13.5+Sun/8.13.5/Submit) id k2KNWmNI006511; Mon, 20 Mar 2006 15:32:48 -0800 (PST) Date: Mon, 20 Mar 2006 15:32:48 -0800 From: Dan Price Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak In-reply-to: <200603202329.k2KNTfsb027517@marduk.eng.sun.com> To: Gary Winiger Cc: Joseph.Kowalski@eng.sun.com, psarc@sun.com, bonwick@zion.eng.sun.com, bonwick@eng.sun.com, Rich.Brown@sun.com Message-id: <20060320233248.GS5479@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.1.2.240295 References: <200603202329.k2KNTfsb027517@marduk.eng.sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 764 On Mon 20 Mar 2006 at 03:29PM, Gary Winiger wrote: > > Whatever PSARC wants to call these designations is OK with us :) > > > > We have agreement among the iteams that this represents the best > > engineering/business balance. > > > > So, if PSARC could issue us a ruling on what we should call these > > things, I'll update the case, and maybe we can wrap up :) > > Seems fine to me. CLI is Unstable (can change incompatible in > a minor). Output is for human consumption only as described in the > ATTRIBUTES section that points to a NOTES section. Great. If I don't hear immediate objections, I'll issue a new version of the case later today or tonight. -dp -- Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp From sacadmin Mon Mar 20 19:23:14 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2L3NEIQ001994 for ; Mon, 20 Mar 2006 19:23:14 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k2L3NCc07536; Mon, 20 Mar 2006 20:23:13 -0700 (MST) 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 <0IWG00J03K2NUD00@nwk-avmta-2.sfbay.sun.com>; Mon, 20 Mar 2006 19:23:11 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.56.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IWG00I0AK2MMY10@nwk-avmta-2.sfbay.sun.com>; Mon, 20 Mar 2006 19:23:10 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6.Gamma0+Sun/8.13.5) with SMTP id k2L3N5qb907503; Mon, 20 Mar 2006 19:23:09 -0800 (PST) Date: Mon, 20 Mar 2006 17:21:36 -1000 (HST) From: Joseph Kowalski Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak To: Joseph.Kowalski@eng.sun.com, dp@eng.sun.com Cc: psarc@sun.com, bonwick@zion.eng.sun.com, gww@eng.sun.com, bonwick@eng.sun.com, Rich.Brown@sun.com Reply-to: Joseph Kowalski Message-id: <200603210323.k2L3N5qb907503@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: 5vSNpr1tTyLWEZpIJDMBMQ== X-PMX-Version: 5.1.2.240295 Status: RO Content-Length: 788 > Date: Mon, 20 Mar 2006 15:23:04 -0800 ... > CLI: > - We want to modify the CLI compatibly throughout the S10U* > train (patches, and micro releases if applicable) > > - We want to be able to incompatibly modify the CLI, if really > needed, in the current minor release (Nevada). Isn't this S10 rather than Nevada? This goes into U2 (or U3), right? > Output: > - We want to be able to modify the output in future S10U* patches; > this may involve altering the sort order, changing the columns, etc. > > - We want to be able to modify the output in Nevada, and in > future minor releases beyond. We anticipate the return of the > parseable output mode once things settle. No problem here. - jek3 From sacadmin Mon Mar 20 19:27:23 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2L3RMIQ002014 for ; Mon, 20 Mar 2006 19:27:23 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k2L3R7ad024245; Tue, 21 Mar 2006 11:27:19 +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 <0IWG00K01K9G0O00@nwk-avmta-2.sfbay.sun.com>; Mon, 20 Mar 2006 19:27:16 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.228.50]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IWG00IX7K9FMZ00@nwk-avmta-2.sfbay.sun.com>; Mon, 20 Mar 2006 19:27:15 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6.Gamma0+Sun/8.13.5) with SMTP id k2L3RAIt908484; Mon, 20 Mar 2006 19:27:14 -0800 (PST) Date: Mon, 20 Mar 2006 17:25:41 -1000 (HST) From: Joseph Kowalski Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak To: Joseph.Kowalski@eng.sun.com, dp@eng.sun.com, gww@eng.sun.com Cc: psarc@sun.com, bonwick@zion.eng.sun.com, gww@eng.sun.com, bonwick@eng.sun.com, Rich.Brown@sun.com Reply-to: Joseph Kowalski Message-id: <200603210327.k2L3RAIt908484@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: nZt8HTqpCw187zK5yQegOg== X-PMX-Version: 5.1.2.240295 Status: RO Content-Length: 826 > From: Gary Winiger ... > > CLI: > > - We want to modify the CLI compatibly throughout the S10U* > > train (patches, and micro releases if applicable) > > > > - We want to be able to incompatibly modify the CLI, if really > > needed, in the current minor release (Nevada). > > In today's terms, this is call Unstable. In the new terms, > Uncommitted. Sorry, I misread this. I see Gary's reading (and conclusion) as correct. You get exactly one chance to make the incompatable change which is in Nevada GA. I'd like to see a promotion clause: S10 - Unstable/Uncommitted post-S10 - Stable/Committed That should give you what is wanted. It may seem like the term Nevada should show up, but the rules at the S10->Nevada transition are the S10 rules. - jek3 From sacadmin Mon Mar 20 20:28:16 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2L4SEIQ002896 for ; Mon, 20 Mar 2006 20:28:15 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k2L4S6Wh020377 for <@sunmail3.sfbay.sun.com:psarc@sun.com>; Tue, 21 Mar 2006 12:28:13 +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 <0IWG00M01N2ZKS00@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 20 Mar 2006 20:28:11 -0800 (PST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IWG00IZZN2ZMX20@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 20 Mar 2006 20:28:11 -0800 (PST) Received: from snowdog.eng.sun.com (snowdog.SFBay.Sun.COM [129.146.228.213]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2L4SAJv022690; Mon, 20 Mar 2006 20:28:10 -0800 (PST) Received: from snowdog.eng.sun.com (localhost [127.0.0.1]) by snowdog.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2L4SATN007663; Mon, 20 Mar 2006 20:28:10 -0800 (PST) Received: (from dp@localhost) by snowdog.eng.sun.com (8.13.5+Sun/8.13.5/Submit) id k2L4SASE007662; Mon, 20 Mar 2006 20:28:10 -0800 (PST) Date: Mon, 20 Mar 2006 20:28:09 -0800 From: Dan Price Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak In-reply-to: <200603210327.k2L3RAIt908484@jurassic.eng.sun.com> To: Joseph Kowalski Cc: gww@eng.sun.com, psarc@sun.com, bonwick@zion.eng.sun.com, bonwick@eng.sun.com, Rich.Brown@sun.com Message-id: <20060321042809.GB5479@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.1.2.240295 References: <200603210327.k2L3RAIt908484@jurassic.eng.sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 2086 On Mon 20 Mar 2006 at 05:25PM, Joseph Kowalski wrote: > > > From: Gary Winiger > ... > > > CLI: > > > - We want to modify the CLI compatibly throughout the S10U* > > > train (patches, and micro releases if applicable) > > > > > > - We want to be able to incompatibly modify the CLI, if really > > > needed, in the current minor release (Nevada). > > > > In today's terms, this is call Unstable. In the new terms, > > Uncommitted. > > Sorry, I misread this. I see Gary's reading (and conclusion) as correct. > You get exactly one chance to make the incompatable change which is > in Nevada GA. > > I'd like to see a promotion clause: > > S10 - Unstable/Uncommitted > post-S10 - Stable/Committed > > That should give you what is wanted. It may seem like the term Nevada > should show up, but the rules at the S10->Nevada transition are the > S10 rules. I'd rather not set a promotion clause; we didn't (or didn't mean to) propose that in this case, and it seems like the ARC is adding additional burden-- effectively setting a timer which may be impossible for the implementors to meet for any number of reasons. I do appreciate the sentiment of "get it done eventually" but I am leery of the constraint that says "we don't care how good or bad or architecturally complete or incomplete it is, it's now stable." We don't even know what the release date of the current minor release is, do we? Let me restate my position above with a minor addendum: CLI: - We want to modify the CLI compatibly throughout the S10U* train (patches, and micro releases if applicable) - We want to be able to incompatibly modify the CLI, **if really needed** in the current and future minor releases (Nevada and beyond). Note that I'm not advocating that we evolvthe CLI willy nilly. I also note that 'Stable' would situate fsstat at a higher stability level than either mpstat or vmstat. -dp -- Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp From sacadmin Tue Mar 21 10:20:32 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LIKUIQ025511 for ; Tue, 21 Mar 2006 10:20:31 -0800 (PST) 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 k2LIKBsP021841; Wed, 22 Mar 2006 02:20:24 +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 <0IWH00103PLUOQ00@brm-avmta-1.central.sun.com>; Tue, 21 Mar 2006 11:20:18 -0700 (MST) Received: from jurassic.eng.sun.com ([129.146.56.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IWH00L68PLTS160@brm-avmta-1.central.sun.com>; Tue, 21 Mar 2006 11:20:17 -0700 (MST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6.Gamma0+Sun/8.13.5) with SMTP id k2LI88Zm605984; Tue, 21 Mar 2006 10:08:12 -0800 (PST) Date: Tue, 21 Mar 2006 08:06:38 -1000 (HST) From: Joseph Kowalski Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak To: Joseph.Kowalski@eng.sun.com, dp@eng.sun.com Cc: gww@eng.sun.com, psarc@Sun.COM, bonwick@zion.eng.sun.com, bonwick@eng.sun.com, Rich.Brown@Sun.COM Reply-to: Joseph Kowalski Message-id: <200603211808.k2LI88Zm605984@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: 0GtCgqC/nSD8JNlEYB2R5Q== X-PMX-Version: 5.1.2.240295 Status: RO Content-Length: 3298 And my belief is that if you can't get the CLI right in the years before Nevada GA, you will never be satisfied. The possibility for a "better" incompatable tweek will always exist. Sometimes "good enough" is, well, good enough. So yes, this may be an additional burden imposed by the ARC (in your view). I actually believe this is a relaxation being granted your project that we aren't insisting on Stable out of the gate (as has been the case I'd guess with 98+% of the CLIs we've reviewed). Keeping CLIs compatable just ain't that hard. So, I don't want to derail this to force a vote over a "promotion clause". However, I would like to hear the concensus of other ARC members on this issue. - jek3 > Date: Mon, 20 Mar 2006 20:28:09 -0800 > From: Dan Price > To: Joseph Kowalski > Cc: gww@eng.sun.com, psarc@sun.com, bonwick@zion.eng.sun.com, bonwick@eng.sun.com, Rich.Brown@sun.com > Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak > Mime-Version: 1.0 > Content-Disposition: inline > User-Agent: Mutt/1.4.2.1i > > On Mon 20 Mar 2006 at 05:25PM, Joseph Kowalski wrote: > > > > > From: Gary Winiger > > ... > > > > CLI: > > > > - We want to modify the CLI compatibly throughout the S10U* > > > > train (patches, and micro releases if applicable) > > > > > > > > - We want to be able to incompatibly modify the CLI, if really > > > > needed, in the current minor release (Nevada). > > > > > > In today's terms, this is call Unstable. In the new terms, > > > Uncommitted. > > > > Sorry, I misread this. I see Gary's reading (and conclusion) as correct. > > You get exactly one chance to make the incompatable change which is > > in Nevada GA. > > > > I'd like to see a promotion clause: > > > > S10 - Unstable/Uncommitted > > post-S10 - Stable/Committed > > > > That should give you what is wanted. It may seem like the term Nevada > > should show up, but the rules at the S10->Nevada transition are the > > S10 rules. > > I'd rather not set a promotion clause; we didn't (or didn't mean to) > propose that in this case, and it seems like the ARC is adding > additional burden-- effectively setting a timer which may be impossible > for the implementors to meet for any number of reasons. I do appreciate > the sentiment of "get it done eventually" but I am leery of the > constraint that says "we don't care how good or bad or architecturally > complete or incomplete it is, it's now stable." We don't even know what > the release date of the current minor release is, do we? > > Let me restate my position above with a minor addendum: > > CLI: > - We want to modify the CLI compatibly throughout the S10U* > train (patches, and micro releases if applicable) > > - We want to be able to incompatibly modify the CLI, **if really > needed** in the current and future minor releases (Nevada and > beyond). > > Note that I'm not advocating that we evolvthe CLI willy nilly. > > I also note that 'Stable' would situate fsstat at a higher stability > level than either mpstat or vmstat. > > -dp > > -- > Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp From sacadmin Tue Mar 21 11:16:22 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LJGLIQ028652 for ; Tue, 21 Mar 2006 11:16:22 -0800 (PST) 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 k2LJGHkc029492 for <@sunmail1brm.central.sun.com:psarc@sun.com>; Wed, 22 Mar 2006 03:16:20 +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 <0IWH00301S77JH00@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Tue, 21 Mar 2006 12:16:19 -0700 (MST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IWH00LWOS77S380@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Tue, 21 Mar 2006 12:16:19 -0700 (MST) Received: from snowdog.eng.sun.com (snowdog.SFBay.Sun.COM [129.146.228.213]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2LJGIJv018631; Tue, 21 Mar 2006 11:16:18 -0800 (PST) Received: from snowdog.eng.sun.com (localhost [127.0.0.1]) by snowdog.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2LJGIGK008919; Tue, 21 Mar 2006 11:16:18 -0800 (PST) Received: (from dp@localhost) by snowdog.eng.sun.com (8.13.5+Sun/8.13.5/Submit) id k2LJGHDw008918; Tue, 21 Mar 2006 11:16:17 -0800 (PST) Date: Tue, 21 Mar 2006 11:16:17 -0800 From: Dan Price Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak In-reply-to: <200603211808.k2LI88Zm605984@jurassic.eng.sun.com> To: Joseph Kowalski Cc: gww@eng.sun.com, psarc@sun.com, bonwick@zion.eng.sun.com, bonwick@eng.sun.com, Rich.Brown@sun.com Message-id: <20060321191617.GK5479@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.1.2.240295 References: <200603211808.k2LI88Zm605984@jurassic.eng.sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1087 On Tue 21 Mar 2006 at 08:06AM, Joseph Kowalski wrote: > > And my belief is that if you can't get the CLI right in the years before > Nevada GA, you will never be satisfied. The possibility for a "better" > incompatable tweek will always exist. Sometimes "good enough" is, well, > good enough. And sometimes not; for example, we might wish to remove an option from the command in the future. There is precedence for this within the *stat tools; see PSARC/2002/203. > So yes, this may be an additional burden imposed by the ARC (in your view). > I actually believe this is a relaxation being granted your project that we > aren't insisting on Stable out of the gate (as has been the case I'd guess > with 98+% of the CLIs we've reviewed). Keeping CLIs compatable just ain't > that hard. I think it is calling a duck a duck to say that this an additional burden-- PSARC approved the original CLI as 'evolving' without comment. 'Stable' places fsstat's CLI above the original stability. -dp -- Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp From sacadmin Tue Mar 21 11:53:28 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LJrQIQ029969 for ; Tue, 21 Mar 2006 11:53:27 -0800 (PST) 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 k2LJr4Rg021240; Wed, 22 Mar 2006 03:53:23 +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 <0IWH00407TWXUV00@brm-avmta-1.central.sun.com>; Tue, 21 Mar 2006 12:53:21 -0700 (MST) Received: from jurassic.eng.sun.com ([129.146.106.105]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IWH00LEOTWXRZC0@brm-avmta-1.central.sun.com>; Tue, 21 Mar 2006 12:53:21 -0700 (MST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6.Gamma0+Sun/8.13.5) with SMTP id k2LJrFJ3685011; Tue, 21 Mar 2006 11:53:19 -0800 (PST) Date: Tue, 21 Mar 2006 09:51:44 -1000 (HST) From: Joseph Kowalski Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak To: Joseph.Kowalski@eng.sun.com, dp@eng.sun.com Cc: gww@eng.sun.com, psarc@sun.com, bonwick@zion.eng.sun.com, bonwick@eng.sun.com, Rich.Brown@sun.com Reply-to: Joseph Kowalski Message-id: <200603211953.k2LJrFJ3685011@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: 4ZZUVEx7yggd/Jt+t3JPCA== X-PMX-Version: 5.1.2.240295 Status: RO Content-Length: 1283 > From: Dan Price ... > On Tue 21 Mar 2006 at 08:06AM, Joseph Kowalski wrote: > > > > And my belief is that if you can't get the CLI right in the years before > > Nevada GA, you will never be satisfied. The possibility for a "better" > > incompatable tweek will always exist. Sometimes "good enough" is, well, > > good enough. > > And sometimes not; for example, we might wish to remove an option from > the command in the future. There is precedence for this within the > *stat tools; see PSARC/2002/203. > > > So yes, this may be an additional burden imposed by the ARC (in your view). > > I actually believe this is a relaxation being granted your project that we > > aren't insisting on Stable out of the gate (as has been the case I'd guess > > with 98+% of the CLIs we've reviewed). Keeping CLIs compatable just ain't > > that hard. > > I think it is calling a duck a duck to say that this an additional > burden-- PSARC approved the original CLI as 'evolving' without comment. > 'Stable' places fsstat's CLI above the original stability. > > -dp And I think stability is what Solaris is all about and the inability to drop an option is a miniscle gain compared to the gain of stability. Could the rest of the ARC please chime in? - jek3 From sacadmin Tue Mar 21 12:22:53 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LKMqIQ001547 for ; Tue, 21 Mar 2006 12:22:52 -0800 (PST) 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 k2LKMg0W009604; Wed, 22 Mar 2006 04:22:48 +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 <0IWH00603V9V3T00@brm-avmta-1.central.sun.com>; Tue, 21 Mar 2006 13:22:43 -0700 (MST) Received: from phorcys.East.Sun.COM ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IWH00L6CV9URZE0@brm-avmta-1.central.sun.com>; Tue, 21 Mar 2006 13:22:42 -0700 (MST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k2LKMe4f015741; Tue, 21 Mar 2006 15:22:40 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k2LKMefM015738; Tue, 21 Mar 2006 15:22:40 -0500 (EST) Date: Tue, 21 Mar 2006 15:22:40 -0500 From: James Carlson Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak In-reply-to: Joseph Kowalski's message of 21 March 2006 09:51:44 To: Joseph Kowalski Cc: dp@eng.sun.com, gww@eng.sun.com, psarc@sun.com, bonwick@zion.eng.sun.com, bonwick@eng.sun.com, Rich.Brown@sun.com Message-id: <17440.24720.209239.689896@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.2.240295 References: <200603211953.k2LJrFJ3685011@jurassic.eng.sun.com> Status: RO Content-Length: 2117 Joseph Kowalski writes: > > I think it is calling a duck a duck to say that this an additional > > burden-- PSARC approved the original CLI as 'evolving' without comment. > > 'Stable' places fsstat's CLI above the original stability. > > > > -dp > > And I think stability is what Solaris is all about and the inability > to drop an option is a miniscle gain compared to the gain of stability. > > Could the rest of the ARC please chime in? Two comments: first, there's a hair's breadth of difference between Evolving and Stable. Probably even less than that. I see no reason Joe couldn't ask for Evolving on the command line, and no real reason why Dan should worry about Joe's "Stable" request having actually raised anything. For the second bit: With suitably irritating warning, I don't see why fsstat could not ever be as unstable as Dan asks, or even remain unstable indefinitely. It seems like a plausible thing. Not good for Solaris, but plausible. I agree with Joe that it's definitely *not* desirable in a Solaris component, and if there's any way we can preserve that "old" command line option or even just turn it into a no-op (if that were appropriate), that'd be preferable to breaking working applications that get built out of it. That may even be true of Unstable -- having the license to break things doesn't mean you should. Giving the command line options a patch release binding with Unstable classification, and a Minor release binding as Evolving seems like a mostly good answer. If it really is the case that in the next couple of years before Nevada ships we still can't manage to settle on the command line of this utility and there's still a chance of incompatible change, then we either amend this case (if we even remember it then) or file a new fast-track to extend it as Unstable for yet another Minor release. Seems unlikely to me, but ok. -- 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 Tue Mar 21 12:45:13 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LKjDIQ002193 for ; Tue, 21 Mar 2006 12:45:13 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k2LKj3C14622; Tue, 21 Mar 2006 13:45:04 -0700 (MST) 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 <0IWH00709WB20500@brm-avmta-1.central.sun.com>; Tue, 21 Mar 2006 13:45:02 -0700 (MST) Received: from jurassic.eng.sun.com ([129.146.104.45]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IWH00LFTWB1S1F0@brm-avmta-1.central.sun.com>; Tue, 21 Mar 2006 13:45:01 -0700 (MST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6.Gamma0+Sun/8.13.5) with SMTP id k2LKir04727006; Tue, 21 Mar 2006 12:44:59 -0800 (PST) Date: Tue, 21 Mar 2006 10:43:23 -1000 (HST) From: Joseph Kowalski Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak To: Joseph.Kowalski@eng.sun.com, james.d.carlson@sun.com Cc: dp@eng.sun.com, gww@eng.sun.com, psarc@sun.com, bonwick@zion.eng.sun.com, bonwick@eng.sun.com, Rich.Brown@sun.com Reply-to: Joseph Kowalski Message-id: <200603212044.k2LKir04727006@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: P/B7gK0JVBFYrUm4Z1eMfQ== X-PMX-Version: 5.1.2.240295 Status: RO Content-Length: 2779 Well yea, but once I do the rewrite, this ON Evolving would become Stable. I'd rather not repeat the discussion which is why I avoided any reference to Evolving. - jek3 > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Date: Tue, 21 Mar 2006 15:22:40 -0500 > From: James Carlson > To: Joseph Kowalski > Cc: dp@eng.sun.com, gww@eng.sun.com, psarc@sun.com, bonwick@zion.eng.sun.com, bonwick@eng.sun.com, Rich.Brown@sun.com > Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak > > Joseph Kowalski writes: > > > I think it is calling a duck a duck to say that this an additional > > > burden-- PSARC approved the original CLI as 'evolving' without comment. > > > 'Stable' places fsstat's CLI above the original stability. > > > > > > -dp > > > > And I think stability is what Solaris is all about and the inability > > to drop an option is a miniscle gain compared to the gain of stability. > > > > Could the rest of the ARC please chime in? > > Two comments: first, there's a hair's breadth of difference between > Evolving and Stable. Probably even less than that. I see no reason > Joe couldn't ask for Evolving on the command line, and no real reason > why Dan should worry about Joe's "Stable" request having actually > raised anything. > > For the second bit: > > With suitably irritating warning, I don't see why fsstat could not > ever be as unstable as Dan asks, or even remain unstable indefinitely. > It seems like a plausible thing. Not good for Solaris, but plausible. > > I agree with Joe that it's definitely *not* desirable in a Solaris > component, and if there's any way we can preserve that "old" command > line option or even just turn it into a no-op (if that were > appropriate), that'd be preferable to breaking working applications > that get built out of it. That may even be true of Unstable -- having > the license to break things doesn't mean you should. > > Giving the command line options a patch release binding with Unstable > classification, and a Minor release binding as Evolving seems like a > mostly good answer. If it really is the case that in the next couple > of years before Nevada ships we still can't manage to settle on the > command line of this utility and there's still a chance of > incompatible change, then we either amend this case (if we even > remember it then) or file a new fast-track to extend it as Unstable > for yet another Minor release. > > Seems unlikely to me, but ok. > > -- > 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 Tue Mar 21 12:53:24 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LKrOIQ002560 for ; Tue, 21 Mar 2006 12:53:24 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k2LKrNC19530; Tue, 21 Mar 2006 13:53:23 -0700 (MST) 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 <0IWH00709WOWBB00@brm-avmta-1.central.sun.com>; Tue, 21 Mar 2006 13:53:20 -0700 (MST) Received: from phorcys.East.Sun.COM ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IWH00L8GWOVS3F0@brm-avmta-1.central.sun.com>; Tue, 21 Mar 2006 13:53:20 -0700 (MST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k2LKrINv015937; Tue, 21 Mar 2006 15:53:18 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k2LKrI65015934; Tue, 21 Mar 2006 15:53:18 -0500 (EST) Date: Tue, 21 Mar 2006 15:53:18 -0500 From: James Carlson Subject: Re: PSARC/2006/180 fsstat(1m) stability update and interface tweak In-reply-to: Joseph Kowalski's message of 21 March 2006 10:43:23 To: Joseph Kowalski Cc: dp@eng.sun.com, gww@eng.sun.com, psarc@sun.com, bonwick@zion.eng.sun.com, bonwick@eng.sun.com, Rich.Brown@sun.com Message-id: <17440.26558.771625.323412@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.2.240295 References: <200603212044.k2LKir04727006@jurassic.eng.sun.com> Status: RO Content-Length: 912 Joseph Kowalski writes: > Well yea, but once I do the rewrite, this ON Evolving would become Stable. > > I'd rather not repeat the discussion which is why I avoided any reference > to Evolving. Sure. I was just pointing out that you and Dan really weren't far apart on that at all. He was looking at an elevation from the originally-proposed Evolving to your proposal of Stable and objecting to that, but, in fact, the two are more alike than apart. s/Stable/Evolving/ and that concern goes away quietly. ... leaving only the concern about just how many years we think it might take to get that command line near enough right to know that we're not going to delete any more options. -- 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 Mar 24 15:33:53 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2ONXrIQ025335 for ; Fri, 24 Mar 2006 15:33:53 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k2ONXpq25898 for <@sunmail2.sfbay.sun.com:psarc@sun.com>; Fri, 24 Mar 2006 15:33:51 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0IWN00M01O4DDZ00@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Fri, 24 Mar 2006 15:33:49 -0800 (PST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IWN00LR2O4CBK00@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Fri, 24 Mar 2006 15:33:48 -0800 (PST) Received: from snowdog.eng.sun.com (snowdog.SFBay.Sun.COM [129.146.228.213]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2ONXmJv021387; Fri, 24 Mar 2006 15:33:48 -0800 (PST) Received: from snowdog.eng.sun.com (localhost [127.0.0.1]) by snowdog.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2ONXlgG006852; Fri, 24 Mar 2006 15:33:48 -0800 (PST) Received: (from dp@localhost) by snowdog.eng.sun.com (8.13.5+Sun/8.13.5/Submit) id k2ONXl8w006851; Fri, 24 Mar 2006 15:33:47 -0800 (PST) Date: Fri, 24 Mar 2006 15:33:47 -0800 From: Dan Price Subject: PSARC 2006/180 spec update, approval To: psarc@sun.com Cc: rich.brown@sun.com, Jeff Bonwick Message-id: <20060324233347.GM5452@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.1.2.240295 User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 5490 I have updated the spec.txt file as per discussion in the case log and at Wednesday's ARC review. I'll be happy to make additional tweaks if I misrepresented the agreement in any way. I have marked the version below with changebars. This case is now approved. -dp ------------------------------------------------------------------------------- fsstat(1m) stability update and interface tweak Dan Price (dp@eng) Advising: Rich Brown (Rich.Brown@Sun.COM), Jeff Bonwick (bonwick@eng) Introduction ------------ Early feedback on and experience with the fsstat [1] utility has shown that it is in need of further refinements, particularly with respect to non-global Zones [2]. This case seeks to make room in fsstat for future improvements in | Solaris Update releases. Interface Table --------------- | Current Proposed Proposed | Entity Stability (patch) (minor release) | ----------------------------------------------------------------------------- | fsstat(1m) CLI Evolving Unstable Evolving | fsstat(1m) Output Unstable Not an Interface Not an Interface | fsstat(1m) -P Output Unstable Removed Removed* | vopstats_{fstype|fsid} Cons Priv. Cons Priv. Cons Priv. | | * Our intention is that fsstat -P will reappear in a future revision | of this tool, which will be the subject of a future case. (Note that the current fsstat man page in build 35 incorrectly documents the stability of the command. This is being fixed.) Background ---------- The concerns about fsstat raised thus far are listed later in this case. We are *not* asking for architectural feedback on these concerns; rather illustrating that they exist and that the parties involved have acknowledged and discussed them. Due to intense time to market pressure communicated by the ZFS team, fsstat has not undergone the usual long Solaris beta cycle, and will ship in Update 2. The ZFS team has emphasized that the utility of the fsstat command justifies its presence in the product even though we expect its output to change. We believe that this is one of the most important changes to observability in Solaris Nevada, and thus deserves leeway to soak and mature further. After further review from the project team, the ZFS team, and the Zones team, it was decided that we seek PSARC approval to note to customers that this utility may change substantially in a future update release, and to remove the default output of the command so that it can be populated at a later date, as well as to remove the parseable output. We have discovered that we lack sufficient customer feedback to know exactly what "mode" default output should reflect. Proposal -------- Members of the project team, the ZFS team, and the Zones team have cooperated to reach this agreement. This solution represents the best compromise of architectural flexibility and time-to-market needs. - Change the default output of fsstat to print the usage message. Move the current default behavior (an aggregated view by filesystem module name) to a new -F option. | - Alter CLI stability of fsstat in the current patch release (i.e. | Solaris 10 Updates) to Unstable [3] to allow us the flexibility | to incompatibly revise fsstat in the current minor release | (i.e. Nevada). Immediately prior to the release of Solaris | Nevada, the stability will rise to Evolving. - Remove the parseable output of fsstat until we have greater experience with the command. | - Alter the output stability of the human readable output of | fsstat to "Not an Interface." | - Document in that man page that fsstat is not suitable for the construction of higher level software tools at this time (i.e. don't parse its output). The kstats which fsstat consumes are not altered in any way by this case. fsstat(1m) Concerns ------------------- Concerns registered thus far are documented in this section. These are for informational purposes; we don't want to debate them here as we have not yet had time to study them in depth: - The default output is unsuitable in current form for Solaris Zones, since it reveals system-wide activity. While not a security problem, the output is essentially nonsensical for non-global zones. - The zones team has provided the advice that at least for zones, admins are going to want to understand how each mount is behaving; they are less likely to be concerned about UFS vs. ZFS activity levels. - The default output of the command may yield information that is difficult for admins to make sense of (the theory is that most admins do not think in terms of filesystem module type). - A more suitable default output may be to follow the model of prstat, and sort the output by activity. Further study and prototyping are needed. - Use of human-readable numbers (i.e. 1.1M, 2.5K, 9.9G) actually obscures which numbers are big or small. References ---------- [1] PSARC 2006/034 fsstat [2] PSARC 2002/174 Virtualization and Namespace Isolation in Solaris [3] PSARC 2005/185 "Enabling Serendipitous Discovery." Opinion, section 4.3. ------------------------------------------------------------------------------- -- Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp