From sacadmin Mon Jan 23 03:26:55 2006 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0NBQrIQ027890 for ; Mon, 23 Jan 2006 03:26:54 -0800 (PST) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0NBQmoR012607; Mon, 23 Jan 2006 11:26:48 GMT Received: from [192.168.254.1] (localhost [127.0.0.1]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id k0NBQlnp009161; Mon, 23 Jan 2006 11:26:47 GMT Message-ID: <43D4BD77.3020702@sun.com> Date: Mon, 23 Jan 2006 11:26:47 +0000 From: Calum Mackay Organization: Sun Microsystems User-Agent: Mail/News 1.6a1 (X11/20060123) MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com, Rich Brown Subject: 2006/034 fsstat Content-Type: multipart/mixed; boundary="------------040209030306090601080606" Status: RO Content-Length: 21377 This is a multi-part message in MIME format. --------------040209030306090601080606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm sponsoring the following fast-track for Rich Brown. The proposed command's CLI has been approved by UIRB: http://sac.sfbay/Archives/CaseLog/rb/UIRB/2005/756/CLI-Opinion.html and a proposed man page is attached. The timeout is set for Wed 1st Feb. The fast-track seeks a Patch release binding (with the intention to ship in a Solaris 10 Update). cheers, calum. --------------040209030306090601080606 Content-Type: text/plain; name="fast-track.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fast-track.txt" 1) Summary and Motivation In 2003, a Sun Sigma team tasked with producing a pan-SMI strategy for file systems published a document [1] that made several recommendations with regard to storing, accessing, and managing data in a network. Among those recommendations was the creation of new mechanisms and tools to observe the behavior of data servers and their clients. One of the outcomes of that strategy paper was that a development team was tasked with improving the observability of data clients and servers. The team decided that one of its objectives was to provide a general observability tool for file systems that would display statistics for any file system in a consistent but file system independent way. The ZFS team has also expressed interest in this tool and has asked that its priority be raised so that it could be included in an upcoming Solaris 10 update. 2) Overview This fast-track proposes four things: - A general observability tool for file system: fsstat - A new structure for collecting statistics for mounted file systems and file system types: vopstats - A proposed scheme for naming kstats used with vopstats structures - An additional member (v_vsanchor) in the vnode structure used to reference an intermediate bookkeeping structure that references the kstat and vopstats structures. 2.1) fsstat 'fsstat' is a tool that displays kstat data which is collected at the VOP layer on a per mount-point and per filesystem-type basis. 'fsstat' uses existing user-level interfaces such as statvfs(2), sysfs(2), and the kstat library routines to extract data from the kernel. Because the data is collected at the file system independent VOP layer, this tool can be used for all file systems including unbundled Sun-supplied file systems and 3rd party file systems with no additional changes to the system. See Appendix A below for the draft man page for fsstat(1M). 2.2) struct vopstats The kernel changes to support 'fsstat' include a structure made up of kstat_named_t structures. Each vnode operation has at least one associated kstat_named_t structure: n{opname} Keeps count of the number of times this operation has been called. Additionally, I/O-related operations (read, write, readdir) have the following associated kstat_named_t structure: {opname}_bytes Holds the cumulative number of bytes that have been transferred in all calls to this operation. Where "opname" is the name of a vnode operation such as "open", "close", "read", "write", "ioctl", etc. The kstat_named_t structures associated with "read" would then be: nread Number of read calls read_bytes Cumulative bytes transferred for all read calls See Appendix B for a full listing of the vopstats structure. 2.3) Kstat name for vopstats In order to retrieve the vopstats structures, 'fsstat' relies on the kstat(3KSTAT) facility. Optimally, kstat names should be unique for easy retrieval, however, the length of a kstat name is limited to 30 characters plus a NUL character. One of the challenges of this project was to find a naming scheme that relied on existing interfaces and provided consistent naming between the kernel and user levels. There are two cases to consider in terms of kstat naming for vopstats: fstype and mount-point. The fstype is straightforward. Each file system type has a unique entry in the vfssw[] table. That entry contains a unique name (e.g., "ufs", "nfs", "zfs"). That information is available in the kernel as well as in user-space via sysfs(2). Mount-points are more problematic. Using the full path could easily overflow the 30 character limit. The one property that is unique for a mounted file system and is available in a consistent format in both the kernel and at user-level is the fsid. In the kernel, this can be obtained using VFS_STATVFS(). At user-level, it is obtained using statvfs(2). Since we have a unique identifier for FS-types and mount-points, we simply prepend a known string, "vopstats_", to each unique identifier to create a unique kstat name. The following are examples taken from a live test system: Mounted file systems: / ==> fsid = 0x1d80068 ==> vopstats_1d80068 /tmp ==> fsid = 0x49c0002 ==> vopstats_49c0002 /rsbpool/test1 ==> fsid = 0x3f50003 ==> vopstats_3f50003 File system types: ufs ==> vopstats_ufs zfs ==> vopstats_zfs 2.4) New member in struct vnode: struct vopstats_anchor *v_vsanchor The new v_vsanchor member is a pointer to a struct vopstats_anchor structure. This is a bookkeeping structure that includes the vopstats structure which will be updated on every VOP call. 3) Interfaces ________________________________________________________________ | Exported Interface | Classification | Comments | |________________________|___________________|__________________| | fsstat(1M) (CLI) | Evolving | See Appendix A | | | | | | fsstat(1M) (output) | Unstable | See Appendix A | | | | | | struct vopstats | Consolidation | See Appendix B | | | Private | | | | | | | vopstats_{fstype|fsid} | Consolidation | kstat/vopstats | | | Private | naming convention| | | | | | VOPSTATS_STR | Consolidation | vnode.h: #define | | | Private | for kstat naming | | | | prefix: | | | | "vopstats_" | | | | | | v_vsanchor | Consolidation | vnode.h: vnode_t | | | Private | structure member | |________________________|___________________|__________________| 4) References [1] "A Strategy for Storing, Accessing and Managing Data in a Network: Recommendations of the File System Sigma Team" (Morrison, O'Conner, Ross, Weinberg, Wong), November, 2003 http://fs.central/fssg/insight/docs/FSS-plan-v401.pdf Appendix A fsstat(1M) Appendix B struct vopstats Last Updated: 01/20/06 13:13:40 SCCS INFO: @(#) fast-track.txt 1.6@(#) --------------040209030306090601080606 Content-Type: text/x-troff-man; name="fsstat.1m" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fsstat.1m" NAME fsstat - report file system statistics SYNOPSIS fsstat [-{a|f|g|i|n|v}] [-P | {-T u|d}] [fstype|path]... [interval [count]] DESCRIPTION fsstat reports kernel file operation activity by file system type (fstype) or by path, which is converted to a mount-point. The first line of output reports all activity since: - The fs module was loaded (in the case of fstype) - The file system was mounted (in the case of mount-point) Statistics are gathered at the file system independent (vnode interface) layer at both the fstype and the mount-point levels. The output of fsstat is dependent on the mode (option) requested. In the absence of the -P option, all statistic fields are displayed using "smart numbers" which automatically scale the units in a human readable form that fits in a maximum of 5 characters. For example: 100 is displayed as 100 2048 is displayed as 2K 3000000 is displayed as 2.86M The unit modifiers are: K (kilo), M (mega), G (giga), T (tera), and P (peta). During the execution of fsstat, the state of the system can change. If relevant, a state change message is included in the fsstat output in one of the following forms: <> <> After the state change messages are displayed, fsstat continues to display the statistics as directed. If all of the fs-types and mount-points that fsstat was reporting on are no longer available, then fsstat exits. With no operands (fstype or mount-point) specified, fsstat displays statistics for every loaded file system type available on the system. OPTIONS -a Report the activity for kernel attribute operations. The following statistics are reported: getattr Number of file attribute retrieval (getattr) calls setattr Number of file attribute modification (setattr) calls getsec Number of file security attribute retrieval (getsecattr) calls setsec Number of file security attribute modification (getsecattr) calls The entity being reported on (fstype or mount-point) is displayed in the last column. -f Report the full activity for all kernel file operations. Each file operation is listed in the left column. The following statistics are reported for each operation: #ops Number of calls for this operation bytes Average transfer size in bytes (only applies to read, write, readdir) The entity being reported on (fstype or mount-point) is displayed in the first row if the -P option is not used. If the -P option is used, the entity is reported in the last column. -g (Default) Report general file system activity. This display combines similar operations into general categories as follows: new file Number of creation operations: file, directories, and symlinks: create, mkdir, symlink name remov Number of name removal operations: remove, rmdir, unlink name chng Number of name change operations: rename, link, symlink attr get Number of attribute retrieval operations: getattr, access, getsecattr, fid attr set Number of attribute change operations: setattr, setsecattr, space lookup ops Number of object lookup operations: lookup, vget rddir ops Number of readdir operations read ops Number of data read operations read bytes Bytes transferred by read operations write ops Number of data write operations write bytes Bytes transferred by write operations The entity being reported on (fstype or mount-point) is displayed in the last column. -i Reports the activity for kernel I/O operations. The following statistics are reported: read ops Number of read calls read bytes Number of bytes read write ops Number of write calls write bytes Number of bytes written rddir ops Number of readdir calls rddir bytes Number of bytes read by readdir rwlock ops Number of rwlock calls rwulock ops Number of rwunlock calls The entity being reported on (fstype or mount-point) is displayed in the last column. -n Reports the activity for kernel naming operations. The following statistics are reported: lookup Number of lookup calls creat Number of create calls remov Number of remove calls link Number of link calls renam Number of rename calls mkdir Number of mkdir calls rmdir Number of rmdir calls rddir Number of readdir calls symlnk Number of symlink calls rdlnk Number of readlink calls The entity being reported on (fstype or mount-point) is displayed in the last column. -v Reports the activity for calls to the virtual memory operations. The following statistics are reported. map Number of map calls addmap Number of addmap calls delmap Number of delmap calls getpag Number of getpage calls putpag Number of putpage calls pagio Number of pageio calls The entity being reported on (fstype or mount-point) is displayed in the last column. -P Modify the output of each display such that the output is parsable. All fields are in the same order as the requested output would normally be. All numbers are in raw format with no units. All fields are separated by a colon (:). No header is displayed. The entity being reported on (fstype or mount-point) is displayed in the last field. -T u | d Display a time stamp. Specify u for a printed representation of the internal representation of time. See time(2). Specify d for standard date format. See ctime(3C). OPERANDS The following operands are supported: count Display only count reports. fstype Explicitly specify the file system type(s) to be reported. The file system module must be loaded. interval Report once each interval seconds. path Specify the path(s) of the mount-point(s) to be reported. If path is not a mount-point, the mount-point containing path will be determined and displayed in the output. NOTES Options All display options (-a, -f, -g, -i, -n, -v) are mutually exclusive. Entering more than one of these options will result in an error. Operands: fstype & fspath fstype and fspath operands can be interspersed on the command line. Preference is given to fstype which means that if a user wishes to see the statistics for a directory that has the same name as an fstype (e.g, ufs), then the path must be specified unambiguously (e.g., ./ufs). Similarly, in order to disambiguate a file with a numeric name (e.g., "10") from an interval or count operand, the name should be prefixed accordingly (e.g., ./10). Default behavior With no operands specified, fsstat reports the statistics for all configured fstypes. With only interval/count specified, fsstat summarizes the activity for all configured file system types during the 'interval' period 'repeated' count times. Headers When an interval is used, headers repeat after more than 24 lines of statistics have been displayed and the set of lines to be displayed in the current interval have completed. EXAMPLES Example 1: Show general activity for all file system types (default) $ fsstat new name name attr attr lookup rddir read read write write file remov chng retrv chng ops ops ops bytes ops bytes 0 0 0 0 0 0 0 0 0 0 0 specfs 2.08K 186 29 150K 359 471K 7.47K 342K 19.6K 102M 49.8M ufs 0 0 0 0 0 0 0 0 0 0 0 fifofs 0 0 0 0 0 0 0 0 0 0 0 namefs 0 0 0 3.37K 0 3.02K 692 3.97K 0 1.37M 0 proc 0 0 0 0 0 0 0 0 0 0 0 nfs 55 35 0 266 6 338 52 5.01K 5.06K 2.50M 9.38M zfs 89 57 0 14.4K 35 486 8 50.7K 3.40M 76.7M 315M tmpfs 0 0 0 32 0 0 0 0 0 0 0 fd 0 0 0 0 0 0 0 0 0 0 0 mntfs 0 0 0 0 0 0 0 0 0 0 0 devfs 0 0 0 525 0 1.35K 0 0 0 0 0 ctfs 0 0 0 0 0 0 0 0 0 0 0 objfs 0 0 0 0 0 0 0 0 0 0 0 sockfs 0 0 0 0 0 0 0 0 0 0 0 nfsdyn 6 7 2 874 4 1.17K 48 767 261 106K 14.5K nfs3 1 1 1 749 0 2.91K 221 420 46 762K 9.6K nfs4 0 0 0 678 0 653 0 0 0 0 0 autofs Example 2: Show naming activity for ufs, nfs, nfs3, nfs4, tmpfs $ fsstat -n ufs nfs nfs3 nfs4 tmpfs lookup creat remov link renam mkdir rmdir rddir symlnk rdlnk 3.57M 3.10K 586 6 24 115 100 30.2K 5 330K ufs 0 0 0 0 0 0 0 0 0 0 nfs 18.3K 3 5 0 0 0 0 1.03K 2 346 nfs3 535 0 0 0 0 0 0 46 0 4 nfs4 146 24 15 0 0 4 0 4 0 0 tmpfs Example 3: Show the attribute activity for the FS type ufs and the mounted file systems "/" and "/export/home" every 3 seconds for 3 iterations. # fsstat -a ufs / /export/home 3 3 getattr setattr getsec setsec 378K 91.9K 11.8K 0 ufs 367K 82.3K 11.6K 0 / 11.3K 9.6K 198 0 /export/home 4.97K 2.27K 163 0 ufs 3.94K 1.36K 162 0 / 1.03K 927 1 0 /export/home 2.30K 1.06K 73 0 ufs 1.95K 766 71 0 / 361 317 2 0 /export/home 2.33K 1.06K 78 0 ufs 1.64K 451 77 0 / 711 631 1 0 /export/home Example 4: Same command as above, but make the output parsable (-P). $ fsstat -a -P ufs / /export/home 3 3 399989:99987:12450:0:ufs 385958:88008:12248:0:/ 14024:11979:202:0:/export/home 4524:2098:141:0:ufs 3780:1442:140:0:/ 745:656:1:0:/export/home 3689:1686:118:0:ufs 2824:920:117:0:/ 865:766:1:0:/export/home 4032:1829:128:0:ufs 3622:1468:127:0:/ 410:361:1:0:/export/home Example 5: Show the statistics for each file operation for / (-f) $ fsstat -f / Mountpoint: / operation #ops bytes open 8.54K close 9.8K read 43.6K 65.9M write 1.57K 2.99M ioctl 2.06K setfl 4 getattr 40.3K setattr 38 access 9.19K lookup 203K create 595 remove 56 link 0 rename 9 mkdir 19 rmdir 0 readdir 2.02K 2.27M symlink 4 readlink 8.31K fsync 199 inactive 2.96K fid 0 rwlock 47.2K rwunlock 47.2K seek 29.1K cmp 42.9K frlock 4.45K space 8 realvp 3.25K getpage 104K putpage 2.69K map 13.2K addmap 34.4K delmap 33.4K poll 287 dump 0 pathconf 54 pageio 0 dumpctl 0 dispose 23.8K getsecattr 697 setsecattr 0 shrlock 0 vnevent 0 Last Updated: 01/20/06 13:23:41 SCCS INFO: @(#) fsstat.1m 1.7@(#) --------------040209030306090601080606 Content-Type: text/plain; name="vopstats_t.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vopstats_t.txt" typedef struct vopstats { kstat_named_t nopen; /* VOP_OPEN */ kstat_named_t nclose; /* VOP_CLOSE */ kstat_named_t nread; /* VOP_READ */ kstat_named_t read_bytes; kstat_named_t nwrite; /* VOP_WRITE */ kstat_named_t write_bytes; kstat_named_t nioctl; /* VOP_IOCTL */ kstat_named_t nsetfl; /* VOP_SETFL */ kstat_named_t ngetattr; /* VOP_GETATTR */ kstat_named_t nsetattr; /* VOP_SETATTR */ kstat_named_t naccess; /* VOP_ACCESS */ kstat_named_t nlookup; /* VOP_LOOKUP */ kstat_named_t ncreate; /* VOP_CREATE */ kstat_named_t nremove; /* VOP_REMOVE */ kstat_named_t nlink; /* VOP_LINK */ kstat_named_t nrename; /* VOP_RENAME */ kstat_named_t nmkdir; /* VOP_MKDIR */ kstat_named_t nrmdir; /* VOP_RMDIR */ kstat_named_t nreaddir; /* VOP_READDIR */ kstat_named_t readdir_bytes; kstat_named_t nsymlink; /* VOP_SYMLINK */ kstat_named_t nreadlink; /* VOP_READLINK */ kstat_named_t nfsync; /* VOP_FSYNC */ kstat_named_t ninactive; /* VOP_INACTIVE */ kstat_named_t nfid; /* VOP_FID */ kstat_named_t nrwlock; /* VOP_RWLOCK */ kstat_named_t nrwunlock; /* VOP_RWUNLOCK */ kstat_named_t nseek; /* VOP_SEEK */ kstat_named_t ncmp; /* VOP_CMP */ kstat_named_t nfrlock; /* VOP_FRLOCK */ kstat_named_t nspace; /* VOP_SPACE */ kstat_named_t nrealvp; /* VOP_REALVP */ kstat_named_t ngetpage; /* VOP_GETPAGE */ kstat_named_t nputpage; /* VOP_PUTPAGE */ kstat_named_t nmap; /* VOP_MAP */ kstat_named_t naddmap; /* VOP_ADDMAP */ kstat_named_t ndelmap; /* VOP_DELMAP */ kstat_named_t npoll; /* VOP_POLL */ kstat_named_t ndump; /* VOP_DUMP */ kstat_named_t npathconf; /* VOP_PATHCONF */ kstat_named_t npageio; /* VOP_PAGEIO */ kstat_named_t ndumpctl; /* VOP_DUMPCTL */ kstat_named_t ndispose; /* VOP_DISPOSE */ kstat_named_t nsetsecattr; /* VOP_SETSECATTR */ kstat_named_t ngetsecattr; /* VOP_GETSECATTR */ kstat_named_t nshrlock; /* VOP_SHRLOCK */ kstat_named_t nvnevent; /* VOP_VNEVENT */ } vopstats_t; --------------040209030306090601080606-- From sacadmin Mon Jan 23 05:54:33 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0NDsXIQ000479 for ; Mon, 23 Jan 2006 05:54:33 -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 k0NDsXMQ013380; Mon, 23 Jan 2006 08:54:33 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k0NDsXS7013377; Mon, 23 Jan 2006 08:54:33 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17364.57368.927499.337524@gargle.gargle.HOWL> Date: Mon, 23 Jan 2006 08:54:32 -0500 From: James Carlson To: Calum Mackay Cc: psarc@sac.sfbay.sun.com, Rich Brown Subject: Re: 2006/034 fsstat In-Reply-To: Calum Mackay's message of 23 January 2006 11:26:47 References: <43D4BD77.3020702@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1279 Calum Mackay writes: > fsstat [-{a|f|g|i|n|v}] [-P | {-T u|d}] [fstype|path]... [interval [count]] > > The unit modifiers are: K (kilo), M (mega), G (giga), T (tera), > and P (peta). The current du(1M) command (despite its man page) supports those above plus "E" for "exa" (2^60). Shouldn't these things be consistent? (As a bit of a code review nit, it seems to me that it'd be really nice if this logic weren't copied with changes from utility to utility, but were instead implemented in one common place.) (64 bit counters go up to "16E" using this scale.) > -g (Default) Report general file system activity. This display > combines similar operations into general categories > as follows: If this is the default, under what conditions would the user need to specify "-g" explicitly? > typedef struct vopstats { > kstat_named_t nopen; /* VOP_OPEN */ > kstat_named_t nclose; /* VOP_CLOSE */ Missing from this table is an indication of the data type. Are these all KSTAT_DATA_UINT64? -- 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 Mon Jan 23 06:09:17 2006 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0NE9GIQ000599 for ; Mon, 23 Jan 2006 06:09:16 -0800 (PST) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0NE9CoR012636; Mon, 23 Jan 2006 14:09:12 GMT Received: from [192.168.254.1] (localhost [127.0.0.1]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id k0NE9C9u014241; Mon, 23 Jan 2006 14:09:12 GMT Message-ID: <43D4E388.8000708@sun.com> Date: Mon, 23 Jan 2006 14:09:12 +0000 From: Calum Mackay Organization: Sun Microsystems User-Agent: Mail/News 1.6a1 (X11/20060123) MIME-Version: 1.0 To: James Carlson CC: psarc@sac.sfbay.sun.com, Rich Brown Subject: Re: 2006/034 fsstat References: <43D4BD77.3020702@sun.com> <17364.57368.927499.337524@gargle.gargle.HOWL> In-Reply-To: <17364.57368.927499.337524@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 666 thanks for the comments, Jim. I'll let Rich reply, except for: >> -g (Default) Report general file system activity. This display >> combines similar operations into general categories >> as follows: > > If this is the default, under what conditions would the user need to > specify "-g" explicitly? This was added at the request of UIRB. Their opinion notes: One option was added to the specification to cover the default case, for consistency and in order to make it easier to document the mode options for users. Although I wouldn't have thought it was consistent, at least not with most Solaris utils. cheers, c. From sacadmin Mon Jan 23 08:05:50 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0NG5oIQ002618 for ; Mon, 23 Jan 2006 08:05:50 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0NG5oTe028723 for ; Mon, 23 Jan 2006 08:05:50 -0800 (PST) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k0NG5nuf000256 for ; Mon, 23 Jan 2006 09:05:49 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ITJ00E01ZD4EF00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for psarc@sac.sfbay.sun.com; Mon, 23 Jan 2006 09:05:49 -0700 (MST) Received: from [129.147.9.18] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ITJ001R9ZDPWQS1@mail-amer.sun.com> for psarc@sac.sfbay.sun.com; Mon, 23 Jan 2006 09:05:49 -0700 (MST) Date: Mon, 23 Jan 2006 10:05:49 -0600 From: Rich Brown Subject: Re: 2006/034 fsstat In-reply-to: <17364.57368.927499.337524@gargle.gargle.HOWL> Sender: Rich.Brown@Sun.COM To: James Carlson Cc: psarc@sac.sfbay.sun.com, Rich.Brown@Sun.COM Message-id: <43D4FEDD.8070604@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <43D4BD77.3020702@sun.com> <17364.57368.927499.337524@gargle.gargle.HOWL> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) Status: RO Content-Length: 1411 James Carlson wrote: > Calum Mackay writes: > >> fsstat [-{a|f|g|i|n|v}] [-P | {-T u|d}] [fstype|path]... [interval [count]] >> > > > >> The unit modifiers are: K (kilo), M (mega), G (giga), T (tera), >> and P (peta). > > > The current du(1M) command (despite its man page) supports those above > plus "E" for "exa" (2^60). Shouldn't these things be consistent? (As > a bit of a code review nit, it seems to me that it'd be really nice if > this logic weren't copied with changes from utility to utility, but > were instead implemented in one common place.) > > (64 bit counters go up to "16E" using this scale.) Oversight on my part... This will report "E" for exa. Good catch. BTW, libzfs has a zfs_nicenum() function which does this. > >> -g (Default) Report general file system activity. This display >> combines similar operations into general categories >> as follows: > > > If this is the default, under what conditions would the user need to > specify "-g" explicitly? As Calum mentioned, this addition was requested by UIRB. >>typedef struct vopstats { >> kstat_named_t nopen; /* VOP_OPEN */ >> kstat_named_t nclose; /* VOP_CLOSE */ > > > Missing from this table is an indication of the data type. Are these > all KSTAT_DATA_UINT64? > Yes, that's correct. Each of these are initialized as KSTAT_DATA_UINT64. Thanks, Rich From sacadmin Mon Jan 23 08:08:17 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0NG8HIQ002771 for ; Mon, 23 Jan 2006 08:08:17 -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 k0NG8GJc014144; Mon, 23 Jan 2006 11:08:16 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k0NG8GHw014141; Mon, 23 Jan 2006 11:08:16 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17364.65392.757906.438614@gargle.gargle.HOWL> Date: Mon, 23 Jan 2006 11:08:16 -0500 From: James Carlson To: Rich Brown Cc: psarc@sac.sfbay.sun.com Subject: Re: 2006/034 fsstat In-Reply-To: Rich Brown's message of 23 January 2006 10:05:49 References: <43D4BD77.3020702@sun.com> <17364.57368.927499.337524@gargle.gargle.HOWL> <43D4FEDD.8070604@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 584 Rich Brown writes: > BTW, libzfs has a zfs_nicenum() function which does this. I don't think that the function really has much to do with zfs in particular. > > If this is the default, under what conditions would the user need to > > specify "-g" explicitly? > > As Calum mentioned, this addition was requested by UIRB. Very strange, I think. OK, though. -- 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 Mon Jan 23 08:37:38 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0NGbcIQ003593 for ; Mon, 23 Jan 2006 08:37:38 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0NGbbLn028535 for ; Mon, 23 Jan 2006 08:37:37 -0800 (PST) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k0NGbb8u026691 for ; Mon, 23 Jan 2006 09:37:37 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ITK00G010BW9700@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for psarc@sac.sfbay.sun.com; Mon, 23 Jan 2006 09:37:37 -0700 (MST) Received: from [129.147.9.18] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ITK00EFX0UJSEJ1@mail-amer.sun.com> for psarc@sac.sfbay.sun.com; Mon, 23 Jan 2006 09:37:37 -0700 (MST) Date: Mon, 23 Jan 2006 10:37:31 -0600 From: Rich Brown Subject: Re: 2006/034 fsstat In-reply-to: <17364.65392.757906.438614@gargle.gargle.HOWL> Sender: Rich.Brown@Sun.COM To: James Carlson Cc: psarc@sac.sfbay.sun.com Message-id: <43D5064B.4020501@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <43D4BD77.3020702@sun.com> <17364.57368.927499.337524@gargle.gargle.HOWL> <43D4FEDD.8070604@Sun.COM> <17364.65392.757906.438614@gargle.gargle.HOWL> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) Status: RO Content-Length: 330 James Carlson wrote: > Rich Brown writes: > >>BTW, libzfs has a zfs_nicenum() function which does this. > > > I don't think that the function really has much to do with zfs in > particular. Agreed. I found the following CR that references the general issue: 6356629 provide a lib number_to_scaled_string() function Rich From sacadmin Mon Jan 23 14:50:53 2006 Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0NMorIQ024153 for ; Mon, 23 Jan 2006 14:50:53 -0800 (PST) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.5+Sun/8.13.5) with SMTP id k0NMorVZ016491; Mon, 23 Jan 2006 14:50:53 -0800 (PST) Message-Id: <200601232250.k0NMorVZ016491@ivrel.sfbay.sun.com> Date: Mon, 23 Jan 2006 14:50:53 -0800 (PST) From: Glenn Skinner Reply-To: Glenn Skinner Subject: Re: 2006/034 fsstat To: psarc@sac.sfbay.sun.com, Rich.Brown@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: bT9Y4c8X7anYe2gXLFZxIA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Status: RO Content-Length: 1560 Date: Mon, 23 Jan 2006 11:26:47 +0000 From: Calum Mackay Subject: 2006/034 fsstat I'm sponsoring the following fast-track for Rich Brown. The proposed command's CLI has been approved by UIRB: http://sac.sfbay/Archives/CaseLog/rb/UIRB/2005/756/CLI-Opinion.html and a proposed man page is attached. The timeout is set for Wed 1st Feb. The fast-track seeks a Patch release binding (with the intention to ship in a Solaris 10 Update). First, could you place the files that were attached to the original message in the case directory? The case's specification should be accessible without having to dig it out of the mail file. Second, it seems to me that this case is proposing to provide information that I'd expect to be able to access through a DTrace provider (or providers). Have you considered defining a vnodeop (and possibly a vfsop) provider? If you were to do so, then you would have to confront the issue of what stability levels to assign to the providers, which would help resolve the next issue below. Third, it seems that, by making the options to fsstat Evolving, you're implicitly putting pressure on the vnode interface to force it to at least that stability level. Unless I've missed something (and I may well have), the interface doesn't officially yet have that level of stability. But if you were to define a DTrace-style translation from the underlying vnode ops to the statistics that fsstat emits, you would have confronted and resolved this issue. -- Glenn From sacadmin Mon Jan 23 14:54:28 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.55]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0NMsSIQ024847 for ; Mon, 23 Jan 2006 14:54:28 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-72.SFBay.Sun.COM [129.150.12.72]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id k0NMsKOK473640; Mon, 23 Jan 2006 14:54:26 -0800 (PST) Message-Id: <200601232254.k0NMsKOK473640@jurassic.eng.sun.com> Date: Mon, 23 Jan 2006 12:54:13 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/034 fsstat To: james.d.carlson@sun.com, calum.mackay@sun.com Cc: psarc@sac.sfbay.sun.com, Rich.Brown@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 2XEvssr+/fAEg1pb/zQhlQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 838 > From: Calum Mackay ... > > If this is the default, under what conditions would the user need to > > specify "-g" explicitly? > > This was added at the request of UIRB. Their opinion notes: > > > One option was added to the specification to cover the default case, for > consistency and in order to make it easier to document the mode options > for users. > > > Although I wouldn't have thought it was consistent, at least not with > most Solaris utils. > > cheers, > c. Growl,... I strongly disagree with this. Creating "exceptions" isn't in the best interest of usability. How can they justify this as "for consistancy"? Anybody up for a PSARC override of UIRB? (If so, I think we'd need to derail so as to write an opinion to tell UIRB why.) - sigh, maybe its not worth the effort,... - jek3 From sacadmin Mon Jan 23 15:04:28 2006 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0NN4SIQ025246 for ; Mon, 23 Jan 2006 15:04:28 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0NN4MH0013143; Mon, 23 Jan 2006 18:04:22 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k0NN4LJg014243; Mon, 23 Jan 2006 18:04:21 -0500 (EST) Subject: Re: 2006/034 fsstat From: Bill Sommerfeld To: Joseph Kowalski Cc: James.D.Carlson@sun.com, Calum.Mackay@sun.com, psarc@sac.sfbay.sun.com, Rich.Brown@sun.com In-Reply-To: <200601232254.k0NMsKOK473640@jurassic.eng.sun.com> References: <200601232254.k0NMsKOK473640@jurassic.eng.sun.com> Content-Type: text/plain Message-Id: <1138057461.11612.30.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.330 Date: Mon, 23 Jan 2006 18:04:21 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 261 On Mon, 2006-01-23 at 17:54, Joseph Kowalski wrote: > Anybody up for a PSARC override of UIRB? (If so, I think we'd need to > derail so as to write an opinion to tell UIRB why.) I thought UIRB had recently abdicated responsibility for CLI's... - Bill From sacadmin Mon Jan 23 16:54:09 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0O0s8IQ029215 for ; Mon, 23 Jan 2006 16:54:08 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0O0s8Ln012832 for ; Mon, 23 Jan 2006 16:54:08 -0800 (PST) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k0O0s7uf025710 for ; Mon, 23 Jan 2006 17:54:08 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ITK00I01NS88Y00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for psarc@sac.sfbay.sun.com; Mon, 23 Jan 2006 17:54:07 -0700 (MST) Received: from [129.147.9.18] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ITK000RWNU732E1@mail-amer.sun.com>; Mon, 23 Jan 2006 17:54:07 -0700 (MST) Date: Mon, 23 Jan 2006 18:54:07 -0600 From: Rich Brown Subject: Re: 2006/034 fsstat In-reply-to: <200601232250.k0NMorVZ016491@ivrel.sfbay.sun.com> Sender: Rich.Brown@Sun.COM To: Glenn Skinner Cc: psarc@sac.sfbay.sun.com Message-id: <43D57AAF.4010608@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200601232250.k0NMorVZ016491@ivrel.sfbay.sun.com> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) Status: RO Content-Length: 2365 Glenn Skinner wrote: > Date: Mon, 23 Jan 2006 11:26:47 +0000 > From: Calum Mackay > Subject: 2006/034 fsstat > > I'm sponsoring the following fast-track for Rich Brown. > > The proposed command's CLI has been approved by UIRB: > > http://sac.sfbay/Archives/CaseLog/rb/UIRB/2005/756/CLI-Opinion.html > > and a proposed man page is attached. > > The timeout is set for Wed 1st Feb. The fast-track seeks a Patch > release binding (with the intention to ship in a Solaris 10 > Update). > > First, could you place the files that were attached to the original > message in the case directory? The case's specification should be > accessible without having to dig it out of the mail file. Will do. > Second, it seems to me that this case is proposing to provide > information that I'd expect to be able to access through a DTrace > provider (or providers). Have you considered defining a vnodeop (and > possibly a vfsop) provider? If you were to do so, then you would have > to confront the issue of what stability levels to assign to the > providers, which would help resolve the next issue below. A Dtrace solution was considered. A kstat solution has the advantage of providing historical data which was requested by several groups (PTS, NFS). > Third, it seems that, by making the options to fsstat Evolving, you're > implicitly putting pressure on the vnode interface to force it to at > least that stability level. Unless I've missed something (and I may > well have), the interface doesn't officially yet have that level of > stability. But if you were to define a DTrace-style translation from > the underlying vnode ops to the statistics that fsstat emits, you would > have confronted and resolved this issue. I wasn't sure what you meant at first, then I realized that the fsstat.1m man page lists each specific vnode operation. I agree that this puts stability pressure on both the vnode interface and to fsstat unnecessarily. Good catch! The intention of the options (e.g. '-n' for naming, '-i' for I/O) was to provide various views of what was happening on the system, not to expose the individual operations. I'll remove the references to the specific vnode operations in the OPTIONS section of the man page. I'll have that ready tomorrow morning. Thanks Glenn, Rich From sacadmin Mon Jan 23 17:03:00 2006 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0O12xIQ029664 for ; Mon, 23 Jan 2006 17:02:59 -0800 (PST) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0O12toR000092; Tue, 24 Jan 2006 01:02:55 GMT Received: from [192.168.254.1] (localhost [127.0.0.1]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id k0O12s8r016986; Tue, 24 Jan 2006 01:02:54 GMT Message-ID: <43D57CBE.1090509@sun.com> Date: Tue, 24 Jan 2006 01:02:54 +0000 From: Calum Mackay Organization: Sun Microsystems User-Agent: Mail/News 1.6a1 (X11/20060123) MIME-Version: 1.0 To: Glenn Skinner CC: psarc@sac.sfbay.sun.com, Rich.Brown@sun.com Subject: Re: 2006/034 fsstat References: <200601232250.k0NMorVZ016491@ivrel.sfbay.sun.com> In-Reply-To: <200601232250.k0NMorVZ016491@ivrel.sfbay.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 428 Glenn Skinner wrote: > First, could you place the files that were attached to the original > message in the case directory? The case's specification should be > accessible without having to dig it out of the mail file. Apologies, Glenn; I was going to do that at the case's conclusion, but should have done it earlier. The three files are now in: http://sac.sfbay/Archives/CaseLog/arc/PSARC/2006/034/materials/ cheers, c. From sacadmin Mon Jan 23 17:09:20 2006 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0O19JIQ029695 for ; Mon, 23 Jan 2006 17:09:19 -0800 (PST) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0O19DoR002108; Tue, 24 Jan 2006 01:09:13 GMT Received: from [192.168.254.1] (localhost [127.0.0.1]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id k0O19DsG017996; Tue, 24 Jan 2006 01:09:13 GMT Message-ID: <43D57E39.7000504@sun.com> Date: Tue, 24 Jan 2006 01:09:13 +0000 From: Calum Mackay Organization: Sun Microsystems User-Agent: Mail/News 1.6a1 (X11/20060123) MIME-Version: 1.0 To: Bill Sommerfeld CC: Joseph Kowalski , James.D.Carlson@sun.com, psarc@sac.sfbay.sun.com, Rich.Brown@sun.com Subject: Re: 2006/034 fsstat References: <200601232254.k0NMsKOK473640@jurassic.eng.sun.com> <1138057461.11612.30.camel@thunk> In-Reply-To: <1138057461.11612.30.camel@thunk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 483 Bill Sommerfeld wrote: > On Mon, 2006-01-23 at 17:54, Joseph Kowalski wrote: >> Anybody up for a PSARC override of UIRB? (If so, I think we'd need to >> derail so as to write an opinion to tell UIRB why.) > > I thought UIRB had recently abdicated responsibility for CLI's... It didn't seem so, based on our experience of this case, at least. I believe the ZFS case issue was based on resources, if that was your meaning? Perhaps Rich's was small enough to get in :) cheers, c. From sacadmin Mon Jan 23 19:35:32 2006 Received: from phys-eri-2 (phys-eri-2.PRC.Sun.COM [129.158.216.18]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0O3ZVIQ003103 for ; Mon, 23 Jan 2006 19:35:32 -0800 (PST) Received: from conversion-daemon.eri-mail1.prc.sun.com by eri-mail1.prc.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ITK00001V90CX@eri-mail1.prc.sun.com> (original mail from darren.reed@sun.com) for psarc@sac.eng.sun.com; Tue, 24 Jan 2006 11:35:30 +0800 (CST) Received: from [129.158.87.77] (dhcp-mel06-87-77.Aus.Sun.COM [129.158.87.77]) by eri-mail1.prc.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0ITK004WHVB49N@eri-mail1.prc.sun.com>; Tue, 24 Jan 2006 11:35:30 +0800 (CST) Date: Tue, 24 Jan 2006 14:34:08 +1100 From: Darren Reed Subject: Re: 2006/034 fsstat In-reply-to: <43D4BD77.3020702@sun.com> To: Calum Mackay Cc: psarc@sac.eng.sun.com, Rich Brown Message-id: <43D5A030.3050609@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 References: <43D4BD77.3020702@sun.com> Status: RO Content-Length: 1223 Calum Mackay wrote: >... >2) Overview > > This fast-track proposes four things: > > - A general observability tool for file system: fsstat > > - A new structure for collecting statistics for mounted file systems > and file system types: vopstats > > - A proposed scheme for naming kstats used with vopstats structures > > - An additional member (v_vsanchor) in the vnode structure used to > reference an intermediate bookkeeping structure that references > the kstat and vopstats structures. > >2.1) fsstat > > 'fsstat' is a tool that displays kstat data which is collected at > the VOP layer on a per mount-point and per filesystem-type basis. > 'fsstat' uses existing user-level interfaces such as statvfs(2), > sysfs(2), and the kstat library routines to extract data from the > kernel. Because the data is collected at the file system > independent VOP layer, this tool can be used for all file systems > including unbundled Sun-supplied file systems and 3rd party file > systems with no additional changes to the system. > Was there any (internal?) discussion on calling it vfsstat rather than fsstat, which is more in line with what it is actually interfacing with? Darren From sacadmin Mon Jan 23 19:45:46 2006 Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk.SFBay.Sun.COM [129.146.11.21]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0O3jkIQ003235 for ; Mon, 23 Jan 2006 19:45:46 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0O3jjmT023648 for ; Mon, 23 Jan 2006 19:45:45 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k0O3jjSD028254 for ; Mon, 23 Jan 2006 20:45:45 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ITK00C01VNZMO00@mail-amer.sun.com> (original mail from Torrey.McMahon@Sun.COM) for psarc@sac.eng.sun.com; Mon, 23 Jan 2006 20:45:45 -0700 (MST) Received: from [192.168.1.100] ([69.143.25.27]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ITK003ZWVS48R9K@mail-amer.sun.com>; Mon, 23 Jan 2006 20:45:45 -0700 (MST) Date: Mon, 23 Jan 2006 22:45:48 -0500 From: Torrey McMahon Subject: Re: 2006/034 fsstat In-reply-to: <43D5A030.3050609@sun.com> Sender: Torrey.McMahon@Sun.COM To: Darren Reed Cc: Calum Mackay , psarc@sac.eng.sun.com, Rich Brown Message-id: <43D5A2EC.3020906@sun.com> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <43D4BD77.3020702@sun.com> <43D5A030.3050609@sun.com> User-Agent: Thunderbird 1.5 (Windows/20051201) Status: RO Content-Length: 809 Darren Reed wrote: > Calum Mackay wrote: > >> >> >> 2.1) fsstat >> >> 'fsstat' is a tool that displays kstat data which is collected at >> the VOP layer on a per mount-point and per filesystem-type basis. >> 'fsstat' uses existing user-level interfaces such as statvfs(2), >> sysfs(2), and the kstat library routines to extract data from the >> kernel. Because the data is collected at the file system >> independent VOP layer, this tool can be used for all file systems >> including unbundled Sun-supplied file systems and 3rd party file >> systems with no additional changes to the system. >> > > Was there any (internal?) discussion on calling it vfsstat > rather than fsstat, which is more in line with what it is > actually interfacing with? Tell me you're joking Darren. Please. :-) From sacadmin Mon Jan 23 20:13:35 2006 Received: from phys-eri-2 (phys-eri-2.PRC.Sun.COM [129.158.216.18]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0O4DYIQ004144 for ; Mon, 23 Jan 2006 20:13:34 -0800 (PST) Received: from conversion-daemon.eri-mail1.prc.sun.com by eri-mail1.prc.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ITK00101WRT6U@eri-mail1.prc.sun.com> (original mail from darren.reed@sun.com) for psarc@sac.eng.sun.com; Tue, 24 Jan 2006 12:13:32 +0800 (CST) Received: from [129.158.87.77] (dhcp-mel06-87-77.Aus.Sun.COM [129.158.87.77]) by eri-mail1.prc.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0ITK004XGX2I9N@eri-mail1.prc.sun.com>; Tue, 24 Jan 2006 12:13:32 +0800 (CST) Date: Tue, 24 Jan 2006 15:12:10 +1100 From: Darren Reed Subject: Re: 2006/034 fsstat In-reply-to: <43D5A2EC.3020906@sun.com> To: Torrey McMahon Cc: Calum Mackay , psarc@sac.eng.sun.com, Rich Brown Message-id: <43D5A91A.1020202@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 References: <43D4BD77.3020702@sun.com> <43D5A030.3050609@sun.com> <43D5A2EC.3020906@sun.com> Status: RO Content-Length: 1262 Torrey McMahon wrote: > Darren Reed wrote: > >> Calum Mackay wrote: >> >>> >>> >>> 2.1) fsstat >>> >>> 'fsstat' is a tool that displays kstat data which is collected at >>> the VOP layer on a per mount-point and per filesystem-type basis. >>> 'fsstat' uses existing user-level interfaces such as statvfs(2), >>> sysfs(2), and the kstat library routines to extract data from the >>> kernel. Because the data is collected at the file system >>> independent VOP layer, this tool can be used for all file systems >>> including unbundled Sun-supplied file systems and 3rd party file >>> systems with no additional changes to the system. >>> >> >> Was there any (internal?) discussion on calling it vfsstat >> rather than fsstat, which is more in line with what it is >> actually interfacing with? > > > > Tell me you're joking Darren. Please. :-) I read through the docs and thought, "this tool is interfacing primarily with VFS, why isn't it a vfsstat?" Given that it is a trivial issue to some, I'm just curious if the team thought about this at all or if they were content with it being called "fsstat". To whit, if there were a seperate fsstat from vfsstat, I'm not sure what it would do, if anything but I'm curious, all the same. Darren From sacadmin Mon Jan 23 20:22:07 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0O4M7IQ004196 for ; Mon, 23 Jan 2006 20:22:07 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0O4M6Ln009993 for ; Mon, 23 Jan 2006 20:22:06 -0800 (PST) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k0O4M68u008924 for ; Mon, 23 Jan 2006 21:22:06 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ITK00701XEYT600@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for psarc@sac.sfbay.sun.com; Mon, 23 Jan 2006 21:22:06 -0700 (MST) Received: from [129.147.9.18] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ITK001LQXGTWQ02@mail-amer.sun.com>; Mon, 23 Jan 2006 21:22:06 -0700 (MST) Date: Mon, 23 Jan 2006 22:22:05 -0600 From: Rich Brown Subject: Re: 2006/034 fsstat In-reply-to: <43D5A91A.1020202@sun.com> Sender: Rich.Brown@Sun.COM To: Darren Reed Cc: Torrey McMahon , Calum Mackay , psarc@sac.sfbay.sun.com Message-id: <43D5AB6D.9060209@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <43D4BD77.3020702@sun.com> <43D5A030.3050609@sun.com> <43D5A2EC.3020906@sun.com> <43D5A91A.1020202@sun.com> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) Status: RO Content-Length: 1539 Darren Reed wrote: > Torrey McMahon wrote: > >> Darren Reed wrote: >> >>> Calum Mackay wrote: >>> >>>> >>>> >>>> 2.1) fsstat >>>> >>>> 'fsstat' is a tool that displays kstat data which is collected at >>>> the VOP layer on a per mount-point and per filesystem-type basis. >>>> 'fsstat' uses existing user-level interfaces such as statvfs(2), >>>> sysfs(2), and the kstat library routines to extract data from the >>>> kernel. Because the data is collected at the file system >>>> independent VOP layer, this tool can be used for all file systems >>>> including unbundled Sun-supplied file systems and 3rd party file >>>> systems with no additional changes to the system. >>>> >>> >>> Was there any (internal?) discussion on calling it vfsstat >>> rather than fsstat, which is more in line with what it is >>> actually interfacing with? >> >> >> >> >> Tell me you're joking Darren. Please. :-) > > > > I read through the docs and thought, "this tool is interfacing > primarily with VFS, why isn't it a vfsstat?" Given that it is > a trivial issue to some, I'm just curious if the team thought > about this at all or if they were content with it being called > "fsstat". To whit, if there were a seperate fsstat from > vfsstat, I'm not sure what it would do, if anything but I'm > curious, all the same. > > Darren > > Actually, it would be more accurate to call it 'vopstat' or 'fopstat'. ;-) No, up until now, there's never been a suggestion to change the name. It's been 'fsstat' from the beginning. Rich From sacadmin Tue Jan 24 05:02:58 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0OD2wIQ019924 for ; Tue, 24 Jan 2006 05:02:58 -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 k0OD2rDm017047; Tue, 24 Jan 2006 08:02:53 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k0OD2rKq017044; Tue, 24 Jan 2006 08:02:53 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17366.9596.939175.863650@gargle.gargle.HOWL> Date: Tue, 24 Jan 2006 08:02:52 -0500 From: James Carlson To: Calum Mackay Cc: Bill Sommerfeld , Joseph Kowalski , psarc@sac.sfbay.sun.com, Rich.Brown@sun.com, Robert Mori Subject: Re: 2006/034 fsstat In-Reply-To: Calum Mackay's message of 24 January 2006 01:09:13 References: <200601232254.k0NMsKOK473640@jurassic.eng.sun.com> <1138057461.11612.30.camel@thunk> <43D57E39.7000504@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1475 Calum Mackay writes: > Bill Sommerfeld wrote: > > On Mon, 2006-01-23 at 17:54, Joseph Kowalski wrote: > >> Anybody up for a PSARC override of UIRB? (If so, I think we'd need to > >> derail so as to write an opinion to tell UIRB why.) > > > > I thought UIRB had recently abdicated responsibility for CLI's... > > It didn't seem so, based on our experience of this case, at least. I > believe the ZFS case issue was based on resources, if that was your meaning? > > Perhaps Rich's was small enough to get in :) I'm not sure what's going on in this particular case, but back in October I had a conversation with Robert Mori (new UIRB chair) who said that the UIRB decided to delegate all of the command line cases to the ARC because there were just too many of them and they were focusing on graphical interfaces. Still, if this project somehow got a UIRB opinion _despite_ what we understood to be the current policy, I think we should deal with it explicitly rather than just ignoring it. If we have the votes to overrule with a TCR, then we ought to do that. I think the "default option" feature is just unnecessarily ugly cruft, but doesn't rise by itself to the level of demanding a change. But if others do, I'd support removal as a TCR. -- 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 Jan 24 08:04:38 2006 Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0OG4cIQ023256 for ; Tue, 24 Jan 2006 08:04:38 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ITL00G01TMNVD@mpk-mail1.sfbay.sun.com> (original mail from ed.gould@sun.com) for psarc@sac.sfbay.sun.com; Tue, 24 Jan 2006 08:04:38 -0800 (PST) Received: from [192.168.0.10] (vpn-129-150-27-20.SFBay.Sun.COM [129.150.27.20]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0ITL005JYTZ8HL@mpk-mail1.sfbay.sun.com>; Tue, 24 Jan 2006 08:04:21 -0800 (PST) Date: Tue, 24 Jan 2006 08:04:20 -0800 From: Ed Gould Subject: Re: 2006/034 fsstat In-reply-to: <17366.9596.939175.863650@gargle.gargle.HOWL> To: James Carlson Cc: Rich.Brown@Sun.COM, Robert Mori , psarc@sac.sfbay.sun.com, Joseph Kowalski , Calum Mackay , Bill Sommerfeld Message-id: <387a397362c11fe58508071b3cd98281@sun.com> MIME-version: 1.0 (Apple Message framework v623) X-Mailer: Apple Mail (2.623) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200601232254.k0NMsKOK473640@jurassic.eng.sun.com> <1138057461.11612.30.camel@thunk> <43D57E39.7000504@sun.com> <17366.9596.939175.863650@gargle.gargle.HOWL> Status: RO Content-Length: 648 On Jan 24, 2006, at 5:02, James Carlson wrote: > I think the "default option" feature is just unnecessarily ugly cruft, > but doesn't rise by itself to the level of demanding a change. But if > others do, I'd support removal as a TCR. I think it's unnecessary, ugly cruft as well, but I don't quite object to its being there. I've seen this kind of option start to pop up over the past several years, and while I've never understood why, it does seem to be happening. I'd like to get more rationale than just "it's there for consistency" from UIRB before we override them (if we do at all). In particular, Consistency with what? --Ed From sacadmin Tue Jan 24 09:00:34 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0OH0YIQ025261 for ; Tue, 24 Jan 2006 09:00:34 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0OH0YLn019872 for ; Tue, 24 Jan 2006 09:00:34 -0800 (PST) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k0OGunQj021773 for ; Tue, 24 Jan 2006 09:56:49 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ITL00L01VSETP00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 24 Jan 2006 09:56:49 -0700 (MST) Received: from [129.147.9.18] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ITL00JGEWEOPI24@mail-amer.sun.com>; Tue, 24 Jan 2006 09:56:49 -0700 (MST) Date: Tue, 24 Jan 2006 10:56:48 -0600 From: Rich Brown Subject: Re: 2006/034 fsstat In-reply-to: <387a397362c11fe58508071b3cd98281@sun.com> Sender: Rich.Brown@Sun.COM To: psarc@sac.sfbay.sun.com Cc: Robert Mori , Rich.Brown@Sun.COM Message-id: <43D65C50.3060708@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200601232254.k0NMsKOK473640@jurassic.eng.sun.com> <1138057461.11612.30.camel@thunk> <43D57E39.7000504@sun.com> <17366.9596.939175.863650@gargle.gargle.HOWL> <387a397362c11fe58508071b3cd98281@sun.com> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) Status: RO Content-Length: 1229 Ed Gould wrote: > > On Jan 24, 2006, at 5:02, James Carlson wrote: > >> I think the "default option" feature is just unnecessarily ugly cruft, >> but doesn't rise by itself to the level of demanding a change. But if >> others do, I'd support removal as a TCR. > > > I think it's unnecessary, ugly cruft as well, but I don't quite object > to its being there. I've seen this kind of option start to pop up over > the past several years, and while I've never understood why, it does > seem to be happening. > > I'd like to get more rationale than just "it's there for consistency" > from UIRB before we override them (if we do at all). In particular, > Consistency with what? > > --Ed > I spoke with the UIRB sponsor for this. The justification for the '-g' option was clarity in the fsstat(1M) man page. The links to the pre- and post- '-g' option man pages are: http://sac.sfbay.sun.com/Archives/CaseLog/rb/UIRB/2005/756/fsstat.1m_2005.12.21 http://sac.sfbay.sun.com/Archives/CaseLog/rb/UIRB/2005/756/fsstat.1m_2006.01.12 The sponsor is willing to defer to the ARC. If the ARC's general consensus is to change it back, I'll send a formal request to the UIRB and update the man page accordingly. Rich From sacadmin Tue Jan 24 09:21:25 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0OHLPIQ026063 for ; Tue, 24 Jan 2006 09:21:25 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0OHLPLn000936 for ; Tue, 24 Jan 2006 09:21:25 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k0OHLOSD004100 for ; Tue, 24 Jan 2006 10:21:24 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ITL00701XE89J00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 24 Jan 2006 10:21:24 -0700 (MST) Received: from [129.147.9.18] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ITL003QUXJH9062@mail-amer.sun.com> for psarc@sac.sfbay.sun.com; Tue, 24 Jan 2006 10:21:18 -0700 (MST) Date: Tue, 24 Jan 2006 11:21:17 -0600 From: Rich Brown Subject: Re: 2006/034 fsstat In-reply-to: <43D57AAF.4010608@Sun.COM> Sender: Rich.Brown@Sun.COM To: psarc@sac.sfbay.sun.com Cc: Rich Brown Message-id: <43D6620D.1080603@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200601232250.k0NMorVZ016491@ivrel.sfbay.sun.com> <43D57AAF.4010608@Sun.COM> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) Status: RO Content-Length: 5906 Rich Brown wrote: > > Glenn Skinner wrote: > ... >> Third, it seems that, by making the options to fsstat Evolving, you're >> implicitly putting pressure on the vnode interface to force it to at >> least that stability level. Unless I've missed something (and I may >> well have), the interface doesn't officially yet have that level of >> stability. But if you were to define a DTrace-style translation from >> the underlying vnode ops to the statistics that fsstat emits, you would >> have confronted and resolved this issue. > > > I wasn't sure what you meant at first, then I realized that the fsstat.1m > man page lists each specific vnode operation. I agree that this puts > stability pressure on both the vnode interface and to fsstat unnecessarily. > Good catch! > > The intention of the options (e.g. '-n' for naming, '-i' for I/O) was to > provide various views of what was happening on the system, not to expose > the individual operations. I'll remove the references to the specific > vnode operations in the OPTIONS section of the man page. I'll have that > ready tomorrow morning. > > Thanks Glenn, > > Rich > Per Glenn's comment, I've updated the man page to remove references to the specific vnode operations (plus a few corrections). I've included the 'diff's below for your convenience. Calum has added the latest man page (fsstat.1m) to the materials directory. Thanks Calum. Rich Diffs from previous version: ------- fsstat.1m ------- 16,17c16,18 < Statistics are gathered at the file system independent (vnode < interface) layer at both the fstype and the mount-point levels. --- > Statistics are gathered at the file system independent layer at > both the fstype and the mount-point levels. > 28c29 < and P (peta). --- > P (peta), and E (exa). 51c52 < (getattr) calls --- > calls 54c55 < (setattr) calls --- > calls 57c58 < retrieval (getsecattr) calls --- > retrieval calls 60c61 < modification (getsecattr) calls --- > modification calls 82,96c83,93 < new file Number of creation operations: < file, directories, and symlinks: < create, mkdir, symlink < name remov Number of name removal operations: < remove, rmdir, unlink < name chng Number of name change operations: < rename, link, symlink < attr get Number of attribute retrieval < operations: getattr, access, < getsecattr, fid < attr set Number of attribute change < operations: setattr, setsecattr, space < lookup ops Number of object lookup operations: < lookup, vget < rddir ops Number of readdir operations --- > new file Number of creation operations for > file system objects (e.g., files, > directories, symlinks, etc.) > name remov Number of name removal operations > name chng Number of name change operations > attr get Number of object attribute retrieval > operations > attr set Number of object attribute change > operations > lookup ops Number of object lookup operations > rddir ops Number of read directory operations 98c95,96 < read bytes Bytes transferred by read operations --- > read bytes Bytes transferred by data read > operations 100c98,99 < write bytes Bytes transferred by write operations --- > write bytes Bytes transferred by data write > operations 108c107 < read ops Number of read calls --- > read ops Number of data read calls 110c109 < write ops Number of write calls --- > write ops Number of data write calls 112,115c111,117 < rddir ops Number of readdir calls < rddir bytes Number of bytes read by readdir < rwlock ops Number of rwlock calls < rwulock ops Number of rwunlock calls --- > rddir ops Number of read directory calls > rddir bytes Number of bytes read by reading > directories > rwlock ops Number of internal file system > lock operations > rwulock ops Number of internal file system > unlock operations 123,125c125,127 < lookup Number of lookup calls < creat Number of create calls < remov Number of remove calls --- > lookup Number of file name retrieval calls > creat Number of file creation calls > remov Number of file remove calls 127,132c129,134 < renam Number of rename calls < mkdir Number of mkdir calls < rmdir Number of rmdir calls < rddir Number of readdir calls < symlnk Number of symlink calls < rdlnk Number of readlink calls --- > renam Number of file renaming calls > mkdir Number of directory creation calls > rmdir Number of directory removal calls > rddir Number of directory read calls > symlnk Number of symlink creation calls > rdlnk Number of symlink read calls 140,145c142,152 < map Number of map calls < addmap Number of addmap calls < delmap Number of delmap calls < getpag Number of getpage calls < putpag Number of putpage calls < pagio Number of pageio calls --- > map Number of calls mapping a file > addmap Number of calls setting additional > mapping to a mapped file > delmap Number of calls deleting mapping > to a file > getpag Number of calls retrieving a > page of data from a file > putpag Number of calls writing a page > of data to a file > pagio Number of calls to transfer > pages in file system swap files 185,186c192,193 < Operands: fstype & fspath < fstype and fspath operands can be interspersed on the command --- > Operands: fstype & path > fstype and path operands can be interspersed on the command 481 (sr1-ubrm-15)$ From sacadmin Tue Jan 24 09:35:09 2006 Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0OHZ8IQ026380 for ; Tue, 24 Jan 2006 09:35:08 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ITL00401XSZPX@mpk-mail1.sfbay.sun.com> (original mail from ed.gould@sun.com) for psarc@sac.sfbay.sun.com; Tue, 24 Jan 2006 09:35:08 -0800 (PST) Received: from [192.168.0.10] (vpn-129-150-30-105.SFBay.Sun.COM [129.150.30.105]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0ITL00MTRY5YS5@mpk-mail1.sfbay.sun.com>; Tue, 24 Jan 2006 09:34:46 -0800 (PST) Date: Tue, 24 Jan 2006 09:34:46 -0800 From: Ed Gould Subject: Re: 2006/034 fsstat In-reply-to: <43D65C50.3060708@Sun.COM> To: Rich Brown Cc: Robert Mori , psarc@sac.sfbay.sun.com Message-id: <75f932e5c7004e1acc7a0b3ed89395d5@sun.com> MIME-version: 1.0 (Apple Message framework v623) X-Mailer: Apple Mail (2.623) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <200601232254.k0NMsKOK473640@jurassic.eng.sun.com> <1138057461.11612.30.camel@thunk> <43D57E39.7000504@sun.com> <17366.9596.939175.863650@gargle.gargle.HOWL> <387a397362c11fe58508071b3cd98281@sun.com> <43D65C50.3060708@Sun.COM> Status: RO Content-Length: 1070 On Jan 24, 2006, at 8:56, Rich Brown wrote: > I spoke with the UIRB sponsor for this. The justification for > the '-g' option was clarity in the fsstat(1M) man page. The links > to the pre- and post- '-g' option man pages are: > > http://sac.sfbay.sun.com/Archives/CaseLog/rb/UIRB/2005/756/ > fsstat.1m_2005.12.21 > http://sac.sfbay.sun.com/Archives/CaseLog/rb/UIRB/2005/756/ > fsstat.1m_2006.01.12 > > The sponsor is willing to defer to the ARC. If the ARC's general > consensus is to change it back, I'll send a formal request to the > UIRB and update the man page accordingly. I don't see that adding an option, by itself, makes the documentation clearer. In fact, I find it more confusing. The default behavior should be documented in the man page as just that: the default behavior. Options change the default behavior, in the manner described. Having the default behavior described in the context of an "option" is at best misleading, and at worst incorrect. If this is the only reason for having the option, then I would remove it. --Ed From sacadmin Tue Jan 24 10:02:30 2006 Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk.SFBay.Sun.COM [129.146.11.21]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0OI2UIQ028873 for ; Tue, 24 Jan 2006 10:02:30 -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 k0OI2TmT002784; Tue, 24 Jan 2006 10:02:29 -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 k0OI0QdU004565; Tue, 24 Jan 2006 10:00:26 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k0OI0QEW004564; Tue, 24 Jan 2006 10:00:26 -0800 (PST) Date: Tue, 24 Jan 2006 10:00:26 -0800 (PST) From: Gary Winiger Message-Id: <200601241800.k0OI0QEW004564@marduk.eng.sun.com> To: Rich.Brown@sun.com, ed.gould@sun.com Subject: Re: 2006/034 fsstat Cc: Rob.Mori@sun.com, psarc@sac.sfbay.sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 241 > If this is the only reason for having the option, then I would remove > it. Just to understand correctly: % fsstat and % fsstat -g produce the same output. If so, I'd go with the broader occam and remove the duplicity. Gary.. From sacadmin Tue Jan 24 10:30:57 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.166]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0OIUuIQ000390 for ; Tue, 24 Jan 2006 10:30:56 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-72.SFBay.Sun.COM [129.150.12.72]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id k0OIUohI150920; Tue, 24 Jan 2006 10:30:55 -0800 (PST) Message-Id: <200601241830.k0OIUohI150920@jurassic.eng.sun.com> Date: Tue, 24 Jan 2006 08:30:40 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/034 fsstat To: calum.mackay@sun.com, james.d.carlson@sun.com Cc: sommerfeld@sun.com, Joseph.Kowalski@eng.sun.com, psarc@sac.sfbay.sun.com, Rich.Brown@sun.com, Rob.Mori@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ymGhMzjAcv1pfpko3KQKCQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 446 > From: James Carlson ... > I think the "default option" feature is just unnecessarily ugly cruft, > but doesn't rise by itself to the level of demanding a change. But if > others do, I'd support removal as a TCR. I'm just not sure if there is a precedent to address here. If this is a "one time" fly by, I agree its not worth worrying about. Rob, I see you are on the distribution now. What's your take? - jek3 From sacadmin Tue Jan 24 11:29:15 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0OJTEIQ003271 for ; Tue, 24 Jan 2006 11:29:14 -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 k0OJTEif019044; Tue, 24 Jan 2006 14:29:14 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k0OJTE6u019041; Tue, 24 Jan 2006 14:29:14 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17366.32777.980860.415594@gargle.gargle.HOWL> Date: Tue, 24 Jan 2006 14:29:13 -0500 From: James Carlson To: Ed Gould Cc: Rich Brown , Robert Mori , psarc@sac.sfbay.sun.com Subject: Re: 2006/034 fsstat In-Reply-To: Ed Gould's message of 24 January 2006 09:34:46 References: <200601232254.k0NMsKOK473640@jurassic.eng.sun.com> <1138057461.11612.30.camel@thunk> <43D57E39.7000504@sun.com> <17366.9596.939175.863650@gargle.gargle.HOWL> <387a397362c11fe58508071b3cd98281@sun.com> <43D65C50.3060708@Sun.COM> <75f932e5c7004e1acc7a0b3ed89395d5@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1611 Ed Gould writes: > > The sponsor is willing to defer to the ARC. If the ARC's general > > consensus is to change it back, I'll send a formal request to the > > UIRB and update the man page accordingly. > > I don't see that adding an option, by itself, makes the documentation > clearer. In fact, I find it more confusing. The default behavior > should be documented in the man page as just that: the default > behavior. Options change the default behavior, in the manner > described. Having the default behavior described in the context of an > "option" is at best misleading, and at worst incorrect. The mystery deepens. Here's the original UIRB comment: ** crl-7: There is no option for "the default". While there is nothing really wrong with that and is like the other *stat utilities, looking at the man page I think it makes it clearer and cleaner if "the default" were an option, but just one on by default so it doesn't have to be specified. Then the output of the command is described in the same section as the other types. So consistency with other commands doesn't matter, but parallelism in the man page layout does? In any event, I have exchanged email with some UI people, and I hope we can get to the bottom of the two topics here (whether UIRB is back in the CLI game, and if "default" options are now some kind of CLI expectation). -- 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 Jan 24 13:54:29 2006 Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0OLsTIQ012525 for ; Tue, 24 Jan 2006 13:54:29 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ITM001019YWI2@mpk-mail1.sfbay.sun.com> (original mail from Rob.Mori@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 24 Jan 2006 13:54:28 -0800 (PST) Received: from [129.146.11.105] (sr2-umpk-05.SFBay.Sun.COM [129.146.11.105]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0ITM00HQUA6PZU@mpk-mail1.sfbay.sun.com>; Tue, 24 Jan 2006 13:54:26 -0800 (PST) Date: Tue, 24 Jan 2006 13:54:25 -0800 From: Robert Mori Subject: Re: 2006/034 fsstat In-reply-to: <200601241830.k0OIUohI150920@jurassic.eng.sun.com> To: Joseph Kowalski Cc: Calum.Mackay@Sun.COM, James.D.Carlson@Sun.COM, sommerfeld@sun.com, psarc@sac.sfbay.sun.com, Rich.Brown@Sun.COM Reply-to: Rob.Mori@Sun.COM Message-id: <43D6A211.7050004@Sun.COM> MIME-version: 1.0 Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 References: <200601241830.k0OIUohI150920@jurassic.eng.sun.com> Status: RO Content-Length: 2830
Thanks for all the information.  An update on UIRB CLI
reviews:  Recently we have added a UIRB member to
review CLIs. We have also added a member to review
man pages.  These reviews are done individually
by email.  We would welcome additional CLI reviewers.
The Guidelines effort (CLIP Companion) is ready for
review and I believe John Plocher will get us a review
date.  The UIRB always welcomes additional CLI
review feedback.  On the 2006/034 fsstat case, our
CLI reviewer has provided the product team with
a considerable amount of useful feedback, and the
product team is appreciative.  As far as the -g option,
if PSARC asks the team to remove this option, UIRB
will not object.

