From sacadmin Mon Mar 27 09:41:13 2006 Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2RHfDIQ014911 for ; Mon, 27 Mar 2006 09:41:13 -0800 (PST) Received: from zion.eng.sun.com (localhost [127.0.0.1]) by zion.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id k2RHfDoV020493; Mon, 27 Mar 2006 09:41:13 -0800 (PST) Received: (from ahl@localhost) by zion.eng.sun.com (8.13.3+Sun/8.13.3/Submit) id k2RHfDcc020492; Mon, 27 Mar 2006 09:41:13 -0800 (PST) Date: Mon, 27 Mar 2006 09:41:13 -0800 From: Adam Leventhal To: psarc@sac.eng.sun.com Cc: bryan.cantrill@sun.com, adam.leventhal@sun.com, dtrace-core@kiowa.eng.sun.com Subject: PSARC 2006/196 DTrace Filesystem Info Provider Message-ID: <20060327174113.GC19662@eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i Status: RO Content-Length: 2131 I'm sponsoring the following case on behalf of Bryan Cantrill and the DTrace team. This case introduces a new Private DTrace provider with Patch binding. As all interfaces are Private and the underlying data sources have been reviewed in 2006/034, this case qualifies for self-review Adam ---8<--- The DTrace fsinfo provider exports probes related to the fsstat(1) command and its implementation in terms of the vopstats_* kstats. Because these kstats are currently classified as Private as per PSARC 2006/034, the fsinfo provider will export its probes with Private/Private/ISA Name stability. (See PSARC 2001/466 for the definition of provider stability.) Due to its Private stability, this provider will not be documented; if the stability of the underlying kstats can be increased to Evolving (and the non-trivial issues surrounding vop-level interface stability that were raised in PSARC 2006/034 can be resolved), the Name stability of the fsinfo provider should be similarly changed and the provider should be fully documented. Further, due to the fsinfo provider's Private stability, this case qualifies for self-review; this case is being filed to create a record of its creation. In terms of the (Private) nomenclature for fsinfo probes: each probe is named after its corresponding field in the vopstats_* kstat, with the leading "n" omitted. For example, when the "nmkdir" field of a vopstats_* kstat is incremented, the fsinfo:::mkdir probe will fire. The probes have two arguments: (1) A pointer to a translated fsinfo_t structure, the definition of which may be found in PSARC 2004/335. (2) An integer, which is non-zero only for probes related to "I/O-related operations" as defined by PSARC 2006/034. For these probes (which include fsinfo:::read, fsinfo:::write and fsinfo:::readdir), the integer is the value by which the corresponding *_bytes field in the vopstat_* kstat will be incremented. Examples of use of the fsinfo provider may be found in the case materials directory. -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl