From sacadmin Tue Jun 9 13:53:59 2009 Received: from tethys.sfbay.sun.com (tethys.SFBay.Sun.COM [129.146.226.92]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n59KrxOm014628; Tue, 9 Jun 2009 13:53:59 -0700 (PDT) Received: from tethys.sfbay.sun.com (localhost [127.0.0.1]) by tethys.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n59Kr4vp013098; Tue, 9 Jun 2009 13:53:04 -0700 (PDT) Received: (from jg@localhost) by tethys.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n59Kr4RW013095; Tue, 9 Jun 2009 13:53:04 -0700 (PDT) Date: Tue, 9 Jun 2009 13:53:04 -0700 (PDT) From: Jerry Gilliam Message-Id: <200906092053.n59Kr4RW013095@tethys.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: EOF UCB Device Names [PSARC/2009/346 FastTrack timeout 06/16/2009] Status: RO Content-Length: 554 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: EOF UCB Device Names 1.2. Name of Document Author/Supplier: Author: Jerry Gilliam 1.3 Date of This Document: 09 June, 2009 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From jerry.gilliam@sun.com Tue Jun 9 14:02:39 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n59L2cDZ015269 for ; Tue, 9 Jun 2009 14:02:38 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n59L2W25019564; Tue, 9 Jun 2009 22:02:33 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKZ0021BP492K00@brm-avmta-1.central.sun.com>; Tue, 09 Jun 2009 15:02:33 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKZ00MZ8P48ZME0@brm-avmta-1.central.sun.com>; Tue, 09 Jun 2009 15:02:32 -0600 (MDT) Received: from [129.146.226.92] (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n59L2Vh4806245; Tue, 09 Jun 2009 14:02:32 -0700 (PDT) Date: Tue, 09 Jun 2009 14:01:37 -0700 From: Jerry Gilliam Subject: EOF UCB Device Names [PSARC/2009/346 timeout 06/16/2009] To: PSARC-ext@sun.com Cc: Sriram.Popuri@sun.com, Chris.Horne@sun.com, Jan.Setje-Eilers@sun.com Message-id: <4A2ECDB1.3070402@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 8511 I am submitting the following as a fast-track on behalf of myself, with a timeout set for 06/16/2009. Patch/micro binding is requested. ------------- 1. Introduction 1.1. Project/Component Working Name: EOF UCB Device Names 1.2. Name of Document Author/Supplier: Author: Jerry Gilliam 1.3. Date of This Document: 06/05/2009 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. Solaris PAC 1.4.2. PSARC 1.4.3. Chris Armes 1.4.4. Solaris Sustaining 1.5. Email Aliases: 1.5.1. Responsible Manager: Michael.Pogue@sun.com 1.5.2. Responsible Engineer: Jerry.Gilliam@sun.com 1.5.3. Marketing Manager: 1.5.4. Interest List: Sriram.Popuri@sun.com, Chris.Horne@sun.com, Jan.Setje-Eilers@sun.com 2. Project Summary 2.1. Project Description: EOF of UCB device names 3. Business Summary 3.1. Problem Area: Performance issues related to boot and device naming with ucblinks 3.2. Market/Requester: Escalations by Bloomberg Financial and other customers with large installations 3.2 Details A large configuration was simulated with a pseudo driver used to configure 16k disk devices. Devfsadm required 25 minutes in this configuration and ucblinks 5 minutes on top of that. The number of /dev/[r]sd names generated by ucblinks alone was 262k and since these names are at the top /dev level, greatly contribute to system sluggishness. For example, > 5 minute logins. With the /dev/[r]sd names removed, system responsiveness was as expected. 4. Technical Description: 4.1. Details: Since committed interfaces can only be obsoleted in a minor release and a way to provide relief to existing customers is required, a two-step process is proposed. In the current minor release, complete the EOF, removing ucblinks, and provide a note in the next available release with intention to obsolete said interfaces. For patch/macro release relief, it is proposed to introduce a service to manage ucblinks: svc:/system/ucb-device-names. With a default of disabled, the out-of-the box experience will be improved with no ucblinks generated and existing ucb compatible names removed. Enabling the service will generate ucb compatible names by running ucblinks, for any customer who desires this compatibility to be retained. The set of UCB compatible names is: UCB link name Standard name Device type /dev/[r]fd%d /dev/[r]diskette fd floppy drives /dev/[r]sr%d /dev/[r]dsk/* sd/atapi cdrom drives /dev/[r]sd%d /dev/[r]dsk/* sd disk drives /dev/[r]n%d /dev/rmt/* st tape drives Support for the following is removed: xd, xt, xy The following appear to be ucb compatible names, with code within ucblinks building them, but devfsadm builds them also so that removing the ucblinks code will not affect these names: /dev/fb%d /dev/fbs/* framebuffers /dev/tty[d]%d /devices link serial devices /dev/tty[a-z] /devices link serial devices 4.2. Bug/RFE Number(s): 6785226 devfsadm -C does not help to clean up the device tree. 4.5 Interfaces: Minor release: -------------- /usr/ucb/ucblinks(1B) Obsolete ucblinks end-of-feature /dev/[r]fd%d Obsolete floppy device /dev names /dev/[r]sr%d Obsolete cdrom /dev names /dev/[r]sd%d Obsolete disk /dev names /dev/[r]n%d Obsolete tape /dev names Patch/Macro release: -------------------- svc:/system/ucb-device-names Uncommitted service, disabled by default /lib/svc/method/ucb-device-names Proj. Priv. service method /var/svc/manifest/system/ Proj. Priv. service manifest ucb-device-names.xml /usr/ucb/ucblinks(1B) -C Uncommitted ucblinks cleanup The above patch/micro interfaces are not to be carried forward to the minor release. 4.6. Doc Impact: Minor release: -------------- ucblinks(1B) man page to be removed. Patch/Macro release: -------------------- ucblinks(1B) man page update - suggested changes provided. 4.12. Dependencies: There are no uses made of any /dev ucb compatible name within solaris. The base install of OpenSolaris does not include /usr/ucb/ucblinks. Some tools such as iostat generate device names using the form, equivalent to a ucb device name. iostat does have an option (-n) to generate reports using /dev/[rd]dsk device names. [2] The same names are logged along with device errors in the system log and one way to map such names to the physical device has been via the /dev ucb compatible name. Libdevinfo provides a method to do the same mapping. This is used by iostat(1M) and is available for usr by other tools as needed. [3] 5. Reference Documents: [1] PSARC/1996/430 iostat(1M) enhancements for device statistics [3] PSARC/2006/519 Metadevice Names in iostat/vmstat Output [2] PSARC/2000/310 libdevinfo devlinks interfaces 6. Resources and Schedule: http://tethys.sfbay/export/ws/onnv-ucb-svc 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open SunOS/BSD Compatibility Package Commands ucblinks(1B) NAME ucblinks - adds /dev entries to give SunOS 4.x compatible names to SunOS 5.x devices SYNOPSIS /usr/ucb/ucblinks [-e rulebase] [-r rootdir] [-C] | svc:/system/ucb-device-names DESCRIPTION ucblinks creates symbolic links under the /dev directory for devices whose SunOS 5.x names differ from their SunOS 4.x names. Where possible, these symbolic links point to the device's SunOS 5.x name rather than to the actual /devices entry. ucblinks does not remove unneeded compatibility links; these must be removed by hand. ucblinks should be called each time the system is reconfiguration-booted, after any new SunOS 5.x links that are needed have been created, since the reconfiguration may have resulted in more compatibility names being needed. In releases prior to SunOS 5.4, ucblinks used a nawk rule- base to construct the SunOS 4.x compatible names. ucblinks no longer uses nawk for the default operation, although nawk rule-bases can still be specifed with the -e option. The nawk rule-base equivalent to the SunOS 5.4 default operation can be found in /usr/ucblib/ucblinks.awk. The svc:/system/ucb-device-names service controls whether | the system runs ucblinks(1B) on reconfigure boot. When | enabled, ucblinks(1B) is run, both at that time and on | subsequent reconfiguration boots. When disabled, ucblinks(1B) | is run in clean-up (-C) and ucb device names will no longer | be reconstructed on reconfigure boot. | | The svc:/system/ucb-device-names service is by default disabled. | EXAMPLES | | Example 1: Querying the state of the service | | # svcs system/ucb-device-names | STATE STIME FMRI | disabled 13:19:49 svc:/system/ucb-device-names:default | | Example 2: Enabling the service | | # svcadm enable system/ucb-device-names | | Example 2: Enabling the service | | # svcadm disable system/ucb-device-names | OPTIONS -e rulebase Specify rulebase as the file containing nawk(1) pattern-action statements. -r rootdir Specify rootdir as the directory under which dev and devices will be found, rather than the standard root directory /. | -C Clean up /dev ucb compatible device names. | | FILES /usr/ucblib/ucblinks.awk sample rule-base for compatibil- ity links ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWscpu | |_____________________________|_____________________________| SEE ALSO devlinks(1M), disks(1M), ports(1M), tapes(1M), attributes(5) From john.plocher@gmail.com Tue Jun 9 16:38:48 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n59NcmJw018758 for ; Tue, 9 Jun 2009 16:38:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n59NchZQ015630; Tue, 9 Jun 2009 17:38:45 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKZ00903WCKT800@nwk-avmta-1.sfbay.Sun.COM>; Tue, 09 Jun 2009 16:38:44 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKZ00AKUWCKTV90@nwk-avmta-1.sfbay.Sun.COM>; Tue, 09 Jun 2009 16:38:44 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n59Naciq024916; Tue, 09 Jun 2009 23:38:44 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay42i.sun.com with ESMTP id BT-MMP-6216740; Tue, 09 Jun 2009 23:38:43 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-25287744; Tue, 09 Jun 2009 23:38:43 +0000 (Z) Received: from mail-qy0-f192.google.com ([209.85.221.192] [209.85.221.192]) by relay4i.sun.com with ESMTP id BT-MMP-2145935; Tue, 09 Jun 2009 23:38:43 +0000 (Z) Received: by mail-qy0-f192.google.com with SMTP id 30so479434qyk.30 for ; Tue, 09 Jun 2009 16:38:41 -0700 (PDT) Received: by 10.229.85.21 with SMTP id m21mr175470qcl.9.1244590377437; Tue, 09 Jun 2009 16:32:57 -0700 (PDT) Date: Tue, 09 Jun 2009 16:32:57 -0700 From: John Plocher Subject: Re: EOF UCB Device Names [PSARC/2009/346 timeout 06/16/2009] In-reply-to: <4A2ECDB1.3070402@sun.com> To: Jerry Gilliam Cc: PSARC-ext@sun.com, Sriram.Popuri@sun.com, Jan.Setje-Eilers@sun.com, Chris.Horne@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BkeXTaSULGyiLfJ3TyfCrSrcZAc5fHx4F1VDmI/cNgA=; b=OdWUegX08tZ6xTrRN3Zajxov6PZqwVp1zEgBI91RPb4/B/MaZOEcu9Si6X9KZmbS0z Mep+t+0NPli1t/VOf4lKeLEhEMVDuZ7D1d65i4gHI/eCpa11uZ2uE3X3/pRvajzXGbyv SuqiZE94WLhlJHt13Aya7uvFm+nhXnX0QpmIA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cL1SqYlEi15CLNWsVcuqVRoXNGioEIsy5P7xD15aVju1JrxfTQgGYT7YN85i1ynQlk iTS86HKzLotz/NdkuF2EnciaZUT2mQfMCW+6uDF6u+SO+vyy2k4yJOCxrLHfEo/WCqa/ l0+5s5JAnkIaUK5lMVrUFjhJ7ybGNWj5Uz4Uw= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.058sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4A2ECDB1.3070402@sun.com> Status: RO Content-Length: 1116 +--- from man page-- | EXAMPLES | ... | Example 2: Enabling the service | | # svcadm enable system/ucb-device-names | | Example 2: Enabling the service | | # svcadm disable system/ucb-device-names +-- I assume that the duplicated "Example 2" heading is a typo, and that "disable" removes the links created by "enable" (the proposal never explicitly says it does...) +-- from the proposal --- | 4.12. Dependencies: | Some tools such as iostat generate device names using the | form, | ... | The same names are logged along with device errors | in the system log +-- For completeness, it would be good if you also updated the tools (such as iostat) and system error log messages to generate correct device names by default, since with the removal of usb names, their output will become something between deliberately misleading and wrong :-) Yes, I know this opens a stability-of-output can of worms, but being able to fix these types of reality mismatches is exactly why the next "Solaris" is being positioned as a major release... -John From jerry.gilliam@sun.com Tue Jun 9 17:55:46 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5A0tkdP020836 for ; Tue, 9 Jun 2009 17:55:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5A0th1v011091; Tue, 9 Jun 2009 17:55:44 -0700 (PDT) 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 <0KKZ00301ZWVTW00@brm-avmta-1.central.sun.com>; Tue, 09 Jun 2009 18:55:43 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKZ00CQJZWVV760@brm-avmta-1.central.sun.com>; Tue, 09 Jun 2009 18:55:43 -0600 (MDT) Received: from [129.146.226.92] (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n5A0tgfi844067; Tue, 09 Jun 2009 17:55:42 -0700 (PDT) Date: Tue, 09 Jun 2009 17:54:48 -0700 From: Jerry Gilliam Subject: Re: EOF UCB Device Names [PSARC/2009/346 timeout 06/16/2009] In-reply-to: To: John Plocher Cc: PSARC-ext@sun.com, Sriram.Popuri@sun.com, Jan.Setje-Eilers@sun.com, Chris.Horne@sun.com Message-id: <4A2F0458.8020109@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A2ECDB1.3070402@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 2091 John Plocher wrote: > > I assume that the duplicated "Example 2" heading is a typo, and that > "disable" removes the links created by "enable" (the proposal never > explicitly says it does...) > Yes, and the DESCRIPTION section of the man page does note that When disabled, ucblinks(1B) is run in clean-up (-C) and ucb device names will no longer be reconstructed on reconfigure boot. so the clean-up is the intended behavior on disable. I'll update the spec with that correction (amongst others) for the final version. > > For completeness, it would be good if you also updated the tools (such > as iostat) and system error log messages to generate correct device > names by default, since with the removal of usb names, their output > will become something between deliberately misleading and wrong :-) > Yes, I know this opens a stability-of-output can of worms, but being > able to fix these types of reality mismatches is exactly why the next > "Solaris" is being positioned as a major release... > > -John The heavy lifting has already been done to modify iostat(1M) to display CTD names. However this is not the default, one must use -n. See PSARC/2005/574, MPxIO iostat improvements. The difference: tethys:jg[118] % iostat tty sd0 sd1 sd2 nfs1 cpu tin tout kps tps serv kps tps serv kps tps serv kps tps serv us sy wt id 0 15 0 0 0 21 1 15 0 0 0 5 1 113 1 0 0 99 tethys:jg[119] % iostat -n tty c7t0d0 c7t1d0 c7t2d0 jurassic-x460 cpu tin tout kps tps serv kps tps serv kps tps serv kps tps serv us sy wt id 0 15 0 0 0 21 1 15 0 0 0 5 1 113 1 0 0 99 For the minor (major?) release only, I think it would be reasonable to modify iostat(1M) to -n behavior by default, effectively obsoleting -n and the form of device name reporting. We would need to retain and ignore -n for compatibility I assume. If that is acceptable, I can amend the materials. -jg From setje@sun.com Tue Jun 9 18:05:10 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5A15Am1021152 for ; Tue, 9 Jun 2009 18:05:10 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5A153uA049262; Tue, 9 Jun 2009 19:05:07 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KL000L170CHO700@nwk-avmta-1.sfbay.Sun.COM>; Tue, 09 Jun 2009 18:05:05 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KL000APO0CGTZC0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 09 Jun 2009 18:05:04 -0700 (PDT) Received: from [129.146.226.114] (smack.SFBay.Sun.COM [129.146.226.114]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n5A153II846912; Tue, 09 Jun 2009 18:05:03 -0700 (PDT) Date: Tue, 09 Jun 2009 18:05:03 -0700 From: Jan Setje-Eilers Subject: Re: EOF UCB Device Names [PSARC/2009/346 timeout 06/16/2009] In-reply-to: <4A2F0458.8020109@sun.com> To: Jerry Gilliam Cc: John Plocher , PSARC-ext@sun.com, Sriram.Popuri@sun.com, Jan.Setje-Eilers@sun.com, Chris.Horne@sun.com Message-id: <4A2F06BF.7070500@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A2ECDB1.3070402@sun.com> <4A2F0458.8020109@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 2455 Jerry Gilliam wrote: > John Plocher wrote: > > > > > I assume that the duplicated "Example 2" heading is a typo, and that > > "disable" removes the links created by "enable" (the proposal never > > explicitly says it does...) > > > > Yes, and the DESCRIPTION section of the man page does note that > > When disabled, ucblinks(1B) is run in clean-up (-C) and > ucb device names will no longer be reconstructed on > reconfigure boot. > > so the clean-up is the intended behavior on disable. > > I'll update the spec with that correction (amongst others) for > the final version. > > > > > For completeness, it would be good if you also updated the tools (such > > as iostat) and system error log messages to generate correct device > > names by default, since with the removal of usb names, their output > > will become something between deliberately misleading and wrong :-) > > Yes, I know this opens a stability-of-output can of worms, but being > > able to fix these types of reality mismatches is exactly why the next > > "Solaris" is being positioned as a major release... > > > > -John > > The heavy lifting has already been done to modify iostat(1M) to > display CTD names. However this is not the default, one must use -n. > See PSARC/2005/574, MPxIO iostat improvements. > > The difference: > > tethys:jg[118] % iostat > tty sd0 sd1 sd2 nfs1 cpu > tin tout kps tps serv kps tps serv kps tps serv kps tps serv us sy > wt id > 0 15 0 0 0 21 1 15 0 0 0 5 1 113 1 0 > 0 99 > > tethys:jg[119] % iostat -n > tty c7t0d0 c7t1d0 c7t2d0 jurassic-x460 cpu > tin tout kps tps serv kps tps serv kps tps serv kps tps serv us sy > wt id > 0 15 0 0 0 21 1 15 0 0 0 5 1 113 1 0 > 0 99 > > For the minor (major?) release only, I think it would be reasonable to > modify iostat(1M) to -n behavior by default, effectively obsoleting > -n and the form of device name reporting. We would > need to retain and ignore -n for compatibility I assume. > > If that is acceptable, I can amend the materials. I'd really like to see that. However to clarify, the names that iostat is currently using are not the ucb names. They are as Jerry points out and remain unchanged without the ucb links being present. -jan From john.plocher@gmail.com Tue Jun 9 18:35:15 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5A1ZEMj021713 for ; Tue, 9 Jun 2009 18:35:14 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n5A1Z33H000258; Wed, 10 Jun 2009 09:35:09 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KL0002011QKSU00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 09 Jun 2009 18:35:08 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KL000AF51QKU3F0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 09 Jun 2009 18:35:08 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5A1NMdt014423; Wed, 10 Jun 2009 01:35:08 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay44i.sun.com with ESMTP id BT-MMP-758025; Wed, 10 Jun 2009 01:35:08 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-25600332; Wed, 10 Jun 2009 01:35:07 +0000 (Z) Received: from mail-qy0-f171.google.com ([209.85.221.171] [209.85.221.171]) by relay4i.sun.com with ESMTP id BT-MMP-3909703; Wed, 10 Jun 2009 01:35:07 +0000 (Z) Received: by qyk1 with SMTP id 1so673327qyk.17 for ; Tue, 09 Jun 2009 18:33:16 -0700 (PDT) Received: by 10.229.110.20 with SMTP id l20mr181705qcp.60.1244597596576; Tue, 09 Jun 2009 18:33:16 -0700 (PDT) Date: Tue, 09 Jun 2009 18:33:16 -0700 From: John Plocher Subject: Re: EOF UCB Device Names [PSARC/2009/346 timeout 06/16/2009] In-reply-to: <4A2F0458.8020109@sun.com> To: Jerry Gilliam Cc: PSARC-ext@sun.com, Sriram.Popuri@sun.com, Jan.Setje-Eilers@sun.com, Chris.Horne@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=v8pydwefRjMwROSDWJ8tlq2w0tXMGZPGgEB2PBehP8Q=; b=EzW2jJVPn3tbeeQzXWAUzCsVcZcm0JxL07oVbWL5nlln90Lkb3h/EAnhFR+W0zL200 ai9iOlXtQSv2wNjwNjuz0dBN25V+ZUEcm9eRGI4xBqpIRkGfZ9/njtxOCRooUQWyg1JI HE5jsead2rI17NCztlvqhv30lmO5/TmtgDu+c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EPQ/X6XPL7QilvIwCgtKAPODbr5mxoWDHClRofx9xgelWfiLLuAalvk3p/n1RoWMHW CF8kXPfs83I9nrnRc9P14qOnoqm8xU5DI+wTRBwu6dlDctbjLBF9IUEmwH1CAhN5TAF3 KQyELEyw32W+rT5l7G5xUgiRFi4MTqJumear4= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.051sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4A2ECDB1.3070402@sun.com> <4A2F0458.8020109@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id n5A1ZEMj021713 Status: RO Content-Length: 450 On Tue, Jun 9, 2009 at 5:54 PM, Jerry Gilliam wrote: > For the minor (major?) release only, I think it would be reasonable to > modify iostat(1M) to -n behavior by default, effectively obsoleting > -n and the form of device name reporting.  We would > need to retain and ignore -n for compatibility I assume. This sounds good. All we need now is to update the log entries that were mentioned... -John From jerry.gilliam@sun.com Tue Jun 9 18:51:23 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5A1pNfL021908 for ; Tue, 9 Jun 2009 18:51:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5A1pKGI002456; Tue, 9 Jun 2009 19:51:20 -0600 (MDT) 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 <0KL000A0F2HH1900@brm-avmta-1.central.sun.com>; Tue, 09 Jun 2009 19:51:17 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KL000CPV2HHVBA0@brm-avmta-1.central.sun.com>; Tue, 09 Jun 2009 19:51:17 -0600 (MDT) Received: from [129.146.226.92] (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n5A1pHMY851840; Tue, 09 Jun 2009 18:51:17 -0700 (PDT) Date: Tue, 09 Jun 2009 18:50:22 -0700 From: Jerry Gilliam Subject: Re: EOF UCB Device Names [PSARC/2009/346 timeout 06/16/2009] In-reply-to: To: John Plocher Cc: PSARC-ext@sun.com, Sriram.Popuri@sun.com, Jan.Setje-Eilers@sun.com, Chris.Horne@sun.com Message-id: <4A2F115E.6090305@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A2ECDB1.3070402@sun.com> <4A2F0458.8020109@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 759 John Plocher wrote: > On Tue, Jun 9, 2009 at 5:54 PM, Jerry Gilliam wrote: >> For the minor (major?) release only, I think it would be reasonable to >> modify iostat(1M) to -n behavior by default, effectively obsoleting >> -n and the form of device name reporting. We would >> need to retain and ignore -n for compatibility I assume. > > This sounds good. All we need now is to update the log entries that > were mentioned... > > -John That will not be so easily accomplished, those log messages are coming out of the kernel where there's not much information other than driver/instance number available. And I believe FMA is doing a better job of providing device error status than the message log. -jg From gdamore@sun.com Tue Jun 9 22:29:25 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5A5TPdx024811 for ; Tue, 9 Jun 2009 22:29:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5A5TPgX016985 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 9 Jun 2009 23:29:25 -0600 (MDT) 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 <0KL000B01CL1DD00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 09 Jun 2009 23:29:25 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KL000L6PCL01270@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 09 Jun 2009 23:29:24 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5A5TOG9021773 for ; Tue, 09 Jun 2009 22:29:24 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KL000800C9Y0W00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 09 Jun 2009 22:29:24 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KL0008ZBCKZQ7E0@fe-sfbay-09.sun.com>; Tue, 09 Jun 2009 22:29:24 -0700 (PDT) Date: Tue, 09 Jun 2009 22:29:23 -0700 From: "Garrett D'Amore" Subject: Re: EOF UCB Device Names [PSARC/2009/346 timeout 06/16/2009] In-reply-to: <4A2F0458.8020109@sun.com> Sender: Garrett.Damore@sun.com To: Jerry Gilliam Cc: John Plocher , PSARC-ext@sun.com, Sriram.Popuri@sun.com, Jan.Setje-Eilers@sun.com, Chris.Horne@sun.com Message-id: <4A2F44B3.1020407@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A2ECDB1.3070402@sun.com> <4A2F0458.8020109@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2692 Jerry Gilliam wrote: > John Plocher wrote: > > > > > I assume that the duplicated "Example 2" heading is a typo, and that > > "disable" removes the links created by "enable" (the proposal never > > explicitly says it does...) > > > > Yes, and the DESCRIPTION section of the man page does note that > > When disabled, ucblinks(1B) is run in clean-up (-C) and > ucb device names will no longer be reconstructed on > reconfigure boot. > > so the clean-up is the intended behavior on disable. > > I'll update the spec with that correction (amongst others) for > the final version. > > > > > For completeness, it would be good if you also updated the tools (such > > as iostat) and system error log messages to generate correct device > > names by default, since with the removal of usb names, their output > > will become something between deliberately misleading and wrong :-) > > Yes, I know this opens a stability-of-output can of worms, but being > > able to fix these types of reality mismatches is exactly why the next > > "Solaris" is being positioned as a major release... > > > > -John > > The heavy lifting has already been done to modify iostat(1M) to > display CTD names. However this is not the default, one must use -n. > See PSARC/2005/574, MPxIO iostat improvements. > > The difference: > > tethys:jg[118] % iostat > tty sd0 sd1 sd2 nfs1 > cpu > tin tout kps tps serv kps tps serv kps tps serv kps tps serv us > sy wt id > 0 15 0 0 0 21 1 15 0 0 0 5 1 113 1 > 0 0 99 > > tethys:jg[119] % iostat -n > tty c7t0d0 c7t1d0 c7t2d0 jurassic-x460 > cpu > tin tout kps tps serv kps tps serv kps tps serv kps tps serv us > sy wt id > 0 15 0 0 0 21 1 15 0 0 0 5 1 113 1 > 0 0 99 > > For the minor (major?) release only, I think it would be reasonable to > modify iostat(1M) to -n behavior by default, effectively obsoleting > -n and the form of device name reporting. We would > need to retain and ignore -n for compatibility I assume. > > If that is acceptable, I can amend the materials. I agree with the above. However, I have some reservations about this change for Solaris 10. I believe that disabling ucblinks on Solaris 10 should *not* be done by default, because of the interface incompatibility, but offered to sites that need it as a workaround. As a possible compromise, I'd be happy if it were disabled by default on a new install, but remained enabled when upgrading. With the above amendments, I'd be happy to vote +1 for this case. - Garrett > > > -jg From john.plocher@gmail.com Wed Jun 10 08:41:25 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5AFfNgw001729 for ; Wed, 10 Jun 2009 08:41:24 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n5AFfCQQ014763; Wed, 10 Jun 2009 23:41:17 +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 <0KL100G0Z4WS2900@nwk-avmta-2.sfbay.sun.com>; Wed, 10 Jun 2009 08:41:16 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KL100G0U4WS1700@nwk-avmta-2.sfbay.sun.com>; Wed, 10 Jun 2009 08:41:16 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5AFfFFa022573; Wed, 10 Jun 2009 15:41:15 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay14i.sun.com with ESMTP id BT-MMP-2841198; Wed, 10 Jun 2009 15:39:15 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-66462; Wed, 10 Jun 2009 15:39:15 +0000 (Z) Received: from mail-qy0-f192.google.com ([209.85.221.192] [209.85.221.192]) by relay1i.sun.com with ESMTP id BT-MMP-1052659; Wed, 10 Jun 2009 15:39:15 +0000 (Z) Received: by mail-qy0-f192.google.com with SMTP id 30so1453964qyk.30 for ; Wed, 10 Jun 2009 08:39:14 -0700 (PDT) Received: by 10.229.81.144 with SMTP id x16mr292051qck.69.1244648354363; Wed, 10 Jun 2009 08:39:14 -0700 (PDT) Date: Wed, 10 Jun 2009 08:39:14 -0700 From: John Plocher Subject: Re: EOF UCB Device Names [PSARC/2009/346 timeout 06/16/2009] In-reply-to: <4A2F44B3.1020407@sun.com> To: "Garrett D'Amore" Cc: Jerry Gilliam , PSARC-ext@sun.com, Sriram.Popuri@sun.com, Jan.Setje-Eilers@sun.com, Chris.Horne@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ANqQmGIMXMlK5xhhlNh3+m4dvjk8wuJSFSvf1htIz7M=; b=x0XM9ZNEv/LhDJIj8GIeo7/pUmsihjxHwhvndSYnYc40QL4xDlxx6XvcAtYIrZJEBp lCpIIIF0FKlap4zfnI6D80bOkIn9CQwogzsmdoZ1OFg1pGL3HOcT+MQwcInsZm2IV5sO 11Jj9PkvsZSqF10Ijm48XDxBSz3GbSMftDNq0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Ake+XydAM5dAxbGqIfm9f/McU/ydcP/hf3zv25AoBSw/RHP3bHHrJe5RzZ/r93PDaM eW3wjpkENgcf4faAg9Ikt/brLRFtYB8plSFsunmHPSSVeaK3JT95+6T76QtHx+va8VUf 3zYOqzSQPSOFoXwq58AAxJBUmFnHl7VC+oGX8= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.055sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4A2ECDB1.3070402@sun.com> <4A2F0458.8020109@sun.com> <4A2F44B3.1020407@sun.com> Status: RO Content-Length: 648 On Tue, Jun 9, 2009 at 10:29 PM, Garrett D'Amore wrote: > However, I have some reservations about this change for Solaris 10. I understood Jerry's comment... Jerry Gilliam wrote: > For the minor (major?) release only, I think it would be reasonable to > modify iostat(1M) to -n behavior by default, effectively obsoleting > -n and the form of device name reporting. ... to say that the iostat and vmstat and friends would not change their default in Solaris10 (which would be the "patch binding" part of the effort), but that they could/would in OpenSolaris/Solaris.next (the minor/major? binding). -John From jerry.gilliam@Sun.COM Wed Jun 10 11:00:15 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5AI0FQ4010761 for ; Wed, 10 Jun 2009 11:00:15 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5AI04Nj048581; Wed, 10 Jun 2009 12:00:12 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KL10001BBCAOI00@nwk-avmta-2.sfbay.sun.com>; Wed, 10 Jun 2009 11:00:10 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KL100GCLBCA1790@nwk-avmta-2.sfbay.sun.com>; Wed, 10 Jun 2009 11:00:10 -0700 (PDT) Received: from [129.146.226.92] (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n5AI0AcC967014; Wed, 10 Jun 2009 11:00:10 -0700 (PDT) Date: Wed, 10 Jun 2009 10:59:13 -0700 From: Jerry Gilliam Subject: Re: EOF UCB Device Names [PSARC/2009/346 timeout 06/16/2009] In-reply-to: <4A2F44B3.1020407@sun.com> To: "Garrett D'Amore" Cc: John Plocher , PSARC-ext@Sun.COM, Sriram.Popuri@Sun.COM, Jan.Setje-Eilers@Sun.COM, Chris.Horne@Sun.COM Message-id: <4A2FF471.80501@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A2ECDB1.3070402@sun.com> <4A2F0458.8020109@sun.com> <4A2F44B3.1020407@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 746 > > However, I have some reservations about this change for Solaris 10. I > believe that disabling ucblinks on Solaris 10 should *not* be done by > default, because of the interface incompatibility, but offered to sites > that need it as a workaround. > > As a possible compromise, I'd be happy if it were disabled by default on > a new install, but remained enabled when upgrading. > > With the above amendments, I'd be happy to vote +1 for this case. > > - Garrett > Making the patch/micro behavior simply default to enabled would be acceptable, I believe. That would give us an unchanged out-of-the-box behavior, but with a straightforward, persistent and documented means of disabling the behavior for anyone that cares. -jg From Andrew.Gabriel@sun.com Wed Jun 10 11:18:48 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5AIImj9011490 for ; Wed, 10 Jun 2009 11:18:48 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n5AIIJMX010539 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 11 Jun 2009 02:18:47 +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 <0KL10011TC71O600@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Jun 2009 11:18:37 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KL100GHYC7015C0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Jun 2009 11:18:37 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5AIIa93004250 for ; Wed, 10 Jun 2009 18:18:36 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KL100C00C3TXU00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Jun 2009 19:18:36 +0100 (BST) Received: from [81.187.162.109] ([unknown] [81.187.162.109]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KL1001Y2C6ZV740@fe-emea-10.sun.com>; Wed, 10 Jun 2009 19:18:36 +0100 (BST) Date: Wed, 10 Jun 2009 19:18:45 +0100 From: Andrew Gabriel Subject: Re: EOF UCB Device Names [PSARC/2009/346 timeout 06/16/2009] In-reply-to: <4A2ECDB1.3070402@sun.com> Sender: Andrew.Gabriel@sun.com To: Jerry Gilliam Cc: PSARC-ext@sun.com, Sriram.Popuri@sun.com, Chris.Horne@sun.com, Jan.Setje-Eilers@sun.com Message-id: <4A2FF905.7090509@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A2ECDB1.3070402@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 467 Jerry Gilliam wrote: > 2. Project Summary > 2.1. Project Description: > > EOF of UCB device names > > UCB link name Standard name Device type > > /dev/[r]sr%d /dev/[r]dsk/* sd/atapi cdrom drives This one I do see quite frequently used in shell scripts, in order to find which of the disk devices is the cdrom/DVD drive on the system. What's the replacement mechanism for doing this in shell scripts? -- Andrew From Artem.Kachitchkin@sun.com Wed Jun 10 13:12:20 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5AKCJxJ013829 for ; Wed, 10 Jun 2009 13:12:20 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n5AKCFTi010579 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 11 Jun 2009 04:12:19 +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 <0KL100803HGH3Z00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Jun 2009 14:12:17 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KL100MVSHGHL340@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Jun 2009 14:12:17 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5AKCHFP026310 for ; Wed, 10 Jun 2009 13:12:17 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KL100500H1I8000@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Jun 2009 13:12:16 -0700 (PDT) Received: from [129.146.104.83] ([unknown] [129.146.104.83]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KL100BGCHG9H080@fe-sfbay-10.sun.com>; Wed, 10 Jun 2009 13:12:09 -0700 (PDT) Date: Wed, 10 Jun 2009 13:12:07 -0700 From: Artem Kachitchkine Subject: Re: EOF UCB Device Names [PSARC/2009/346 timeout 06/16/2009] In-reply-to: <4A2FF905.7090509@sun.com> Sender: Artem.Kachitchkin@sun.com To: Andrew Gabriel Cc: Jerry Gilliam , PSARC-ext@sun.com, Jan.Setje-Eilers@sun.com, Chris.Horne@sun.com, Sriram.Popuri@sun.com Message-id: <4A301397.9080802@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A2ECDB1.3070402@sun.com> <4A2FF905.7090509@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081215) Status: RO Content-Length: 440 >> /dev/[r]sr%d /dev/[r]dsk/* sd/atapi cdrom drives > > This one I do see quite frequently used in shell scripts, in order to > find which of the disk devices is the cdrom/DVD drive on the system. > > What's the replacement mechanism for doing this in shell scripts? This is what I do: for i in `hal-find-by-capability --capability storage.cdrom`;do hal-get-property --udi $i --key block.device done -Artem From peter.tribble@gmail.com Wed Jun 10 15:10:22 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5AMAMim017317 for ; Wed, 10 Jun 2009 15:10:22 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5AMAJAt019918; Wed, 10 Jun 2009 15:10:19 -0700 (PDT) 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 <0KL100G01MX62Q00@nwk-avmta-2.sfbay.sun.com>; Wed, 10 Jun 2009 15:10:18 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KL100EUYMX6Y400@nwk-avmta-2.sfbay.sun.com>; Wed, 10 Jun 2009 15:10:18 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5AM5tin009336; Wed, 10 Jun 2009 22:10:17 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay44i.sun.com with ESMTP id BT-MMP-47429; Wed, 10 Jun 2009 22:10:17 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-26588266; Wed, 10 Jun 2009 22:10:16 +0000 (Z) Received: from mail-ew0-f205.google.com ([209.85.219.205] [209.85.219.205]) by relay4i.sun.com with ESMTP id BT-MMP-4451154; Wed, 10 Jun 2009 22:10:15 +0000 (Z) Received: by ewy1 with SMTP id 1so1491383ewy.8 for ; Wed, 10 Jun 2009 15:08:03 -0700 (PDT) Received: by 10.216.39.194 with SMTP id d44mr703952web.116.1244671683231; Wed, 10 Jun 2009 15:08:03 -0700 (PDT) Date: Wed, 10 Jun 2009 23:08:03 +0100 From: Peter Tribble Subject: Re: EOF UCB Device Names [PSARC/2009/346 timeout 06/16/2009] In-reply-to: <4A2ECDB1.3070402@sun.com> To: Jerry Gilliam Cc: PSARC-ext@sun.com, Sriram.Popuri@sun.com, Jan.Setje-Eilers@sun.com, Chris.Horne@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k0c/2AszRUYEPNxGU2uPgifFtee24hTVjNmZXuwTFwY=; b=Qtf00OFE0+M8S7XiKjrPSx/GG8Y0NxzDBPVJUMolAnEI596TVpvXH2jMEquc9CrtxM y+9dtTPXdJdDWHMHY2xniinyY7Fhat9iuaYznfJIxpL9stxSBpAKsQ7IzYxqiausUlB1 4R/w3WGXIfIA/hl+RQGbsCOh3EemWfMcL590I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=w+2uwxMj5yzF4UvJ1wQm4+QH+0oBr8OO5Xlp9lxi2SuqZxthNHfBuThndAWWHB/b00 A+i7ku9NrZtE8gF9ZzF9s3l+BvZ6x7X+Cioj51WWTazkstmm+vq1r0x5YDcvSBwPiZ/l W3SQrQq0qUlrxKMqL1sOv9NP7yfndt36z+sIY= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.516sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4A2ECDB1.3070402@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id n5AMAMim017317 Status: RO Content-Length: 1513 On Tue, Jun 9, 2009 at 10:01 PM, Jerry Gilliam wrote: > > I am submitting the following as a fast-track on behalf of myself, with > a timeout set for 06/16/2009.  Patch/micro binding is requested. > > ------------- > > 1. Introduction >   1.1. Project/Component Working Name: >        EOF UCB Device Names ... >        For patch/macro release relief, it is proposed to introduce a >        service to manage ucblinks: svc:/system/ucb-device-names.  With >        a default of disabled, the out-of-the box experience will be >        improved with no ucblinks generated and existing ucb compatible >        names removed.  Enabling the service will generate ucb compatible >        names by running ucblinks, for any customer who desires this >        compatibility to be retained. Why add additional complexity? Someone wishing to disable this behaviour already has 3 (at least) options - pkgrm SUNWscpu, rm /usr/ucb/ucblinks, or edit /etc/init.d/devlinks. If it's disabled by default then customers who care could run it manually or edit the devlinks script to reactivate it. Adding a service to manage ucblinks seems to me to be hoping that two wrongs will make a right. (If devlinks were a service then whether ucblinks were enabled could simply be a property of that service. Moving the buggy bit you want to be rid of to a service while leaving the primary component unchanged doesn't seem right.) -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ From jerry.gilliam@sun.com Wed Jun 10 15:47:53 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5AMlqDR018255 for ; Wed, 10 Jun 2009 15:47:52 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5AMlb5U003017; Wed, 10 Jun 2009 23:47:47 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KL100501ONL8L00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 10 Jun 2009 15:47:46 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KL1003ZWONL9G20@nwk-avmta-1.sfbay.Sun.COM>; Wed, 10 Jun 2009 15:47:45 -0700 (PDT) Received: from [129.146.226.92] (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n5AMljUN131783; Wed, 10 Jun 2009 15:47:45 -0700 (PDT) Date: Wed, 10 Jun 2009 15:46:49 -0700 From: Jerry Gilliam Subject: Re: EOF UCB Device Names [PSARC/2009/346 timeout 06/16/2009] In-reply-to: To: Peter Tribble Cc: PSARC-ext@sun.com, Sriram.Popuri@sun.com, Jan.Setje-Eilers@sun.com, Chris.Horne@sun.com Message-id: <4A3037D9.8090901@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A2ECDB1.3070402@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 505 > > Why add additional complexity? Someone wishing to disable this behaviour > already has 3 (at least) options > Yes, the options you list are ways to accomplish the same result. However, customers have a strong preference for administrative methods that don't require editing or removing files. Using a service allows an administrator to specify the desired behavior or query the present state of the behavior via script or command line, without making changes to the system as installed. -jg From jerry.gilliam@sun.com Wed Jun 17 10:06:57 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5HH6vie016263 for ; Wed, 17 Jun 2009 10:06:57 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5HH6sY4009530; Wed, 17 Jun 2009 10:06:54 -0700 (PDT) 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 <0KLE00N6E7JI2V00@brm-avmta-1.central.sun.com>; Wed, 17 Jun 2009 11:06:54 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLE00HI77JH8350@brm-avmta-1.central.sun.com>; Wed, 17 Jun 2009 11:06:54 -0600 (MDT) Received: from [129.146.226.92] (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n5HH6rnJ124592; Wed, 17 Jun 2009 10:06:53 -0700 (PDT) Date: Wed, 17 Jun 2009 10:05:42 -0700 From: Jerry Gilliam Subject: Re: EOF UCB Device Names [PSARC/2009/346 timeout 06/16/2009] To: PSARC-ext@sun.com Cc: Sriram.Popuri@sun.com, Chris.Horne@sun.com, Jan.Setje-Eilers@sun.com Message-id: <4A392266.9050106@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 2128 I've received some off-line comments from Chris regarding the iostat(1M) change and based on this, I'd like to withdraw the iostat -n change in behavior from this case. I'll update the materials shortly. Should the timer be reset on this case to give people time to review this change, and if so, what would be appropriate? Not that I'm expecting it to be controversial, the form of name happens to be identical to the ucb form of name but is not actually related to ucblinks or the /dev ucb names in any way. -jg -------------------- I think the '-n' change to iostat(1M) is the highest risk thing you are proposing, and I am not in favor of this change as specified. In addition to the translation problem, there are truncation issues to resolve. I think if you look, you will find some CRs against current 'iostat -n' causing incorrect/truncated output. Things look good with # iostat -n tty c1t0d0 c1t1d0 c0t0d0 cpu tin tout kps tps serv kps tps serv kps tps serv us sy wt id 0 0 17 1 4 0 0 0 0 0 0 0 0 0 100 but with fabric/mpxio names current -n behavior truncates/breaks. # iostat c3t216000C0FF8047DDd0 c3t216000C0FF8047DDd10 c3t216000C0FF8047DDd11 tty sd16 ssd178 ssd182 ssd216 cpu tin tout kps tps serv kps tps serv kps tps serv kps tps serv us sy wt id 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 99 # iostat -n c3t216000C0FF8047DDd0 c3t216000C0FF8047DDd10 c3t216000C0FF8047DDd11 tty c0t1d0 c3t216000C0FF c3t216000C0FF c3t216000C0FF cpu tin tout kps tps serv kps tps serv kps tps serv kps tps serv us sy wt id 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 99 I would prefer to see a translation mechanism delivered prior to an iostat change. With a translation mechanism in place, you could then revisit the -n proposal in a more limited way - one that does not cause truncation: maybe -X implies -n, or something like that (for line-per-device type output). -Chris From gdamore@sun.com Wed Jun 17 15:23:27 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5HMNQfH002705 for ; Wed, 17 Jun 2009 15:23:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n5HMNNtF026610 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Jun 2009 06:23:26 +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 <0KLE0060HM6ZXG00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Jun 2009 15:23:23 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLE003XVM6ZHC20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Jun 2009 15:23:23 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5HMNN9W019987 for ; Wed, 17 Jun 2009 15:23:23 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLE00000LC1PL00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Jun 2009 15:23:23 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLE00LN0M6GOZD0@fe-sfbay-10.sun.com>; Wed, 17 Jun 2009 15:23:05 -0700 (PDT) Date: Wed, 17 Jun 2009 15:23:04 -0700 From: "Garrett D'Amore" Subject: Re: EOF UCB Device Names [PSARC/2009/346 timeout 06/16/2009] In-reply-to: <4A392266.9050106@sun.com> Sender: Garrett.Damore@sun.com To: Jerry Gilliam Cc: PSARC-ext@sun.com, Sriram.Popuri@sun.com, Chris.Horne@sun.com, Jan.Setje-Eilers@sun.com Message-id: <4A396CC8.2060801@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A392266.9050106@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2375 Jerry Gilliam wrote: > > I've received some off-line comments from Chris regarding the iostat(1M) > change and based on this, I'd like to withdraw the iostat -n change > in behavior from this case. I'll update the materials shortly. > > Should the timer be reset on this case to give people time to review > this change, and if so, what would be appropriate? Not that I'm > expecting it to be controversial, the form of name > happens to be identical to the ucb form of name but is not > actually related to ucblinks or the /dev ucb names in any way. I don't think you need to do anything -- the case will probably be approved today. I'll +1 as specified now. - Garrett > > > -jg > > > -------------------- > > I think the '-n' change to iostat(1M) is the highest risk thing > you are proposing, and I am not in favor of this change as > specified. > > In addition to the translation problem, there are truncation > issues to resolve. I think if you look, you will find some CRs > against current 'iostat -n' causing incorrect/truncated output. > > Things look good with > > # iostat -n > tty c1t0d0 c1t1d0 c0t0d0 cpu > tin tout kps tps serv kps tps serv kps tps serv us sy wt id > 0 0 17 1 4 0 0 0 0 0 0 0 0 0 100 > > but with fabric/mpxio names current -n behavior truncates/breaks. > > # iostat c3t216000C0FF8047DDd0 c3t216000C0FF8047DDd10 > c3t216000C0FF8047DDd11 > tty sd16 ssd178 ssd182 ssd216 > cpu > tin tout kps tps serv kps tps serv kps tps serv kps tps serv us > sy wt id > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 1 0 99 > # iostat -n c3t216000C0FF8047DDd0 c3t216000C0FF8047DDd10 > c3t216000C0FF8047DDd11 > tty c0t1d0 c3t216000C0FF c3t216000C0FF c3t216000C0FF > cpu > tin tout kps tps serv kps tps serv kps tps serv kps tps serv us > sy wt id > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 1 0 99 > > > I would prefer to see a translation mechanism delivered prior > to an iostat change. With a translation mechanism in place, you > could then revisit the -n proposal in a more limited way - one that > does not cause truncation: maybe -X implies -n, or something like that > (for line-per-device type output). > > -Chris >