Thanks again,
Rob

Joseph Kowalski wrote On 01/24/06 10:30,: 
From: James Carlson <james.d.carlson@sun.com>
    
...
  
I think the "default option" feature is just unnecessarily ugly cruft,
but doesn't rise by itself to the level of demanding a change.  But if
others do, I'd support removal as a TCR.
    

I'm just not sure if there is a precedent to address here.  If this is a
"one time" fly by, I agree its not worth worrying about.

Rob, I see you are on the distribution now.  What's your take?

- jek3

--
Rob Mori
User Interface Review Board

Sun Microsystems, Inc.
Menlo Park, California
Phone x89272/+1 650 786 9272
Mobile 650.575.9086
Email Rob.Mori@Sun.COM
From sacadmin Tue Jan 24 14:00:14 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0OM0DIQ012701 for ; Tue, 24 Jan 2006 14:00:14 -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 k0OM0D2X019867; Tue, 24 Jan 2006 17:00:13 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k0OM0AnY019864; Tue, 24 Jan 2006 17:00:10 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17366.41833.495977.235993@gargle.gargle.HOWL> Date: Tue, 24 Jan 2006 17:00:09 -0500 From: James Carlson To: Rob.Mori@Sun.COM Cc: Joseph Kowalski , Calum.Mackay@Sun.COM, sommerfeld@Sun.COM, psarc@sac.sfbay.sun.com, Rich.Brown@Sun.COM Subject: Re: 2006/034 fsstat In-Reply-To: Robert Mori's message of 24 January 2006 13:54:25 References: <200601241830.k0OIUohI150920@jurassic.eng.sun.com> <43D6A211.7050004@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 517 Robert Mori writes: > [...] > product team is appreciative.  As far as the -g option,
> if PSARC asks the team to remove this option, UIRB
> will not object.
That looks clear enough to me. Please do remove it. -- 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 Jan 24 14:08:04 2006 Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0OM84IQ013043 for ; Tue, 24 Jan 2006 14:08:04 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ITM00A01AIMIA@mpk-mail1.sfbay.sun.com> (original mail from ed.gould@sun.com) for psarc@sac.sfbay.sun.com; Tue, 24 Jan 2006 14:08:04 -0800 (PST) Received: from [192.168.0.10] (vpn-129-150-30-105.SFBay.Sun.COM [129.150.30.105]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0ITM00H4IATFZU@mpk-mail1.sfbay.sun.com>; Tue, 24 Jan 2006 14:08:03 -0800 (PST) Date: Tue, 24 Jan 2006 14:08:03 -0800 From: Ed Gould Subject: Re: 2006/034 fsstat In-reply-to: <43D6A211.7050004@Sun.COM> To: Rob.Mori@Sun.COM Cc: Rich.Brown@Sun.COM, psarc@sac.sfbay.sun.com, Joseph Kowalski , Calum.Mackay@Sun.COM, James.D.Carlson@Sun.COM, sommerfeld@sun.com Message-id: MIME-version: 1.0 (Apple Message framework v623) X-Mailer: Apple Mail (2.623) Content-type: text/plain; charset=ISO-8859-1; format=flowed References: <200601241830.k0OIUohI150920@jurassic.eng.sun.com> <43D6A211.7050004@Sun.COM> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sac.sfbay.sun.com id k0OM84IR013044 Status: RO Content-Length: 982 On Jan 24, 2006, at 13:54, Robert Mori wrote: > On the 2006/034 fsstat case, our > CLI reviewer has provided the product team with > a considerable amount of useful feedback, and the > product team is appreciative.  As far as the -g option, > if PSARC asks the team to remove this option, UIRB > will not object. I'm glad to hear that UIRB has no objection to dropping the -g flag in this case, but I'm somewhat more concerned with the general issue. As Jim pointed out, it seems that parallel construction in the man page (misguided, IMHO, as I suggested in an earlier email) is being given precedence over consistency among commands. This strikes me as exactly backwards. Even if the parallel construction in the man page were desirable (but, as I argued in that earlier email, I think it is at best misleading, and at worst simply wrong), I would think that command consistency is more important. Can we come to agreement on the general case, as well? --Ed From sacadmin Tue Jan 24 14:39:40 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0OMdeIQ014462 for ; Tue, 24 Jan 2006 14:39:40 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0OMdeTe027345 for ; Tue, 24 Jan 2006 14:39:40 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k0OMddSD027915 for ; Tue, 24 Jan 2006 15:39:40 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ITM00D01C50EM00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 24 Jan 2006 15:39:39 -0700 (MST) Received: from [129.147.9.18] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ITM00BQFCA2JNUS@mail-amer.sun.com>; Tue, 24 Jan 2006 15:39:39 -0700 (MST) Date: Tue, 24 Jan 2006 16:39:38 -0600 From: Rich Brown Subject: Re: 2006/034 fsstat In-reply-to: <43D6A211.7050004@Sun.COM> Sender: Rich.Brown@Sun.COM To: Rob.Mori@Sun.COM Cc: psarc@sac.sfbay.sun.com, Rich.Brown@Sun.COM Message-id: <43D6ACAA.1030004@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200601241830.k0OIUohI150920@jurassic.eng.sun.com> <43D6A211.7050004@Sun.COM> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) Status: RO Content-Length: 931 Rob, Thanks for the clarification. I certainly do appreciate the feedback from the UIRB on fsstat. The CLI and man page are much better/cleaner because of it. Rich Robert Mori wrote: > > Thanks for all the information. An update on UIRB CLI > reviews: Recently we have added a UIRB member to > review CLIs. We have also added a member to review > man pages. These reviews are done individually > by email. We would welcome additional CLI reviewers. > The Guidelines effort (CLIP Companion) is ready for > review and I believe John Plocher will get us a review > date. The UIRB always welcomes additional CLI > review feedback. On the 2006/034 fsstat case, our > CLI reviewer has provided the product team with > a considerable amount of useful feedback, and the > product team is appreciative. As far as the -g option, > if PSARC asks the team to remove this option, UIRB > will not object. > > Thanks again, > Rob From sacadmin Tue Jan 24 14:41:51 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0OMfoIQ014501 for ; Tue, 24 Jan 2006 14:41:50 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0OMfoTe028377 for ; Tue, 24 Jan 2006 14:41:50 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k0OMfouf005036 for ; Tue, 24 Jan 2006 15:41:50 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ITM00H01CB13H00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 24 Jan 2006 15:41:50 -0700 (MST) Received: from [129.147.9.18] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ITM00BY4CDPJNUS@mail-amer.sun.com>; Tue, 24 Jan 2006 15:41:50 -0700 (MST) Date: Tue, 24 Jan 2006 16:41:49 -0600 From: Rich Brown Subject: Re: 2006/034 fsstat In-reply-to: <17366.41833.495977.235993@gargle.gargle.HOWL> Sender: Rich.Brown@Sun.COM To: psarc@sac.sfbay.sun.com Cc: Rob.Mori@Sun.COM, Rich.Brown@Sun.COM Message-id: <43D6AD2D.3070609@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200601241830.k0OIUohI150920@jurassic.eng.sun.com> <43D6A211.7050004@Sun.COM> <17366.41833.495977.235993@gargle.gargle.HOWL> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) Status: RO Content-Length: 692 It looks like the ARC guidance is to remove the '-g' option. I agree with that decision. If that is not the case, please let me know. Otherwise... I'll update the man page, ask Calum to add it to the materials directory, then send the 'diff's to the PSARC alias. Also, I'll also send an updated man page to the UIRB for their records. Thanks, Rich James Carlson wrote: > Robert Mori writes: > >> > > [...] > >>product team is appreciative.  As far as the -g option,
>>if PSARC asks the team to remove this option, UIRB
>>will not object.
> > > That looks clear enough to me. Please do remove it. > From sacadmin Tue Jan 24 15:34:12 2006 Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0ONYCIQ016694 for ; Tue, 24 Jan 2006 15:34:12 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ITM00101EF59Y@mpk-mail1.sfbay.sun.com> (original mail from Rob.Mori@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 24 Jan 2006 15:34:12 -0800 (PST) Received: from [129.146.11.105] (sr2-umpk-05.SFBay.Sun.COM [129.146.11.105]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0ITM00KQ6EP36V@mpk-mail1.sfbay.sun.com>; Tue, 24 Jan 2006 15:31:52 -0800 (PST) Date: Tue, 24 Jan 2006 15:31:51 -0800 From: Robert Mori Subject: Re: 2006/034 fsstat In-reply-to: To: Ed Gould Cc: Rich.Brown@Sun.COM, psarc@sac.sfbay.sun.com, Joseph Kowalski , Calum.Mackay@Sun.COM, James.D.Carlson@Sun.COM, sommerfeld@sun.com Reply-to: Rob.Mori@Sun.COM Message-id: <43D6B8E7.4040604@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 References: <200601241830.k0OIUohI150920@jurassic.eng.sun.com> <43D6A211.7050004@Sun.COM> Status: RO Content-Length: 1501 If there is a guideline that embodies this case that is not currently reflected in the "clip-companion", then this might be of general use for the CLI development community. Can this be proposed and forwarded to David-John Burrows? Thanks, Rob Ed Gould wrote On 01/24/06 14:08,: > On Jan 24, 2006, at 13:54, Robert Mori wrote: > >> On the 2006/034 fsstat case, our >> CLI reviewer has provided the product team with >> a considerable amount of useful feedback, and the >> product team is appreciative. As far as the -g option, >> if PSARC asks the team to remove this option, UIRB >> will not object. > > > I'm glad to hear that UIRB has no objection to dropping the -g flag in > this case, but I'm somewhat more concerned with the general issue. > > As Jim pointed out, it seems that parallel construction in the man > page (misguided, IMHO, as I suggested in an earlier email) is being > given precedence over consistency among commands. This strikes me as > exactly backwards. Even if the parallel construction in the man page > were desirable (but, as I argued in that earlier email, I think it is > at best misleading, and at worst simply wrong), I would think that > command consistency is more important. > > Can we come to agreement on the general case, as well? > > --Ed > > -- * Rob Mori * User Interface Review Board *Sun Microsystems, Inc.* Menlo Park, California Phone x89272/+1 650 786 9272 Mobile 650.575.9086 Email Rob.Mori@Sun.COM From sacadmin Tue Jan 24 18:32:06 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.37]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0P2W6IQ023661 for ; Tue, 24 Jan 2006 18:32:06 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-72.SFBay.Sun.COM [129.150.12.72]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id k0P2VtM8357482; Tue, 24 Jan 2006 18:32:04 -0800 (PST) Message-Id: <200601250232.k0P2VtM8357482@jurassic.eng.sun.com> Date: Tue, 24 Jan 2006 16:31:48 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/034 fsstat To: Joseph.Kowalski@Sun.COM, Rob.Mori@Sun.COM Cc: Calum.Mackay@Sun.COM, James.D.Carlson@Sun.COM, sommerfeld@Sun.COM, psarc@sac.sfbay.sun.com, Rich.Brown@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LwxhTThZCadhLROHaJbQiA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1017 Rob (and possibly UIRB in general), I've always had trouble with the fact the UIRB reviews are so strongly driven by a single individual. I don't want to reopen that debate. When that individual is working with well established guidelines (like CLIP), this works fine. When it doesn't work is when that individual chooses to invent or propose personal opinion. It *appears* that's what happened here. I'm working on a *minor* update to the CLIP specification. I'm keeping it to removing points of ambiguity and/or poor presentation to keep it non-controversial. I think UIRB members are working on a broader "interpretation" guideline. Either/both are fine, but somewhere the guidelines need to be reviewed by a sizable body of individuals, before they are implemented. And of course, there is tension that PSARC tends to value consistancy while it appears that UIRB values localized optimality. I think this tension is good in many respects, but it stresses the working relationship. - thanks, - jek3 From sacadmin Wed Jan 25 01:30:57 2006 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0P9UvIQ000402 for ; Wed, 25 Jan 2006 01:30:57 -0800 (PST) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0P9UroR014360; Wed, 25 Jan 2006 09:30:53 GMT Received: from [192.168.254.1] (localhost [127.0.0.1]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id k0P9UqNE020042; Wed, 25 Jan 2006 09:30:52 GMT Message-ID: <43D7454C.2090304@sun.com> Date: Wed, 25 Jan 2006 09:30:52 +0000 From: Calum Mackay Organization: Sun Microsystems User-Agent: Mail/News 1.6a1 (X11/20060125) MIME-Version: 1.0 To: Rich Brown CC: psarc@sac.sfbay.sun.com, Rob.Mori@sun.com Subject: Re: 2006/034 fsstat References: <200601241830.k0OIUohI150920@jurassic.eng.sun.com> <43D6A211.7050004@Sun.COM> <17366.41833.495977.235993@gargle.gargle.HOWL> <43D6AD2D.3070609@Sun.COM> In-Reply-To: <43D6AD2D.3070609@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 276 Rich Brown wrote: > It looks like the ARC guidance is to remove the '-g' option. > I agree with that decision. [...] > I'll update the man page, ask Calum to add it to the materials > directory I've added the new man page (sans "-g") to the materials directory. cheers, c. From sacadmin Wed Jan 25 07:01:25 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0PF1PIQ006253 for ; Wed, 25 Jan 2006 07:01:25 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0PF1PLn019880 for ; Wed, 25 Jan 2006 07:01:25 -0800 (PST) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k0PF1O8u026789 for ; Wed, 25 Jan 2006 08:01:24 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ITN00F01LNZK500@mail-amer.sun.com> (original mail from rick.matthews@sun.com) for psarc@sac.sfbay.sun.com; Wed, 25 Jan 2006 08:01:24 -0700 (MST) Received: from sun.com ([129.150.34.151]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ITN00GL2LQB1I20@mail-amer.sun.com> for psarc@sac.sfbay.sun.com; Wed, 25 Jan 2006 08:01:24 -0700 (MST) Date: Wed, 25 Jan 2006 09:02:33 -0600 From: Rick Matthews Subject: Re: 2006/034 fsstat Sender: Richard.Matthews@sun.com To: psarc@sac.sfbay.sun.com Cc: Rich Brown Message-id: <43D79309.4010702@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Status: RO Content-Length: 965 This is more of a PSARC point of order question than a question against the proposal. SAM-QFS, as a Sun unbundled file system, will in the future wish to comply with this proposal. I would guess that a company like Veritas/Symantic would like their file system to comply also once the code has reached Open Solaris. SAM-QFS would need to enter into contracts with ON. Would Veritas also have to through the ARC? Is consolidation private the correct initial stability for these interfaces? -- ---------------------------------------------------------------------------- Rick Matthews phone:+1(651) 554-1518 Sun Microsystems, Inc. email: Rick.Matthews@sun.com 1270 Eagan Industrial Road fax: +1(651) 554-1540 Suite 160 main: +1(651) 554-1500 Eagan, MN 55121-1231 USA ---------------------------------------------------------------------------- From sacadmin Wed Jan 25 07:11:58 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0PFBwIQ006342 for ; Wed, 25 Jan 2006 07:11:58 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0PFBwLn023501 for ; Wed, 25 Jan 2006 07:11:58 -0800 (PST) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k0PFBwuf003110 for ; Wed, 25 Jan 2006 08:11:58 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ITN00201LPYW000@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 25 Jan 2006 08:11:58 -0700 (MST) Received: from [129.147.9.18] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ITN00E0KM7XSD13@mail-amer.sun.com> for psarc@sac.sfbay.sun.com; Wed, 25 Jan 2006 08:11:58 -0700 (MST) Date: Wed, 25 Jan 2006 09:11:57 -0600 From: Rich Brown Subject: Re: 2006/034 fsstat In-reply-to: <43D79309.4010702@sun.com> Sender: Rich.Brown@Sun.COM To: Rick Matthews Cc: psarc@sac.sfbay.sun.com Message-id: <43D7953D.4070703@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <43D79309.4010702@sun.com> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) Status: RO Content-Length: 706 Rick, These changes are implemented at the VOP/VFS level. Unbundled file systems don't need to do anything to participate in this. It will "just work". Rich Rick Matthews wrote: > This is more of a PSARC point of order question than a question against > the proposal. > > SAM-QFS, as a Sun unbundled file system, will in the future wish to comply > with this proposal. I would guess that a company like Veritas/Symantic > would > like their file system to comply also once the code has reached Open > Solaris. > SAM-QFS would need to enter into contracts with ON. Would Veritas also have > to through the ARC? Is consolidation private the correct initial > stability for these > interfaces? > From sacadmin Wed Jan 25 07:17:15 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0PFHFIQ006489 for ; Wed, 25 Jan 2006 07:17:15 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0PFHFLn025058 for ; Wed, 25 Jan 2006 07:17:15 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k0PFHFQj012882 for ; Wed, 25 Jan 2006 08:17:15 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ITN00H01MFSGO00@mail-amer.sun.com> (original mail from Torrey.McMahon@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 25 Jan 2006 08:17:15 -0700 (MST) Received: from [192.168.1.100] ([69.143.25.27]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ITN003B9MGM9084@mail-amer.sun.com> for psarc@sac.sfbay.sun.com; Wed, 25 Jan 2006 08:17:11 -0700 (MST) Date: Wed, 25 Jan 2006 10:17:25 -0500 From: Torrey McMahon Subject: Re: 2006/034 fsstat In-reply-to: <43D79309.4010702@sun.com> Sender: Torrey.McMahon@Sun.COM To: Rick Matthews Cc: psarc@sac.sfbay.sun.com, Rich Brown Message-id: <43D79685.2030806@sun.com> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <43D79309.4010702@sun.com> User-Agent: Thunderbird 1.5 (Windows/20051201) Status: RO Content-Length: 977 Rick Matthews wrote: > This is more of a PSARC point of order question than a question > against the proposal. > > SAM-QFS, as a Sun unbundled file system, will in the future wish to > comply > with this proposal. I would guess that a company like Veritas/Symantic > would > like their file system to comply also once the code has reached Open > Solaris. > SAM-QFS would need to enter into contracts with ON. Would Veritas also > have > to through the ARC? Is consolidation private the correct initial > stability for these > interfaces? > SAM/Q would need a contract given the current stability level. Of course you're welcome to ask the project team to uplevel the interfaces but they don't have to. Veritas, in theory, would need to get a contract. They have in the far reaching past but external software vendors are hard to track down, figure out whom to sign the contract, get them to actually abide by it, etc. External vendors tend to do what they please. From sacadmin Wed Jan 25 07:17:42 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0PFHgIQ006505 for ; Wed, 25 Jan 2006 07:17: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 k0PFHcqE021873; Wed, 25 Jan 2006 10:17:38 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k0PFHcNu021870; Wed, 25 Jan 2006 10:17:38 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17367.38546.385055.646994@gargle.gargle.HOWL> Date: Wed, 25 Jan 2006 10:17:38 -0500 From: James Carlson To: Rick Matthews Cc: psarc@sac.sfbay.sun.com, Rich Brown Subject: Re: 2006/034 fsstat In-Reply-To: Rick Matthews's message of 25 January 2006 09:02:33 References: <43D79309.4010702@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1107 Rick Matthews writes: > SAM-QFS, as a Sun unbundled file system, will in the future wish to comply > with this proposal. I would guess that a company like Veritas/Symantic would > like their file system to comply also once the code has reached Open > Solaris. > SAM-QFS would need to enter into contracts with ON. Would Veritas also have > to through the ARC? Is consolidation private the correct initial > stability for these > interfaces? This is at the VOP level, so nothing should need to be done to those other file systems to make them comply. It should work out of the box. As the original spec said: 2.1) fsstat [...] kernel. Because the data is collected at the file system independent VOP layer, this tool can be used for all file systems including unbundled Sun-supplied file systems and 3rd party file systems with no additional changes to the system. -- 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 Wed Jan 25 07:22:21 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0PFMLIQ006755 for ; Wed, 25 Jan 2006 07:22:21 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0PFMKTe000706 for ; Wed, 25 Jan 2006 07:22:20 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k0PFMJSD015831 for ; Wed, 25 Jan 2006 08:22:20 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ITN00101MJZ4X00@mail-amer.sun.com> (original mail from rick.matthews@sun.com) for psarc@sac.sfbay.sun.com; Wed, 25 Jan 2006 08:22:19 -0700 (MST) Received: from sun.com ([129.150.34.151]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ITN00LOLMP50H40@mail-amer.sun.com> for psarc@sac.sfbay.sun.com; Wed, 25 Jan 2006 08:22:18 -0700 (MST) Date: Wed, 25 Jan 2006 09:23:28 -0600 From: Rick Matthews Subject: Re: 2006/034 fsstat In-reply-to: <17367.38546.385055.646994@gargle.gargle.HOWL> Sender: Richard.Matthews@sun.com To: James Carlson Cc: psarc@sac.sfbay.sun.com, Rich Brown Message-id: <43D797F0.3050500@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <43D79309.4010702@sun.com> <17367.38546.385055.646994@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Status: RO Content-Length: 1577 Rich just pointed that (VFS/vop layer) to me. My mistake. We are going to arrange some testing to verify, but it should just work. Thanks for the reply. -- Rick James Carlson wrote: >Rick Matthews writes: > > >>SAM-QFS, as a Sun unbundled file system, will in the future wish to comply >>with this proposal. I would guess that a company like Veritas/Symantic would >>like their file system to comply also once the code has reached Open >>Solaris. >>SAM-QFS would need to enter into contracts with ON. Would Veritas also have >>to through the ARC? Is consolidation private the correct initial >>stability for these >>interfaces? >> >> > >This is at the VOP level, so nothing should need to be done to those >other file systems to make them comply. It should work out of the >box. As the original spec said: > >2.1) fsstat >[...] > kernel. Because the data is collected at the file system > independent VOP layer, this tool can be used for all file systems > including unbundled Sun-supplied file systems and 3rd party file > systems with no additional changes to the system. > > > -- ---------------------------------------------------------------------------- Rick Matthews phone:+1(651) 554-1518 Sun Microsystems, Inc. email: Rick.Matthews@sun.com 1270 Eagan Industrial Road fax: +1(651) 554-1540 Suite 160 main: +1(651) 554-1500 Eagan, MN 55121-1231 USA ---------------------------------------------------------------------------- From sacadmin Wed Jan 25 07:25:15 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0PFPFIQ006831 for ; Wed, 25 Jan 2006 07:25:15 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0PFPELn028097 for ; Wed, 25 Jan 2006 07:25:15 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k0PFPE8u014252 for ; Wed, 25 Jan 2006 08:25:14 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ITN00101MQLOP00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 25 Jan 2006 08:25:14 -0700 (MST) Received: from [129.147.9.18] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ITN007OWMU2VTNB@mail-amer.sun.com>; Wed, 25 Jan 2006 08:25:14 -0700 (MST) Date: Wed, 25 Jan 2006 09:25:14 -0600 From: Rich Brown Subject: Re: 2006/034 fsstat In-reply-to: <43D7454C.2090304@sun.com> Sender: Rich.Brown@Sun.COM To: psarc@sac.sfbay.sun.com Cc: Rob.Mori@Sun.COM, Rich.Brown@Sun.COM Message-id: <43D7985A.7010003@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200601241830.k0OIUohI150920@jurassic.eng.sun.com> <43D6A211.7050004@Sun.COM> <17366.41833.495977.235993@gargle.gargle.HOWL> <43D6AD2D.3070609@Sun.COM> <43D7454C.2090304@sun.com> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) Status: RO Content-Length: 479 Calum Mackay wrote: > Rich Brown wrote: > >> It looks like the ARC guidance is to remove the '-g' option. >> I agree with that decision. > > [...] > >> I'll update the man page, ask Calum to add it to the materials >> directory > > > I've added the new man page (sans "-g") to the materials directory. > > cheers, > c. > Thanks Calum! The changes should be fairly obvious so I won't send the diffs unless asked. I've also forward the new man page to UIRB. Rich From sacadmin Wed Jan 25 10:15:29 2006 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0PIFSIQ014402 for ; Wed, 25 Jan 2006 10:15:28 -0800 (PST) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0PIFQoR012990; Wed, 25 Jan 2006 18:15:26 GMT Received: from [192.168.254.1] (localhost [127.0.0.1]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id k0PIFPo2009345; Wed, 25 Jan 2006 18:15:25 GMT Message-ID: <43D7C03D.5070906@sun.com> Date: Wed, 25 Jan 2006 18:15:25 +0000 From: Calum Mackay Organization: Sun Microsystems User-Agent: Mail/News 1.6a1 (X11/20060125) MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com, Rich Brown Subject: 2006/034 fsstat References: <43D4BD77.3020702@sun.com> In-Reply-To: <43D4BD77.3020702@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 119 This fast-track was approved at today's PSARC meeting, as per the spec in the case's materials directory. cheers, c. From sacadmin Wed Jan 25 11:45:30 2006 Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0PJjTIQ019479 for ; Wed, 25 Jan 2006 11:45:30 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ITN00C01XHVK5@mpk-mail1.sfbay.sun.com> (original mail from Rob.Mori@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 25 Jan 2006 11:45:29 -0800 (PST) Received: from [129.146.11.105] (sr2-umpk-05.SFBay.Sun.COM [129.146.11.105]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0ITN00J41YV7KD@mpk-mail1.sfbay.sun.com>; Wed, 25 Jan 2006 11:45:10 -0800 (PST) Date: Wed, 25 Jan 2006 11:45:07 -0800 From: Robert Mori Subject: Re: 2006/034 fsstat In-reply-to: <200601250232.k0P2VtM8357482@jurassic.eng.sun.com> To: Joseph Kowalski Cc: Calum.Mackay@Sun.COM, James.D.Carlson@Sun.COM, sommerfeld@Sun.COM, psarc@sac.sfbay.sun.com, Rich.Brown@Sun.COM, UIRB , David Burrowes Reply-to: Rob.Mori@Sun.COM Message-id: <43D7D543.6050106@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 References: <200601250232.k0P2VtM8357482@jurassic.eng.sun.com> Status: RO Content-Length: 2386 I also don't like the fact that we only have 1 CLI reviewer. I like 0 CLI reviewers even less! In this case, our CLI member suggested an addition to an interface that was believed at the time, to provide a benefit. The advice was informal, not a TCR nor a TCA. After PSARC's feedback, the item was withdrawn. As I mentioned before, the engineering team is in a better position after their interaction with UIRB and PSARC. This particular topic, I don't believe appears in any guidelines, and in my previous email, I suggested a guideline be written (by the experts in PSARC.) If you have any specific suggestions on how to improve the process within the operating constraints, we would be very appreciative. On the last point, I disagree that UIRB values optimality over consistency. I see cases where teams are advized to be consistent even though there are better designs available. The UIRB is working well when it advocates for the customer (and sometimes customers want consistency more than efficiency.) I see no philosophical difference between PSARC and UIRB in this regard. Thanks, Rob Joseph Kowalski wrote On 01/24/06 18:31,: >Rob (and possibly UIRB in general), > >I've always had trouble with the fact the UIRB reviews are so strongly >driven by a single individual. I don't want to reopen that debate. When >that individual is working with well established guidelines (like CLIP), >this works fine. When it doesn't work is when that individual chooses >to invent or propose personal opinion. It *appears* that's what happened >here. > >I'm working on a *minor* update to the CLIP specification. I'm keeping >it to removing points of ambiguity and/or poor presentation to keep it >non-controversial. I think UIRB members are working on a broader >"interpretation" guideline. Either/both are fine, but somewhere the >guidelines need to be reviewed by a sizable body of individuals, before >they are implemented. > >And of course, there is tension that PSARC tends to value consistancy >while it appears that UIRB values localized optimality. I think this >tension is good in many respects, but it stresses the working relationship. > >- thanks, > >- jek3 > > > -- * Rob Mori * User Interface Review Board *Sun Microsystems, Inc.* Menlo Park, California Phone x89272/+1 650 786 9272 Mobile 650.575.9086 Email Rob.Mori@Sun.COM From owner-uirb Wed Jan 25 11:45:36 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 k0PJjZIQ019495 for ; Wed, 25 Jan 2006 11:45:35 -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 k0PJjYW18861; Wed, 25 Jan 2006 11:45:34 -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 <0ITN0072FYVUCZ00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jan 2006 11:45:30 -0800 (PST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0ITN00FPCYVTLK60@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jan 2006 11:45:30 -0800 (PST) Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0PJjTTe019378; Wed, 25 Jan 2006 11:45:29 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ITN00C01XHVK5@mpk-mail1.sfbay.sun.com> (original mail from Rob.Mori@Sun.COM); Wed, 25 Jan 2006 11:45:29 -0800 (PST) Received: from [129.146.11.105] (sr2-umpk-05.SFBay.Sun.COM [129.146.11.105]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0ITN00J41YV7KD@mpk-mail1.sfbay.sun.com>; Wed, 25 Jan 2006 11:45:10 -0800 (PST) Date: Wed, 25 Jan 2006 11:45:07 -0800 From: Robert Mori Subject: Re: 2006/034 fsstat In-reply-to: <200601250232.k0P2VtM8357482@jurassic.eng.sun.com> To: Joseph Kowalski Cc: Calum.Mackay@Sun.COM, James.D.Carlson@Sun.COM, sommerfeld@Sun.COM, psarc@sac.sfbay.sun.com, Rich.Brown@Sun.COM, UIRB , David Burrowes Reply-to: Rob.Mori@Sun.COM Message-id: <43D7D543.6050106@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.1.1.222179 References: <200601250232.k0P2VtM8357482@jurassic.eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 Status: RO Content-Length: 2386 I also don't like the fact that we only have 1 CLI reviewer. I like 0 CLI reviewers even less! In this case, our CLI member suggested an addition to an interface that was believed at the time, to provide a benefit. The advice was informal, not a TCR nor a TCA. After PSARC's feedback, the item was withdrawn. As I mentioned before, the engineering team is in a better position after their interaction with UIRB and PSARC. This particular topic, I don't believe appears in any guidelines, and in my previous email, I suggested a guideline be written (by the experts in PSARC.) If you have any specific suggestions on how to improve the process within the operating constraints, we would be very appreciative. On the last point, I disagree that UIRB values optimality over consistency. I see cases where teams are advized to be consistent even though there are better designs available. The UIRB is working well when it advocates for the customer (and sometimes customers want consistency more than efficiency.) I see no philosophical difference between PSARC and UIRB in this regard. Thanks, Rob Joseph Kowalski wrote On 01/24/06 18:31,: >Rob (and possibly UIRB in general), > >I've always had trouble with the fact the UIRB reviews are so strongly >driven by a single individual. I don't want to reopen that debate. When >that individual is working with well established guidelines (like CLIP), >this works fine. When it doesn't work is when that individual chooses >to invent or propose personal opinion. It *appears* that's what happened >here. > >I'm working on a *minor* update to the CLIP specification. I'm keeping >it to removing points of ambiguity and/or poor presentation to keep it >non-controversial. I think UIRB members are working on a broader >"interpretation" guideline. Either/both are fine, but somewhere the >guidelines need to be reviewed by a sizable body of individuals, before >they are implemented. > >And of course, there is tension that PSARC tends to value consistancy >while it appears that UIRB values localized optimality. I think this >tension is good in many respects, but it stresses the working relationship. > >- thanks, > >- jek3 > > > -- * Rob Mori * User Interface Review Board *Sun Microsystems, Inc.* Menlo Park, California Phone x89272/+1 650 786 9272 Mobile 650.575.9086 Email Rob.Mori@Sun.COM From sacadmin Wed Jan 25 15:57:13 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0PNvDIQ026917 for ; Wed, 25 Jan 2006 15:57:13 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0PNvCLn001336 for ; Wed, 25 Jan 2006 15:57:12 -0800 (PST) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k0PNvBQj006820 for ; Wed, 25 Jan 2006 16:57:12 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ITO00G01AFM1600@mail-amer.sun.com> (original mail from David-John.Burrowes@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 25 Jan 2006 16:57:11 -0700 (MST) Received: from 129.146.56.81 ([129.146.56.81]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ITO00DWAAJBTL50@mail-amer.sun.com>; Wed, 25 Jan 2006 16:57:11 -0700 (MST) Date: Wed, 25 Jan 2006 15:57:10 -0800 From: David Burrowes Subject: Re: 2006/034 fsstat In-reply-to: <43D7D543.6050106@Sun.COM> Sender: David-John.Burrowes@Sun.COM To: Rob.Mori@Sun.COM Cc: Joseph Kowalski , Calum.Mackay@Sun.COM, James.D.Carlson@Sun.COM, sommerfeld@Sun.COM, psarc@sac.sfbay.sun.com, Rich.Brown@Sun.COM, UIRB Reply-to: David-John.Burrowes@Sun.COM Message-id: <1138233430.4272.5.camel@natob> Organization: Sun Microsystems Inc. MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Content-type: text/plain Content-transfer-encoding: 7BIT References: <200601250232.k0P2VtM8357482@jurassic.eng.sun.com> <43D7D543.6050106@Sun.COM> Status: RO Content-Length: 2947 I assume that there are going to be other situations like this in the CLI space where ARC and UIRB have different views of what is "good". Can we use something like the cli-guidelines alias as a place to bring these differences to directly so they can be discussed and (if appropriate) the results can be put into the pipeline for a revision to the clip companion? david On Wed, 2006-01-25 at 11:45, Robert Mori wrote: > I also don't like the fact that we only have 1 CLI reviewer. > I like 0 CLI reviewers even less! > > In this case, our CLI member suggested an addition to > an interface that was believed at the time, to provide > a benefit. The advice was informal, not a TCR nor > a TCA. After PSARC's feedback, the item was withdrawn. > As I mentioned before, the engineering team is in > a better position after their interaction with UIRB and PSARC. > This particular topic, I don't believe appears in any > guidelines, and in my previous email, I suggested > a guideline be written (by the experts in PSARC.) > > If you have any specific suggestions on how to improve > the process within the operating constraints, we would > be very appreciative. > > On the last point, > I disagree that UIRB values optimality over consistency. > I see cases where teams are advized to be consistent > even though there are better designs available. The > UIRB is working well when it advocates for the customer > (and sometimes customers want consistency more than > efficiency.) I see no philosophical difference between > PSARC and UIRB in this regard. > > Thanks, > Rob > > Joseph Kowalski wrote On 01/24/06 18:31,: > > >Rob (and possibly UIRB in general), > > > >I've always had trouble with the fact the UIRB reviews are so strongly > >driven by a single individual. I don't want to reopen that debate. When > >that individual is working with well established guidelines (like CLIP), > >this works fine. When it doesn't work is when that individual chooses > >to invent or propose personal opinion. It *appears* that's what happened > >here. > > > >I'm working on a *minor* update to the CLIP specification. I'm keeping > >it to removing points of ambiguity and/or poor presentation to keep it > >non-controversial. I think UIRB members are working on a broader > >"interpretation" guideline. Either/both are fine, but somewhere the > >guidelines need to be reviewed by a sizable body of individuals, before > >they are implemented. > > > >And of course, there is tension that PSARC tends to value consistancy > >while it appears that UIRB values localized optimality. I think this > >tension is good in many respects, but it stresses the working relationship. > > > >- thanks, > > > >- jek3 > > > > > > > > -- > * Rob Mori * > User Interface Review Board > > *Sun Microsystems, Inc.* > Menlo Park, California > Phone x89272/+1 650 786 9272 > Mobile 650.575.9086 > Email Rob.Mori@Sun.COM > > From owner-uirb Wed Jan 25 15:57:26 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 k0PNvPIQ026934 for ; Wed, 25 Jan 2006 15:57:26 -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 k0PNv7CT023198; Thu, 26 Jan 2006 07:57:16 +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 <0ITO00G03AJDXY00@brm-avmta-1.central.sun.com>; Wed, 25 Jan 2006 16:57:13 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0ITO00A24AJDCXD0@brm-avmta-1.central.sun.com>; Wed, 25 Jan 2006 16:57:13 -0700 (MST) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k0PNvBSD010147; Wed, 25 Jan 2006 16:57:12 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ITO00G01AFM1600@mail-amer.sun.com> (original mail from David-John.Burrowes@Sun.COM); Wed, 25 Jan 2006 16:57:11 -0700 (MST) Received: from 129.146.56.81 ([129.146.56.81]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ITO00DWAAJBTL50@mail-amer.sun.com>; Wed, 25 Jan 2006 16:57:11 -0700 (MST) Date: Wed, 25 Jan 2006 15:57:10 -0800 From: David Burrowes Subject: Re: 2006/034 fsstat In-reply-to: <43D7D543.6050106@Sun.COM> Sender: david-john.burrowes@sun.com To: Rob.Mori@sun.com Cc: Joseph Kowalski , Calum.Mackay@sun.com, James.D.Carlson@sun.com, sommerfeld@sun.com, psarc@sac.sfbay.sun.com, Rich.Brown@sun.com, UIRB Reply-to: david-john.burrowes@sun.com Message-id: <1138233430.4272.5.camel@natob> Organization: Sun Microsystems Inc. MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.1.222179 References: <200601250232.k0P2VtM8357482@jurassic.eng.sun.com> <43D7D543.6050106@Sun.COM> Status: RO Content-Length: 2947 I assume that there are going to be other situations like this in the CLI space where ARC and UIRB have different views of what is "good". Can we use something like the cli-guidelines alias as a place to bring these differences to directly so they can be discussed and (if appropriate) the results can be put into the pipeline for a revision to the clip companion? david On Wed, 2006-01-25 at 11:45, Robert Mori wrote: > I also don't like the fact that we only have 1 CLI reviewer. > I like 0 CLI reviewers even less! > > In this case, our CLI member suggested an addition to > an interface that was believed at the time, to provide > a benefit. The advice was informal, not a TCR nor > a TCA. After PSARC's feedback, the item was withdrawn. > As I mentioned before, the engineering team is in > a better position after their interaction with UIRB and PSARC. > This particular topic, I don't believe appears in any > guidelines, and in my previous email, I suggested > a guideline be written (by the experts in PSARC.) > > If you have any specific suggestions on how to improve > the process within the operating constraints, we would > be very appreciative. > > On the last point, > I disagree that UIRB values optimality over consistency. > I see cases where teams are advized to be consistent > even though there are better designs available. The > UIRB is working well when it advocates for the customer > (and sometimes customers want consistency more than > efficiency.) I see no philosophical difference between > PSARC and UIRB in this regard. > > Thanks, > Rob > > Joseph Kowalski wrote On 01/24/06 18:31,: > > >Rob (and possibly UIRB in general), > > > >I've always had trouble with the fact the UIRB reviews are so strongly > >driven by a single individual. I don't want to reopen that debate. When > >that individual is working with well established guidelines (like CLIP), > >this works fine. When it doesn't work is when that individual chooses > >to invent or propose personal opinion. It *appears* that's what happened > >here. > > > >I'm working on a *minor* update to the CLIP specification. I'm keeping > >it to removing points of ambiguity and/or poor presentation to keep it > >non-controversial. I think UIRB members are working on a broader > >"interpretation" guideline. Either/both are fine, but somewhere the > >guidelines need to be reviewed by a sizable body of individuals, before > >they are implemented. > > > >And of course, there is tension that PSARC tends to value consistancy > >while it appears that UIRB values localized optimality. I think this > >tension is good in many respects, but it stresses the working relationship. > > > >- thanks, > > > >- jek3 > > > > > > > > -- > * Rob Mori * > User Interface Review Board > > *Sun Microsystems, Inc.* > Menlo Park, California > Phone x89272/+1 650 786 9272 > Mobile 650.575.9086 > Email Rob.Mori@Sun.COM > > From sacadmin Wed Jan 25 17:58:46 2006 Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0Q1wkIQ000816 for ; Wed, 25 Jan 2006 17:58:46 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ITO00701FWTD4@mpk-mail1.sfbay.sun.com> (original mail from Rob.Mori@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 25 Jan 2006 17:58:46 -0800 (PST) Received: from [129.146.11.105] (sr2-umpk-05.SFBay.Sun.COM [129.146.11.105]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0ITO004ZOG5XT5@mpk-mail1.sfbay.sun.com>; Wed, 25 Jan 2006 17:58:45 -0800 (PST) Date: Wed, 25 Jan 2006 17:58:45 -0800 From: Robert Mori Subject: Re: 2006/034 fsstat In-reply-to: <1138233430.4272.5.camel@natob> To: David-John.Burrowes@Sun.COM Cc: Joseph Kowalski , Calum.Mackay@Sun.COM, James.D.Carlson@Sun.COM, sommerfeld@sun.com, psarc@sac.sfbay.sun.com, Rich.Brown@Sun.COM, UIRB Reply-to: Rob.Mori@Sun.COM Message-id: <43D82CD5.2050701@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 References: <200601250232.k0P2VtM8357482@jurassic.eng.sun.com> <43D7D543.6050106@Sun.COM> <1138233430.4272.5.camel@natob> Status: RO Content-Length: 3302 I'm all for sharing knowledge within the design community -- Rob David Burrowes wrote On 01/25/06 15:57,: >I assume that there are going to be other situations like this in the >CLI space where ARC and UIRB have different views of what is "good". >Can we use something like the cli-guidelines alias as a place to bring >these differences to directly so they can be discussed and (if >appropriate) the results can be put into the pipeline for a revision to >the clip companion? > >david > > >On Wed, 2006-01-25 at 11:45, Robert Mori wrote: > > >>I also don't like the fact that we only have 1 CLI reviewer. >>I like 0 CLI reviewers even less! >> >>In this case, our CLI member suggested an addition to >>an interface that was believed at the time, to provide >>a benefit. The advice was informal, not a TCR nor >>a TCA. After PSARC's feedback, the item was withdrawn. >>As I mentioned before, the engineering team is in >>a better position after their interaction with UIRB and PSARC. >>This particular topic, I don't believe appears in any >>guidelines, and in my previous email, I suggested >>a guideline be written (by the experts in PSARC.) >> >>If you have any specific suggestions on how to improve >>the process within the operating constraints, we would >>be very appreciative. >> >>On the last point, >>I disagree that UIRB values optimality over consistency. >>I see cases where teams are advized to be consistent >>even though there are better designs available. The >>UIRB is working well when it advocates for the customer >>(and sometimes customers want consistency more than >>efficiency.) I see no philosophical difference between >>PSARC and UIRB in this regard. >> >>Thanks, >>Rob >> >>Joseph Kowalski wrote On 01/24/06 18:31,: >> >> >> >>>Rob (and possibly UIRB in general), >>> >>>I've always had trouble with the fact the UIRB reviews are so strongly >>>driven by a single individual. I don't want to reopen that debate. When >>>that individual is working with well established guidelines (like CLIP), >>>this works fine. When it doesn't work is when that individual chooses >>>to invent or propose personal opinion. It *appears* that's what happened >>>here. >>> >>>I'm working on a *minor* update to the CLIP specification. I'm keeping >>>it to removing points of ambiguity and/or poor presentation to keep it >>>non-controversial. I think UIRB members are working on a broader >>>"interpretation" guideline. Either/both are fine, but somewhere the >>>guidelines need to be reviewed by a sizable body of individuals, before >>>they are implemented. >>> >>>And of course, there is tension that PSARC tends to value consistancy >>>while it appears that UIRB values localized optimality. I think this >>>tension is good in many respects, but it stresses the working relationship. >>> >>>- thanks, >>> >>>- jek3 >>> >>> >>> >>> >>> >>-- >> * Rob Mori * >>User Interface Review Board >> >>*Sun Microsystems, Inc.* >>Menlo Park, California >>Phone x89272/+1 650 786 9272 >>Mobile 650.575.9086 >>Email Rob.Mori@Sun.COM >> >> >> >> > > > -- * Rob Mori * User Interface Review Board *Sun Microsystems, Inc.* Menlo Park, California Phone x89272/+1 650 786 9272 Mobile 650.575.9086 Email Rob.Mori@Sun.COM From owner-uirb Wed Jan 25 17:58: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 k0Q1wqIQ000832 for ; Wed, 25 Jan 2006 17:58: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 k0Q1whRu023342; Thu, 26 Jan 2006 09:58: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 <0ITO00D03G5YOZ00@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jan 2006 17:58:46 -0800 (PST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0ITO006XYG5Y23A0@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jan 2006 17:58:46 -0800 (PST) Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0Q1wkTe017224; Wed, 25 Jan 2006 17:58:46 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ITO00701FWTD4@mpk-mail1.sfbay.sun.com> (original mail from Rob.Mori@Sun.COM); Wed, 25 Jan 2006 17:58:46 -0800 (PST) Received: from [129.146.11.105] (sr2-umpk-05.SFBay.Sun.COM [129.146.11.105]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0ITO004ZOG5XT5@mpk-mail1.sfbay.sun.com>; Wed, 25 Jan 2006 17:58:45 -0800 (PST) Date: Wed, 25 Jan 2006 17:58:45 -0800 From: Robert Mori Subject: Re: 2006/034 fsstat In-reply-to: <1138233430.4272.5.camel@natob> To: David-John.Burrowes@sun.com Cc: Joseph Kowalski , Calum.Mackay@sun.com, James.D.Carlson@sun.com, sommerfeld@sun.com, psarc@sac.sfbay.sun.com, Rich.Brown@sun.com, UIRB Reply-to: Rob.Mori@sun.com Message-id: <43D82CD5.2050701@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.1.1.222179 References: <200601250232.k0P2VtM8357482@jurassic.eng.sun.com> <43D7D543.6050106@Sun.COM> <1138233430.4272.5.camel@natob> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 Status: RO Content-Length: 3302 I'm all for sharing knowledge within the design community -- Rob David Burrowes wrote On 01/25/06 15:57,: >I assume that there are going to be other situations like this in the >CLI space where ARC and UIRB have different views of what is "good". >Can we use something like the cli-guidelines alias as a place to bring >these differences to directly so they can be discussed and (if >appropriate) the results can be put into the pipeline for a revision to >the clip companion? > >david > > >On Wed, 2006-01-25 at 11:45, Robert Mori wrote: > > >>I also don't like the fact that we only have 1 CLI reviewer. >>I like 0 CLI reviewers even less! >> >>In this case, our CLI member suggested an addition to >>an interface that was believed at the time, to provide >>a benefit. The advice was informal, not a TCR nor >>a TCA. After PSARC's feedback, the item was withdrawn. >>As I mentioned before, the engineering team is in >>a better position after their interaction with UIRB and PSARC. >>This particular topic, I don't believe appears in any >>guidelines, and in my previous email, I suggested >>a guideline be written (by the experts in PSARC.) >> >>If you have any specific suggestions on how to improve >>the process within the operating constraints, we would >>be very appreciative. >> >>On the last point, >>I disagree that UIRB values optimality over consistency. >>I see cases where teams are advized to be consistent >>even though there are better designs available. The >>UIRB is working well when it advocates for the customer >>(and sometimes customers want consistency more than >>efficiency.) I see no philosophical difference between >>PSARC and UIRB in this regard. >> >>Thanks, >>Rob >> >>Joseph Kowalski wrote On 01/24/06 18:31,: >> >> >> >>>Rob (and possibly UIRB in general), >>> >>>I've always had trouble with the fact the UIRB reviews are so strongly >>>driven by a single individual. I don't want to reopen that debate. When >>>that individual is working with well established guidelines (like CLIP), >>>this works fine. When it doesn't work is when that individual chooses >>>to invent or propose personal opinion. It *appears* that's what happened >>>here. >>> >>>I'm working on a *minor* update to the CLIP specification. I'm keeping >>>it to removing points of ambiguity and/or poor presentation to keep it >>>non-controversial. I think UIRB members are working on a broader >>>"interpretation" guideline. Either/both are fine, but somewhere the >>>guidelines need to be reviewed by a sizable body of individuals, before >>>they are implemented. >>> >>>And of course, there is tension that PSARC tends to value consistancy >>>while it appears that UIRB values localized optimality. I think this >>>tension is good in many respects, but it stresses the working relationship. >>> >>>- thanks, >>> >>>- jek3 >>> >>> >>> >>> >>> >>-- >> * Rob Mori * >>User Interface Review Board >> >>*Sun Microsystems, Inc.* >>Menlo Park, California >>Phone x89272/+1 650 786 9272 >>Mobile 650.575.9086 >>Email Rob.Mori@Sun.COM >> >> >> >> > > > -- * Rob Mori * User Interface Review Board *Sun Microsystems, Inc.* Menlo Park, California Phone x89272/+1 650 786 9272 Mobile 650.575.9086 Email Rob.Mori@Sun.COM From sacadmin Wed Jan 25 18:39:20 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.108.38]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0Q2dKIQ002284 for ; Wed, 25 Jan 2006 18:39:20 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-72.SFBay.Sun.COM [129.150.12.72]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id k0Q2dD6x490727; Wed, 25 Jan 2006 18:39:18 -0800 (PST) Message-Id: <200601260239.k0Q2dD6x490727@jurassic.eng.sun.com> Date: Wed, 25 Jan 2006 16:39:00 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/034 fsstat To: Joseph.Kowalski@sun.com, Rob.Mori@sun.com Cc: Calum.Mackay@sun.com, James.D.Carlson@sun.com, sommerfeld@sun.com, psarc@sac.sfbay.sun.com, Rich.Brown@sun.com, uirb@sun.com, David-John.Burrowes@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: McL01ZdngcUMEMy+FYJLFg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 855 > From: Robert Mori ... > On the last point, > I disagree that UIRB values optimality over consistency. > I see cases where teams are advized to be consistent > even though there are better designs available. The > UIRB is working well when it advocates for the customer > (and sometimes customers want consistency more than > efficiency.) I see no philosophical difference between > PSARC and UIRB in this regard. OK, I phrased that wrong. My intent was to indicate the PSARC values consistancy more that UIRB appears to. Both groups may value it highly; more highly than localized optimality. I say this based on experience. Experience that involved a changing cast of characters. Maybe my observation is based on former administrations. Finally, I hope no slur was read into my comments. Its just an observation. - jek3 From owner-uirb Wed Jan 25 18:39:36 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 k0Q2dZIQ002302 for ; Wed, 25 Jan 2006 18:39:36 -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 k0Q2dHRA010710; Thu, 26 Jan 2006 10:39:22 +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 <0ITO00105I1K3100@brm-avmta-1.central.sun.com>; Wed, 25 Jan 2006 19:39:20 -0700 (MST) Received: from jurassic.eng.sun.com ([129.146.58.37]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0ITO00I1UI1KPOD0@brm-avmta-1.central.sun.com>; Wed, 25 Jan 2006 19:39:20 -0700 (MST) Received: from hawaiian-sun (vpn-129-150-12-72.SFBay.Sun.COM [129.150.12.72]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id k0Q2dD6x490727; Wed, 25 Jan 2006 18:39:18 -0800 (PST) Date: Wed, 25 Jan 2006 16:39:00 -1000 (HST) From: Joseph Kowalski Subject: Re: 2006/034 fsstat To: Joseph.Kowalski@sun.com, Rob.Mori@sun.com Cc: Calum.Mackay@sun.com, James.D.Carlson@sun.com, sommerfeld@sun.com, psarc@sac.sfbay.sun.com, Rich.Brown@sun.com, uirb@sun.com, David-John.Burrowes@sun.com Reply-to: Joseph Kowalski Message-id: <200601260239.k0Q2dD6x490727@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: McL01ZdngcUMEMy+FYJLFg== X-PMX-Version: 5.1.1.222179 Status: RO Content-Length: 855 > From: Robert Mori ... > On the last point, > I disagree that UIRB values optimality over consistency. > I see cases where teams are advized to be consistent > even though there are better designs available. The > UIRB is working well when it advocates for the customer > (and sometimes customers want consistency more than > efficiency.) I see no philosophical difference between > PSARC and UIRB in this regard. OK, I phrased that wrong. My intent was to indicate the PSARC values consistancy more that UIRB appears to. Both groups may value it highly; more highly than localized optimality. I say this based on experience. Experience that involved a changing cast of characters. Maybe my observation is based on former administrations. Finally, I hope no slur was read into my comments. Its just an observation. - jek3 From sacadmin Fri Feb 10 10:45:25 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k1AIjPIQ007862 for ; Fri, 10 Feb 2006 10:45:25 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k1AIjLTe009993 for ; Fri, 10 Feb 2006 10:45:21 -0800 (PST) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k1AIjKQj016201 for ; Fri, 10 Feb 2006 11:45:21 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IUH00601ICSYU00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 10 Feb 2006 11:45:20 -0700 (MST) Received: from [129.147.9.32] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IUH00LSZIRCNRH1@mail-amer.sun.com>; Fri, 10 Feb 2006 11:45:13 -0700 (MST) Date: Fri, 10 Feb 2006 12:45:12 -0600 From: Rich Brown Subject: Re: 2006/034 fsstat Sender: Rich.Brown@Sun.COM To: psarc@sac.sfbay.sun.com Cc: Rich.Brown@Sun.COM, Jeff Bonwick Message-id: <43ECDF38.9020608@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) Status: RO Content-Length: 926 This is an addendum to PSARC 2006/034 fsstat. The approved architecture allows all filesystems to be instrumented to collect statistics and the team intends to provide that in the final delivery to Solaris Nevada. However, due to the constraints of the patch/micro release model, the initial delivery will support a subset of the pseudo filesystems (see below for exclusions). This is not a change in the architecture, this is a phased approach to the implementation. The following will be added to the NOTES section of the fsstat.1m man page: Statistics are not displayed for the following pseudo-filesystems: specfs, fifofs, namefs, lofs, fdfs, swapfs, mntfs, devfs, ctfs, objfs, sockfs, nfsdyn. These constraints do not affect storage-based file systems (ufs, zfs, etc.). In fact, Rick Matthews has put a Nevada-based SAM/QFS filesystem on an fsstat-based system and it worked as expected. Thanks, Rich