From gd78059@sac.sfbay.sun.com Fri Nov 13 14:24:49 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 nADMOmhO003969 for ; Fri, 13 Nov 2009 14:24:49 -0800 (PST) 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 nADMOXmg012250; Fri, 13 Nov 2009 22:24:48 GMT 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 <0KT200209JLADL00@brm-avmta-1.central.sun.com>; Fri, 13 Nov 2009 15:24:46 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT20098PJL9FEC0@brm-avmta-1.central.sun.com>; Fri, 13 Nov 2009 15:24:45 -0700 (MST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nADMOiNZ008208; Fri, 13 Nov 2009 14:24:44 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nADMOg1X003964; Fri, 13 Nov 2009 14:24:42 -0800 (PST) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id nADMOgro003960; Fri, 13 Nov 2009 14:24:42 -0800 (PST) Date: Fri, 13 Nov 2009 14:24:42 -0800 (PST) From: "Garrett D'Amore - sun microsystems" Subject: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] To: PSARC-ext@sun.com Cc: Dan.Mick@sun.com Message-id: <200911132224.nADMOgro003960@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3320 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: pfiles offset 1.2. Name of Document Author/Supplier: Author: Daniel Mick 1.3 Date of This Document: 13 November, 2009 4. Technical Description PROBLEM: pfiles(1) prints various information about open files in a process (the manpage describes it as fstat(2) and fcntl(2) information, as well as network endpoints, socket options, and the file path, if available). Occasionally it would be useful to see the file offset for files that support seek; for example, for long-running processes that process large files sequentially, it can be useful to discover the current position in the file to estimate time to completion. The information is readily available, and easy to output. pfiles(1) output is currently classified as Uncommitted. PROPOSAL: Add a new "offset:" output field to pfiles (in verbose mode, that is, lacking the -n switch). The field would be printed for any file that responds to lseek() with a valid offset, appearing just after the pathname (if any). Several output formats were proposed and discussed; locating just after all the other field:value items would be consistent, but would almost certainly cause linewrap, and it seems a shame to waste an entire line on one new field. Also, there's some value in having the offset near the pathname, as that's likely the reference field of interest for the offset. As an example: here is output from a login ksh process before the change: 5968: ksh Current rlimit: 256 file descriptors 0: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 rdev:24,3 O_RDWR|O_LARGEFILE /dev/pts/3 1: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 rdev:24,3 O_RDWR|O_LARGEFILE /dev/pts/3 2: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 rdev:24,3 O_RDWR|O_LARGEFILE /dev/pts/3 3: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 rdev:24,3 O_RDWR|O_LARGEFILE /dev/pts/3 10: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 rdev:24,3 O_RDWR|O_LARGEFILE FD_CLOEXEC /dev/pts/3 63: S_IFREG mode:0600 dev:400,1 ino:254311 uid:23805 gid:10 size:23938 O_RDWR|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC /home/dmick/.sh_history and here is the proposed pfiles output: 5968: ksh Current rlimit: 256 file descriptors 0: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 rdev:24,3 O_RDWR|O_LARGEFILE /dev/pts/3 offset:32577 1: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 rdev:24,3 O_RDWR|O_LARGEFILE /dev/pts/3 offset:32577 2: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 rdev:24,3 O_RDWR|O_LARGEFILE /dev/pts/3 offset:32577 3: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 rdev:24,3 O_RDWR|O_LARGEFILE /dev/pts/3 offset:32577 10: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 rdev:24,3 O_RDWR|O_LARGEFILE FD_CLOEXEC /dev/pts/3 offset:32577 63: S_IFREG mode:0600 dev:400,1 ino:254311 uid:23805 gid:10 size:24000 O_RDWR|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC /home/dmick/.sh_history offset:24000 From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Fri Nov 13 14:35:02 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 nADMZ1FA004157 for ; Fri, 13 Nov 2009 14:35:02 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nADMYxAO017437 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Nov 2009 22:35:01 GMT 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 <0KT200A01K2CAX00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Nov 2009 14:35:00 -0800 (PST) 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 <0KT20047SK2B2C50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Nov 2009 14:34:59 -0800 (PST) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nADMU88g007803 for ; Fri, 13 Nov 2009 22:34:58 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay11i.sun.com with ESMTP id BT-MMP-6629869 for PSARC-ext@sun.com; Fri, 13 Nov 2009 22:34:58 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-71437843 for PSARC-ext@sun.com; Fri, 13 Nov 2009 22:34:58 +0000 (Z) Received: from relay04-haj2.antispameurope.com ([83.246.65.54] [83.246.65.54]) by relay1i.sun.com with ESMTP id BT-MMP-31108612 for PSARC-ext@sun.com; Fri, 13 Nov 2009 22:34:57 +0000 (Z) Received: by relay04-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 49AA95EC144; Fri, 13 Nov 2009 23:34:56 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay04-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id A6C125EC13F; Fri, 13 Nov 2009 23:34:54 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id nADMYdqO018424; Fri, 13 Nov 2009 23:34:40 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Nov 2009 23:34:39 +0100 Date: Fri, 13 Nov 2009 23:32:42 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <200911132224.nADMOgro003960@sac.sfbay.sun.com> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: psarc-ext@sun.com, gd78059@sac.sfbay.sun.com Message-id: <4afdde8a.XP51izaXch5+zW1q%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== References: <200911132224.nADMOgro003960@sac.sfbay.sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 13 Nov 2009 22:34:39.0885 (UTC) FILETIME=[7CC673D0:01CA64B1] Status: RO Content-Length: 1352 "Garrett D'Amore - sun microsystems" wrote: > 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: > pfiles offset > 1.2. Name of Document Author/Supplier: > Author: Daniel Mick > 1.3 Date of This Document: > 13 November, 2009 > 4. Technical Description > > PROBLEM: > > pfiles(1) prints various information about open files in a process > (the manpage describes it as fstat(2) and fcntl(2) information, as well > as network endpoints, socket options, and the file path, if available). > > Occasionally it would be useful to see the file offset for files that > support seek; for example, for long-running processes that process large > files sequentially, it can be useful to discover the current position > in the file to estimate time to completion. The information is readily > available, and easy to output. +1, for an important feature that I did already add to "ofiles" 20 years ago ;-) Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From MAILER-DAEMON Mon Nov 16 15:20:35 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 nAGNKYm0027101 for ; Mon, 16 Nov 2009 15:20:35 -0800 (PST) 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 nAGNCVDT021662; Mon, 16 Nov 2009 23:20:31 GMT 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 <0KT800C056654500@brm-avmta-1.central.sun.com>; Mon, 16 Nov 2009 16:20:29 -0700 (MST) 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 <0KT80073R664G750@brm-avmta-1.central.sun.com>; Mon, 16 Nov 2009 16:20:29 -0700 (MST) Received: from xanadu (xanadu.SFBay.Sun.COM [129.146.228.194]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id nAGNKQZj680661; Mon, 16 Nov 2009 15:20:26 -0800 (PST) Date: Mon, 16 Nov 2009 15:20:27 -0800 From: Dan Price Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <200911132224.nADMOgro003960@sac.sfbay.sun.com> To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, Dan.Mick@sun.com Message-id: <20091116232022.GA20949@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911132224.nADMOgro003960@sac.sfbay.sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1036 On Fri 13 Nov 2009 at 02:24PM, Garrett D'Amore - sun microsystems wrote: > 63: S_IFREG mode:0600 dev:400,1 ino:254311 uid:23805 gid:10 size:24000 > O_RDWR|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC > /home/dmick/.sh_history offset:24000 +1 from me. I have wanted this many times-- I'm only sorry I didn't implement it years ago! My only question would be to Roger-- whether he intended for the filename to live alone on a line, or could offer guidance about where offset: should live. But I don't really know where else to stick this info. The first line seems to be properties of the file. The next, properties of the way the fd was opened (or fcntl'd). So, it's not obvious that either of these lines would be right either. It would help to see an example of the output for some more exotic types of things, such as sockets and doors-- I assume that for some of these, this output is elided? How about a pfiles of, say, inetd? -dp -- Daniel Price, Solaris Kernel Engineering http://blogs.sun.com/dp From Nicolas.Williams@sun.com Mon Nov 16 15:26:03 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 nAGNQ39x027162 for ; Mon, 16 Nov 2009 15:26:03 -0800 (PST) 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 nAGNQ09B008106; Mon, 16 Nov 2009 16:26:02 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT800A1Z6FDU700@nwk-avmta-1.sfbay.Sun.COM>; Mon, 16 Nov 2009 15:26:01 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT800LTJ6FDKX30@nwk-avmta-1.sfbay.Sun.COM>; Mon, 16 Nov 2009 15:26:01 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nAGNLr4w001147; Mon, 16 Nov 2009 17:21:53 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAGNLrvH001146; Mon, 16 Nov 2009 17:21:53 -0600 (CST) Date: Mon, 16 Nov 2009 17:21:53 -0600 From: Nicolas Williams Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <20091116232022.GA20949@eng.sun.com> To: Dan Price Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, Dan.Mick@sun.com Message-id: <20091116232152.GA773@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911132224.nADMOgro003960@sac.sfbay.sun.com> <20091116232022.GA20949@eng.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1076 On Mon, Nov 16, 2009 at 03:20:27PM -0800, Dan Price wrote: > On Fri 13 Nov 2009 at 02:24PM, Garrett D'Amore - sun microsystems wrote: > > 63: S_IFREG mode:0600 dev:400,1 ino:254311 uid:23805 gid:10 size:24000 > > O_RDWR|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC > > /home/dmick/.sh_history offset:24000 > > +1 from me. I have wanted this many times-- I'm only sorry I didn't > implement it years ago! My only question would be to Roger-- whether he > intended for the filename to live alone on a line, or could offer > guidance about where offset: should live. > > But I don't really know where else to stick this info. The first line > seems to be properties of the file. The next, properties of the way the > fd was opened (or fcntl'd). So, it's not obvious that either of these > lines would be right either. It'd be nice to ensure that filename whitespace does not render the format ambiguous. The proposal doesn't make the format any more ambiguous than it ever was. (Right now pfiles does not do any escaping of newlines in file names.) Nico -- From Nicolas.Williams@sun.com Mon Nov 16 15:33:24 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 nAGNXOf6027317 for ; Mon, 16 Nov 2009 15:33:24 -0800 (PST) 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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAGNXOJg012144; Mon, 16 Nov 2009 15:33:24 -0800 (PST) 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 <0KT800M056ROC200@nwk-avmta-2.sfbay.sun.com>; Mon, 16 Nov 2009 15:33:24 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT800J936RN8ND0@nwk-avmta-2.sfbay.sun.com>; Mon, 16 Nov 2009 15:33:24 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nAGNTG1e001162; Mon, 16 Nov 2009 17:29:16 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAGNTGR9001161; Mon, 16 Nov 2009 17:29:16 -0600 (CST) Date: Mon, 16 Nov 2009 17:29:16 -0600 From: Nicolas Williams Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <20091116232152.GA773@Sun.COM> To: Dan Price Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, Dan.Mick@sun.com Message-id: <20091116232915.GB773@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911132224.nADMOgro003960@sac.sfbay.sun.com> <20091116232022.GA20949@eng.sun.com> <20091116232152.GA773@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 356 Also, it'd be nice to have stable pfiles output. That would definitely require escaping some filename whitespace, but I know, that's not this case. Still, I wouldn't be surprised to see scripts built around pfiles, in which case adding offset to the lines that starts with fildes numbers is probably best (since there items are already comma-separated). From Darren.Reed@sun.com Mon Nov 16 17:11:30 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 nAH1BTfd000194 for ; Mon, 16 Nov 2009 17:11:30 -0800 (PST) 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 nAH1BIZQ009696 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 17 Nov 2009 01:11:28 GMT 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 <0KT800E0JBB4BH00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 17:11:28 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT800LPCBB3L590@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 17:11:28 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAH1BRq3025074 for ; Tue, 17 Nov 2009 01:11:27 +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.04 64bit (built Jul 2 2009)) id <0KT800500B225E00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Nov 2009 01:11:19 +0000 (GMT) Received: from [129.146.106.55] ([unknown] [129.146.106.55]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KT800180BATSA90@fe-emea-10.sun.com>; Tue, 17 Nov 2009 01:11:19 +0000 (GMT) Date: Mon, 16 Nov 2009 17:11:15 -0800 From: Darren Reed Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <200911132224.nADMOgro003960@sac.sfbay.sun.com> Sender: Darren.Reed@sun.com To: dan.mick@sun.com Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <4B01F833.6080705@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: <200911132224.nADMOgro003960@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 1627 On 11/13/09 14:24, Garrett D'Amore - sun microsystems wrote: > ... > PROBLEM: > > pfiles(1) prints various information about open files in a process > (the manpage describes it as fstat(2) and fcntl(2) information, as well > as network endpoints, socket options, and the file path, if available). > > Occasionally it would be useful to see the file offset for files that > support seek; for example, for long-running processes that process large > files sequentially, it can be useful to discover the current position > in the file to estimate time to completion. The information is readily > available, and easy to output. > > pfiles(1) output is currently classified as Uncommitted. > > PROPOSAL: > > Add a new "offset:" output field to pfiles (in verbose mode, that is, > lacking the -n switch). The field would be printed for any file that > responds to lseek() with a valid offset, appearing just after the > pathname (if any). Several output formats were proposed and discussed; > locating just after all the other field:value items would be consistent, > but would almost certainly cause linewrap, and it seems a shame to > waste an entire line on one new field. Also, there's some value in > having the offset near the pathname, as that's likely the reference > field of interest for the offset. > Is this field displayed with sockets? While sockets may not be seek'able, my experience with this kind of utility and extracting information from the kernel is that the "offset" for sockets is actually the number of bytes written (as it is for any file opened with O_TRUNC) and that can be of value. Darren From bart.smaalders@sun.com Mon Nov 16 17:29:06 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAH1T6OO000377 for ; Mon, 16 Nov 2009 17:29:06 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAH1T1Zu017450; Mon, 16 Nov 2009 17:29:04 -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-3.04 (built Jul 15 2005)) id <0KT800I0ZC4FHT00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 16 Nov 2009 17:29:03 -0800 (PST) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT800LOXC4EL5A0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 16 Nov 2009 17:29:02 -0800 (PST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id nAH1Rffu008712; Tue, 17 Nov 2009 01:27:41 +0000 (GMT) Date: Mon, 16 Nov 2009 17:26:59 -0800 From: Bart Smaalders Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <4B01F833.6080705@Sun.COM> To: Darren Reed Cc: dan.mick@sun.com, PSARC-ext@sun.com, "Garrett D'Amore - sun microsystems" Message-id: <4B01FBE3.6070704@Sun.COM> Organization: Sun Microsystems 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: <200911132224.nADMOgro003960@sac.sfbay.sun.com> <4B01F833.6080705@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 1276 Darren Reed wrote: >> Add a new "offset:" output field to pfiles (in verbose mode, that is, >> lacking the -n switch). The field would be printed for any file that >> responds to lseek() with a valid offset, appearing just after the >> pathname (if any). > Is this field displayed with sockets? > > While sockets may not be seek'able, my experience with this kind of > utility and extracting information from the kernel is that the "offset" > for sockets is actually the number of bytes written (as it is for any > file opened with O_TRUNC) and that can be of value. This would seem to depend on the behavior of sockfs, not on pfiles. http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/sockfs/sockcommon_vnops.c 460 /* 461 * Sockets are not seekable. 462 * (and there is a bug to fix STREAMS to make them fail this as well). 463 */ 464 /*ARGSUSED*/ 465 int 466 socket_vop_seek(struct vnode *vp, offset_t ooff, offset_t *noffp, 467 caller_context_t *ct) 468 { 469 return (ESPIPE); 470 } Not this case. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From dan.mick@sun.com Mon Nov 16 23:26:31 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 nAH7QVsl006281 for ; Mon, 16 Nov 2009 23:26:31 -0800 (PST) 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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAH7QVAW017437 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 16 Nov 2009 23:26:31 -0800 (PST) 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 <0KT800907SO6UT00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 23:26:30 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT800J7OSO57W80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 23:26:29 -0800 (PST) Received: from [10.1.48.101] (angus.West.Sun.COM [10.1.48.101]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAH7QTOY002764; Mon, 16 Nov 2009 23:26:29 -0800 (PST) Date: Mon, 16 Nov 2009 23:26:28 -0800 From: Dan Mick Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <20091116232022.GA20949@eng.sun.com> To: Dan Price Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <4B025024.5080105@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: <200911132224.nADMOgro003960@sac.sfbay.sun.com> <20091116232022.GA20949@eng.sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070419) Status: RO Content-Length: 2122 Dan Price wrote: > On Fri 13 Nov 2009 at 02:24PM, Garrett D'Amore - sun microsystems wrote: >> 63: S_IFREG mode:0600 dev:400,1 ino:254311 uid:23805 gid:10 size:24000 >> O_RDWR|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC >> /home/dmick/.sh_history offset:24000 > > +1 from me. I have wanted this many times-- I'm only sorry I didn't > implement it years ago! My only question would be to Roger-- whether he > intended for the filename to live alone on a line, or could offer > guidance about where offset: should live. > > But I don't really know where else to stick this info. The first line > seems to be properties of the file. The next, properties of the way the > fd was opened (or fcntl'd). So, it's not obvious that either of these > lines would be right either. > > It would help to see an example of the output for some more exotic types > of things, such as sockets and doors-- I assume that for some of these, > this output is elided? How about a pfiles of, say, inetd? > > -dp > Here are all the offsets from my inetd: /devices/pseudo/mm@0:null offset:0 /var/svc/log/network-inetd:default.log offset:0 /var/svc/log/network-inetd:default.log offset:0 /devices/pseudo/sysevent@0:sysevent offset:0 /devices/pseudo/sysevent@0:sysevent offset:0 /devices/pseudo/tl@0:ticotsord offset:0 /devices/pseudo/tl@0:ticots offset:0 /devices/pseudo/tl@0:ticotsord offset:0 /devices/pseudo/tcp@0:tcp offset:0 /devices/pseudo/tcp6@0:tcp6 offset:0 /devices/pseudo/tl@0:ticlts offset:0 /devices/pseudo/tl@0:ticotsord offset:0 /devices/pseudo/tl@0:ticotsord offset:0 /devices/pseudo/tl@0:ticlts offset:0 /devices/pseudo/udp@0:udp offset:0 /devices/pseudo/udp6@0:udp6 offset:0 /proc/1019/psinfo offset:0 so basically none of them are 'useful'. It's possible that the information that none of the devices increment a seek offset is itself useful, though, which is why I decided to output them rather than try to invent a heuristic for which dev types mattered and which didn't. From casper@holland.sun.com Tue Nov 17 01:07:26 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 nAH97PRI019937 for ; Tue, 17 Nov 2009 01:07:26 -0800 (PST) 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 nAH97MUc026371 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Tue, 17 Nov 2009 09:07:25 GMT 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 <0KT800J0VXCBNA00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 17 Nov 2009 01:07:23 -0800 (PST) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT8009XKXCAR920@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 17 Nov 2009 01:07:23 -0800 (PST) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nAH97Hp5024799; Tue, 17 Nov 2009 09:07:17 +0000 (GMT) Date: Tue, 17 Nov 2009 10:07:17 +0100 From: Casper.Dik@sun.com Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <20091116232915.GB773@Sun.COM> Sender: casper@holland.sun.com To: Nicolas Williams Cc: Dan Price , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, Dan.Mick@sun.com Message-id: <200911170907.nAH97Hp5024799@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911132224.nADMOgro003960@sac.sfbay.sun.com> <20091116232022.GA20949@eng.sun.com> <20091116232152.GA773@Sun.COM> <20091116232915.GB773@Sun.COM> Status: RO Content-Length: 1615 >Also, it'd be nice to have stable pfiles output. That would definitely >require escaping some filename whitespace, but I know, that's not this >case. Still, I wouldn't be surprised to see scripts built around >pfiles, in which case adding offset to the lines that starts with fildes >numbers is probably best (since there items are already >comma-separated). Something like having a "-p" option (like kstat) and a "-o this,and,that" like ps? E.g., the standard is: 11852: tcsh Current rlimit: 256 file descriptors 0: S_IFCHR mode:0666 dev:413,0 ino:6815752 uid:0 gid:3 rdev:13,2 O_RDONLY|O_LARGEFILE /devices/pseudo/mm@0:null 1: S_IFCHR mode:0666 dev:413,0 ino:6815752 uid:0 gid:3 rdev:13,2 O_RDONLY|O_LARGEFILE /devices/pseudo/mm@0:null 2: S_IFCHR mode:0666 dev:413,0 ino:6815752 uid:0 gid:3 rdev:13,2 O_RDONLY|O_LARGEFILE /devices/pseudo/mm@0:null 15: S_IFCHR mode:0600 dev:414,0 ino:66879962 uid:21782 gid:7 rdev:24,2 O_RDWR|O_LARGEFILE FD_CLOEXEC /dev/pts/2 16: S_IFCHR mode:0600 dev:414,0 ino:66879962 uid:21782 gid:7 rdev:24,2 O_RDWR|O_LARGEFILE FD_CLOEXEC /dev/pts/2 17: S_IFCHR mode:0600 dev:414,0 ino:66879962 uid:21782 gid:7 rdev:24,2 O_RDWR|O_LARGEFILE FD_CLOEXEC /dev/pts/2 18: S_IFCHR mode:0600 dev:414,0 ino:66879962 uid:21782 gid:7 rdev:24,2 O_RDWR|O_LARGEFILE FD_CLOEXEC /dev/pts/2 19: S_IFCHR mode:0600 dev:414,0 ino:66879962 uid:21782 gid:7 rdev:24,2 O_RDWR|O_LARGEFILE FD_CLOEXEC /dev/pts/2 and pfiles -p would produce: 11852 0 c r-- /dev/null or some such? Casper From Nicolas.Williams@sun.com Tue Nov 17 08:49:14 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 nAHGnDKA028482 for ; Tue, 17 Nov 2009 08:49:14 -0800 (PST) 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 nAHGn593020462; Tue, 17 Nov 2009 16:49:11 GMT 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 <0KT90070PIPYVQ00@brm-avmta-1.central.sun.com>; Tue, 17 Nov 2009 09:49:10 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT9004U5IPXSM20@brm-avmta-1.central.sun.com>; Tue, 17 Nov 2009 09:49:09 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nAHGj2HI001513; Tue, 17 Nov 2009 10:45:02 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAHGj2xX001512; Tue, 17 Nov 2009 10:45:02 -0600 (CST) Date: Tue, 17 Nov 2009 10:45:02 -0600 From: Nicolas Williams Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <4B025024.5080105@sun.com> To: Dan Mick Cc: Dan Price , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <20091117164501.GL773@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911132224.nADMOgro003960@sac.sfbay.sun.com> <20091116232022.GA20949@eng.sun.com> <4B025024.5080105@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 480 On Mon, Nov 16, 2009 at 11:26:28PM -0800, Dan Mick wrote: > Here are all the offsets from my inetd: > > /devices/pseudo/mm@0:null offset:0 > [...] > > so basically none of them are 'useful'. It's possible that the information > that none of the devices increment a seek offset is itself useful, though, > which is why I decided to output them rather than try to invent a heuristic > for which dev types mattered and which didn't. offset == 0 -> don't print it? From Nicolas.Williams@sun.com Tue Nov 17 08:49:40 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAHGneA1028494 for ; Tue, 17 Nov 2009 08:49:40 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAHGnbr7025924; Tue, 17 Nov 2009 08:49:38 -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-3.04 (built Jul 15 2005)) id <0KT90071PIQQ5W00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 17 Nov 2009 08:49:38 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT900LTZIOH71B0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 17 Nov 2009 08:48:17 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nAHGiAsG001505; Tue, 17 Nov 2009 10:44:10 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAHGiAdS001504; Tue, 17 Nov 2009 10:44:10 -0600 (CST) Date: Tue, 17 Nov 2009 10:44:10 -0600 From: Nicolas Williams Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <200911170907.nAH97Hp5024799@dm-holland-02.uk.sun.com> To: Casper.Dik@sun.com Cc: Dan Price , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, Dan.Mick@sun.com Message-id: <20091117164410.GK773@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911132224.nADMOgro003960@sac.sfbay.sun.com> <20091116232022.GA20949@eng.sun.com> <20091116232152.GA773@Sun.COM> <20091116232915.GB773@Sun.COM> <200911170907.nAH97Hp5024799@dm-holland-02.uk.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 939 On Tue, Nov 17, 2009 at 10:07:17AM +0100, Casper.Dik@Sun.COM wrote: > > >Also, it'd be nice to have stable pfiles output. That would definitely > >require escaping some filename whitespace, but I know, that's not this > >case. Still, I wouldn't be surprised to see scripts built around > >pfiles, in which case adding offset to the lines that starts with fildes > >numbers is probably best (since there items are already > >comma-separated). > > Something like having a "-p" option (like kstat) and a "-o this,and,that" > like ps? > > [...] > and pfiles -p would produce: > > 11852 0 c r-- /dev/null No need for fixed width columns in parseable output though... > or some such? What pfiles does now is parseable, and even roughly extensible (but for the not-escaping-newlines-in-filenames problem). I'm not proposing that we make the current output format stable, but I am proposing that we keep to its current style. Nico -- From gdamore@sun.com Wed Nov 18 07:11:26 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 nAIFBPw7007414 for ; Wed, 18 Nov 2009 07:11:26 -0800 (PST) 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 nAIFBNfS026975 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 18 Nov 2009 15:11:24 GMT 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 <0KTB00A098UZRM00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 08:11:23 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTB00MRW8UZPQ90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 08:11:23 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAIFBNPG012757 for ; Wed, 18 Nov 2009 07:11:23 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTB00A008RRNI00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 07:11:23 -0800 (PST) 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.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTB00G9G8UY9670@fe-sfbay-09.sun.com>; Wed, 18 Nov 2009 07:11:22 -0800 (PST) Date: Wed, 18 Nov 2009 07:11:22 -0800 From: "Garrett D'Amore" Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <20091117164410.GK773@Sun.COM> Sender: Garrett.Damore@sun.com To: Nicolas Williams Cc: Casper.Dik@sun.com, Dan Price , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, Dan.Mick@sun.com Message-id: <4B040E9A.8040909@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: <200911132224.nADMOgro003960@sac.sfbay.sun.com> <20091116232022.GA20949@eng.sun.com> <20091116232152.GA773@Sun.COM> <20091116232915.GB773@Sun.COM> <200911170907.nAH97Hp5024799@dm-holland-02.uk.sun.com> <20091117164410.GK773@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 464 While there has been some conversation, and it seems like folks are generally in favor of this proposal, I've not seen any actual +1s from any voting ARC members. Can I hear one please? Also, on the question of "parseable" pfiles output, I like the idea, but I think the answer is "not this case". As has been pointed out already, I don't think the changes described for this case make the output any more ambiguous than they already are. - Garrett From Darren.Moffat@Sun.COM Wed Nov 18 07:26:37 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAIFQbCC007577 for ; Wed, 18 Nov 2009 07:26:37 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAIFQZiI009723 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 18 Nov 2009 07:26:37 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KTB00C1F9KC5300@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 08:26:36 -0700 (MST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTB00MBO9KBQB90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 08:26:36 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAIFQYxi009596 for ; Wed, 18 Nov 2009 15:26:35 +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.04 64bit (built Jul 2 2009)) id <0KTB00L008OYDD00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 15:26:13 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTB000Z69JCAQ00@fe-emea-10.sun.com>; Wed, 18 Nov 2009 15:26:01 +0000 (GMT) Date: Wed, 18 Nov 2009 15:26:00 +0000 From: Darren J Moffat Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <4B040E9A.8040909@sun.com> Sender: Darren.Moffat@Sun.COM To: "Garrett D'Amore" Cc: Nicolas Williams , Casper.Dik@Sun.COM, Dan Price , "Garrett D'Amore - sun microsystems" , PSARC-ext@Sun.COM, Dan.Mick@Sun.COM Message-id: <4B041208.4060201@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: <200911132224.nADMOgro003960@sac.sfbay.sun.com> <20091116232022.GA20949@eng.sun.com> <20091116232152.GA773@Sun.COM> <20091116232915.GB773@Sun.COM> <200911170907.nAH97Hp5024799@dm-holland-02.uk.sun.com> <20091117164410.GK773@Sun.COM> <4B040E9A.8040909@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091027) Status: RO Content-Length: 1061 Garrett D'Amore wrote: > > While there has been some conversation, and it seems like folks are > generally in favor of this proposal, I've not seen any actual +1s from > any voting ARC members. Can I hear one please? Seems reasonable to me as specified, but see below. > Also, on the question of "parseable" pfiles output, I like the idea, but > I think the answer is "not this case". As has been pointed out > already, I don't think the changes described for this case make the > output any more ambiguous than they already are. Agreed not this case, but I think the proposal of putting offset: after the file name does actually make it harder to parse the existing output of pfiles(1), since today you can assume that the filename is on a line of its own. All the other non filename fields in the pfiles(1) output are on a different line to the filename. So I'd highly recommend that offset go on the same line as mode: or on its own line. If that is done then an offset of 0 should be printed for things that are seekable. -- Darren J Moffat From Joerg.Barfurth@sun.com Wed Nov 18 07:49:27 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAIFnRJ1007694 for ; Wed, 18 Nov 2009 07:49:27 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAIFnQbf023522 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 18 Nov 2009 07:49:27 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KTB00E0LAMD8X00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 08:49:25 -0700 (MST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTB00MNMAMBQ9B0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 08:49:24 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAIFnMkC029019 for ; Wed, 18 Nov 2009 15:49:23 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTB00500955OG00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 15:49:12 +0000 (GMT) Received: from [10.16.46.243] ([unknown] [10.16.46.243]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTB00ETUALT5920@fe-emea-09.sun.com>; Wed, 18 Nov 2009 15:49:05 +0000 (GMT) Date: Wed, 18 Nov 2009 16:49:05 +0100 From: =?ISO-8859-1?Q?J=F6rg_Barfurth?= Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <4B041208.4060201@Sun.COM> Sender: Joerg.Barfurth@sun.com To: Darren J Moffat Cc: "Garrett D'Amore" , Casper.Dik@sun.com, PSARC-ext@sun.com, Dan Price , "Garrett D'Amore - sun microsystems" Message-id: <4B041771.90002@sun.com> Organization: Sun Microsystems GmbH MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200911132224.nADMOgro003960@sac.sfbay.sun.com> <20091116232022.GA20949@eng.sun.com> <20091116232152.GA773@Sun.COM> <20091116232915.GB773@Sun.COM> <200911170907.nAH97Hp5024799@dm-holland-02.uk.sun.com> <20091117164410.GK773@Sun.COM> <4B040E9A.8040909@sun.com> <4B041208.4060201@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 5204 Darren J Moffat schrieb: > Garrett D'Amore wrote: >> >> While there has been some conversation, and it seems like folks are >> generally in favor of this proposal, I've not seen any actual +1s from >> any voting ARC members. Can I hear one please? > > Seems reasonable to me as specified, but see below. > >> Also, on the question of "parseable" pfiles output, I like the idea, >> but I think the answer is "not this case". As has been pointed out >> already, I don't think the changes described for this case make the >> output any more ambiguous than they already are. > > Agreed not this case, but I think the proposal of putting > offset: after the file name does actually make it harder > to parse the existing output of pfiles(1), since today you > can assume that the filename is on a line of its own. > > All the other non filename fields in the pfiles(1) output > are on a different line to the filename. So I'd highly recommend > that offset go on the same line as mode: or on its own line. > If that is done then an offset of 0 should be printed for > things that are seekable. > Someone asked for sample pfiles output for something like inetd, to see how the 'filename' line looks for things other than regular files and how socket-specific things are handled in output. The one reply there was did not show all of this. Of course this is easy to obtain, but as an additional data point, this has various kinds of files/devices/sockets, so I have included it below. This shows that socket-specific attributes, options and 'sockname: ...' go on separate lines, between the general (stat) attributes and the filename (if any). It would probably be in that style to put 'offset:' onto a new line for seekable file attributes. - Jörg Here is the sample output: # pfiles `pgrep inetd` 394: /usr/lib/inet/inetd start Current rlimit: unlimited file descriptors 0: S_IFCHR mode:0666 dev:302,0 ino:6815752 uid:0 gid:3 rdev:13,2 O_RDONLY|O_LARGEFILE /devices/pseudo/mm@0:null 1: S_IFREG mode:0644 dev:182,65538 ino:25225 uid:0 gid:0 size:686 O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE /var/svc/log/network-inetd:default.log 2: S_IFREG mode:0644 dev:182,65538 ino:25225 uid:0 gid:0 size:686 O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE /var/svc/log/network-inetd:default.log 3: S_IFIFO mode:0000 dev:300,0 ino:191 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK 4: S_IFDOOR mode:0444 dev:312,0 ino:49 uid:0 gid:0 size:0 O_RDONLY|O_LARGEFILE FD_CLOEXEC door to nscd[390] /var/run/name_service_door 5: S_IFDOOR mode:0777 dev:304,0 ino:0 uid:0 gid:0 size:0 O_RDWR FD_CLOEXEC door to svc.configd[9] 6: S_IFDOOR mode:0777 dev:304,0 ino:0 uid:0 gid:0 size:0 O_RDWR FD_CLOEXEC door to svc.configd[9] 7: S_IFIFO mode:0000 dev:300,0 ino:191 uid:0 gid:0 size:0 O_RDWR 8: S_IFCHR mode:0000 dev:302,0 ino:27698 uid:0 gid:0 rdev:152,3 O_RDWR FD_CLOEXEC /devices/pseudo/sysevent@0:sysevent 9: S_IFCHR mode:0000 dev:302,0 ino:27697 uid:0 gid:0 rdev:152,4 O_RDWR FD_CLOEXEC /devices/pseudo/sysevent@0:sysevent 10: S_IFDOOR mode:0777 dev:304,0 ino:0 uid:0 gid:0 size:0 O_RDWR FD_CLOEXEC door to inetd[394] 11: S_IFREG mode:0666 dev:305,1 ino:65539 uid:0 gid:0 size:0 O_RDWR|O_LARGEFILE /system/contract/process/template 12: S_IFSOCK mode:0666 dev:311,0 ino:16946 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_SNDBUF(16384),SO_RCVBUF(5120) sockname: AF_UNIX /var/run/.inetd.uds 13: S_IFCHR mode:0000 dev:302,0 ino:49649 uid:0 gid:0 rdev:10,23 O_RDWR /devices/pseudo/tl@0:ticotsord 14: S_IFCHR mode:0000 dev:302,0 ino:55002 uid:0 gid:0 rdev:10,26 O_RDWR /devices/pseudo/tl@0:ticots 15: S_IFCHR mode:0000 dev:302,0 ino:55003 uid:0 gid:0 rdev:10,29 O_RDWR /devices/pseudo/tl@0:ticotsord 16: S_IFCHR mode:0000 dev:302,0 ino:55000 uid:0 gid:0 rdev:42,61 O_RDWR sockname: AF_INET 0.0.0.0 port: 48976 /devices/pseudo/tcp@0:tcp 17: S_IFCHR mode:0000 dev:302,0 ino:54999 uid:0 gid:0 rdev:142,50 O_RDWR sockname: AF_INET6 :: port: 38537 /devices/pseudo/tcp6@0:tcp6 18: S_IFCHR mode:0000 dev:302,0 ino:54998 uid:0 gid:0 rdev:10,36 O_RDWR /devices/pseudo/tl@0:ticotsord 19: S_IFSOCK mode:0666 dev:311,0 ino:11841 uid:0 gid:0 size:0 O_RDWR SOCK_STREAM SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152) sockname: AF_INET6 :: port: 7008 20: S_IFSOCK mode:0666 dev:311,0 ino:36014 uid:0 gid:0 size:0 O_RDWR SOCK_DGRAM SO_REUSEADDR,SO_SNDBUF(57344),SO_RCVBUF(57344) sockname: AF_INET6 :: port: 69 -- Joerg Barfurth Phone: +49 40 23646662 Software Engineer mailto:joerg.barfurth@sun.com Desktop Technology Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/ Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering From gdamore@sun.com Wed Nov 18 07:57:11 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 nAIFvBhp008170 for ; Wed, 18 Nov 2009 07:57:11 -0800 (PST) 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 nAIFufZa001190 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 18 Nov 2009 15:57:10 GMT 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 <0KTB00A3FAZ8M500@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 07:57:08 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTB008J6AZ6JI10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 07:57:06 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAIFv6YP016332 for ; Wed, 18 Nov 2009 07:57:06 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTB00700AHX2P00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 07:57:06 -0800 (PST) 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.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTB00LRHAZ5JR60@fe-sfbay-09.sun.com>; Wed, 18 Nov 2009 07:57:05 -0800 (PST) Date: Wed, 18 Nov 2009 07:57:04 -0800 From: "Garrett D'Amore" Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <4B041208.4060201@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: Nicolas Williams , Casper.Dik@sun.com, Dan Price , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, Dan.Mick@sun.com Message-id: <4B041950.3000100@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: <200911132224.nADMOgro003960@sac.sfbay.sun.com> <20091116232022.GA20949@eng.sun.com> <20091116232152.GA773@Sun.COM> <20091116232915.GB773@Sun.COM> <200911170907.nAH97Hp5024799@dm-holland-02.uk.sun.com> <20091117164410.GK773@Sun.COM> <4B040E9A.8040909@sun.com> <4B041208.4060201@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 1525 Darren J Moffat wrote: > Garrett D'Amore wrote: >> >> While there has been some conversation, and it seems like folks are >> generally in favor of this proposal, I've not seen any actual +1s >> from any voting ARC members. Can I hear one please? > > Seems reasonable to me as specified, but see below. > >> Also, on the question of "parseable" pfiles output, I like the idea, >> but I think the answer is "not this case". As has been pointed out >> already, I don't think the changes described for this case make the >> output any more ambiguous than they already are. > > Agreed not this case, but I think the proposal of putting > offset: after the file name does actually make it harder > to parse the existing output of pfiles(1), since today you > can assume that the filename is on a line of its own. Concur with the concern... but... > > All the other non filename fields in the pfiles(1) output > are on a different line to the filename. So I'd highly recommend > that offset go on the same line as mode: or on its own line. > If that is done then an offset of 0 should be printed for > things that are seekable. If you put it on the same line as the mode:, then you wind up having to line wrap. This makes the content less usable for *human* consumers. It seems like folks writing *software* should probably not be consuming pfiles output, but possibly using procfs directly. I think this is probably a case where the separate needs of programs and humans lead to divergent design. -- Garrett From Darren.Moffat@Sun.COM Wed Nov 18 08:14:43 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 nAIGEgDx009078 for ; Wed, 18 Nov 2009 08:14:42 -0800 (PST) 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 nAIGEcYw015968 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 18 Nov 2009 16:14:41 GMT 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 <0KTB00G03BSGSZ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 09:14:40 -0700 (MST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTB00GN4BSF5V00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 09:14:39 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAIGEcxL002639 for ; Wed, 18 Nov 2009 16:14:38 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTB00E00AXGLU00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 16:14:36 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTB008ZWBS7Z960@fe-emea-09.sun.com>; Wed, 18 Nov 2009 16:14:32 +0000 (GMT) Date: Wed, 18 Nov 2009 16:14:31 +0000 From: Darren J Moffat Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <4B041950.3000100@sun.com> Sender: Darren.Moffat@Sun.COM To: "Garrett D'Amore" Cc: Nicolas Williams , Casper.Dik@Sun.COM, Dan Price , "Garrett D'Amore - sun microsystems" , PSARC-ext@Sun.COM, Dan.Mick@Sun.COM Message-id: <4B041D67.9080605@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: <200911132224.nADMOgro003960@sac.sfbay.sun.com> <20091116232022.GA20949@eng.sun.com> <20091116232152.GA773@Sun.COM> <20091116232915.GB773@Sun.COM> <200911170907.nAH97Hp5024799@dm-holland-02.uk.sun.com> <20091117164410.GK773@Sun.COM> <4B040E9A.8040909@sun.com> <4B041208.4060201@Sun.COM> <4B041950.3000100@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091027) Status: RO Content-Length: 1154 Garrett D'Amore wrote: >> All the other non filename fields in the pfiles(1) output >> are on a different line to the filename. So I'd highly recommend >> that offset go on the same line as mode: or on its own line. >> If that is done then an offset of 0 should be printed for >> things that are seekable. > > If you put it on the same line as the mode:, then you wind up having to > line wrap. This makes the content less usable for *human* consumers. But putting offset: on the filename line will make that wrap quicker too, especially for pfiles run on an editor running against an deep file tree eg: 5: S_IFREG mode:0644 dev:182,65547 ino:377482 uid:101 gid:10 size:16384 O_RDWR|O_CREAT|O_EXCL /builds/onnv-bugfixes/usr/src/cmd/cmd-crypto/elfsign/.elfsign.c.swp Thats a vim process editing a file not that deep in ON. > It seems like folks writing *software* should probably not be consuming > pfiles output, but possibly using procfs directly. Indeed but that should imply we deliberately make the output worse than it is just now, so putting offset on a new line by its own would be my preference. -- Darren J Moffat From gdamore@sun.com Wed Nov 18 09:00:50 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 nAIH0obN012975 for ; Wed, 18 Nov 2009 09:00:50 -0800 (PST) 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 nAIH0mKl004311 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 18 Nov 2009 10:00:50 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KTB00L17DXC9J00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 10:00:48 -0700 (MST) 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 <0KTB00GRLDXA5V40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 10:00:46 -0700 (MST) 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 nAIH0jtA026582 for ; Wed, 18 Nov 2009 09:00:45 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTB00A00DJA8000@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 09:00:45 -0800 (PST) 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.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTB00FQIDX3KA80@fe-sfbay-10.sun.com>; Wed, 18 Nov 2009 09:00:40 -0800 (PST) Date: Wed, 18 Nov 2009 09:00:39 -0800 From: "Garrett D'Amore" Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <4B041D67.9080605@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: Nicolas Williams , Casper.Dik@sun.com, Dan Price , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, Dan.Mick@sun.com Message-id: <4B042837.6020808@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: <200911132224.nADMOgro003960@sac.sfbay.sun.com> <20091116232022.GA20949@eng.sun.com> <20091116232152.GA773@Sun.COM> <20091116232915.GB773@Sun.COM> <200911170907.nAH97Hp5024799@dm-holland-02.uk.sun.com> <20091117164410.GK773@Sun.COM> <4B040E9A.8040909@sun.com> <4B041208.4060201@Sun.COM> <4B041950.3000100@sun.com> <4B041D67.9080605@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 1562 Darren J Moffat wrote: > Garrett D'Amore wrote: >>> All the other non filename fields in the pfiles(1) output >>> are on a different line to the filename. So I'd highly recommend >>> that offset go on the same line as mode: or on its own line. >>> If that is done then an offset of 0 should be printed for >>> things that are seekable. >> >> If you put it on the same line as the mode:, then you wind up having >> to line wrap. This makes the content less usable for *human* consumers. > > But putting offset: on the filename line will make that wrap quicker > too, especially for pfiles run on an editor running against an deep > file tree eg: > > 5: S_IFREG mode:0644 dev:182,65547 ino:377482 uid:101 gid:10 size:16384 > O_RDWR|O_CREAT|O_EXCL > /builds/onnv-bugfixes/usr/src/cmd/cmd-crypto/elfsign/.elfsign.c.swp > > Thats a vim process editing a file not that deep in ON. Good point. > >> It seems like folks writing *software* should probably not be >> consuming pfiles output, but possibly using procfs directly. > > Indeed but that should imply we deliberately make the output worse > than it is just now, so putting offset on a new line by its own would > be my preference. > Okay, well, I'll let the project team (Dan Mick) comment on this. Personally I don't have that strong a feeling; Dan I chatted for all of about 5 minutes debating where the best way to expose this was. Possibly the best solution is to introduce a parseable format, but I didn't feel comfortable volunteering Dan for the additional work. - Garrett From edward.pilatowicz@sun.com Wed Nov 18 10:07:21 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 nAII7LNl017450 for ; Wed, 18 Nov 2009 10:07:21 -0800 (PST) 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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAII7HoF026620; Wed, 18 Nov 2009 10:07:18 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KTB00511H050A00@brm-avmta-1.central.sun.com>; Wed, 18 Nov 2009 11:07:17 -0700 (MST) 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 <0KTB00GVOH046290@brm-avmta-1.central.sun.com>; Wed, 18 Nov 2009 11:07:17 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id nAII7EPt506112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 10:07:14 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id nAII7EbU506065; Wed, 18 Nov 2009 10:07:14 -0800 (PST) Date: Wed, 18 Nov 2009 10:06:44 -0800 From: Edward Pilatowicz Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <4B041D67.9080605@Sun.COM> To: Darren J Moffat Cc: "Garrett D'Amore" , Nicolas Williams , Casper.Dik@sun.com, Dan Price , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, Dan.Mick@sun.com Message-id: <20091118180643.GA493719@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911132224.nADMOgro003960@sac.sfbay.sun.com> <20091116232022.GA20949@eng.sun.com> <20091116232152.GA773@Sun.COM> <20091116232915.GB773@Sun.COM> <200911170907.nAH97Hp5024799@dm-holland-02.uk.sun.com> <20091117164410.GK773@Sun.COM> <4B040E9A.8040909@sun.com> <4B041208.4060201@Sun.COM> <4B041950.3000100@sun.com> <4B041D67.9080605@Sun.COM> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.20 (2009-06-14) Status: RO Content-Length: 1699 On Wed, Nov 18, 2009 at 04:14:31PM +0000, Darren J Moffat wrote: > Garrett D'Amore wrote: > >>All the other non filename fields in the pfiles(1) output > >>are on a different line to the filename. So I'd highly recommend > >>that offset go on the same line as mode: or on its own line. > >>If that is done then an offset of 0 should be printed for > >>things that are seekable. > > > >If you put it on the same line as the mode:, then you wind up > >having to line wrap. This makes the content less usable for > >*human* consumers. > > But putting offset: on the filename line will make that wrap quicker > too, especially for pfiles run on an editor running against an deep > file tree eg: > > 5: S_IFREG mode:0644 dev:182,65547 ino:377482 uid:101 gid:10 size:16384 > O_RDWR|O_CREAT|O_EXCL > /builds/onnv-bugfixes/usr/src/cmd/cmd-crypto/elfsign/.elfsign.c.swp > > Thats a vim process editing a file not that deep in ON. > > >It seems like folks writing *software* should probably not be > >consuming pfiles output, but possibly using procfs directly. > > Indeed but that should imply we deliberately make the output worse > than it is just now, so putting offset on a new line by its own would > be my preference. > i realize that psarc isn't a democratic form, but regardless i'll put in a vote for not having "offset:" on the same line as the filename. i do have a couple scripts that do: pfiles ... | grep " /" | ... and i guess i could update them todo: pfiles ... | grep " /" | sed 's/ offset:[0-9][0-9]*$//' but that seems like a pain. ;) i'd actually be ok with putting the offset before or after the fd flags. (where it wouldn't add an extra line of output.) ed From dan.mick@sun.com Fri Nov 20 21:54:48 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAL5smMg011337 for ; Fri, 20 Nov 2009 21:54:48 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAL5slmH016893 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 20 Nov 2009 21:54:47 -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-3.04 (built Jul 15 2005)) id <0KTG0030133B1F00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 20 Nov 2009 21:54:47 -0800 (PST) Received: from dm-eng-01.sfbay.sun.com ([129.145.155.198]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTG00APF33BB9C0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 20 Nov 2009 21:54:47 -0800 (PST) Received: from [10.1.48.101] (angus.West.Sun.COM [10.1.48.101]) by dm-eng-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAL5skh2002989; Fri, 20 Nov 2009 21:54:46 -0800 (PST) Date: Fri, 20 Nov 2009 21:54:46 -0800 From: Dan Mick Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <20091117164501.GL773@Sun.COM> To: Nicolas Williams Cc: Dan Price , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <4B0780A6.1000206@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: <200911132224.nADMOgro003960@sac.sfbay.sun.com> <20091116232022.GA20949@eng.sun.com> <4B025024.5080105@sun.com> <20091117164501.GL773@Sun.COM> User-Agent: Thunderbird 2.0.0.0 (X11/20070419) Status: RO Content-Length: 623 Nicolas Williams wrote: > On Mon, Nov 16, 2009 at 11:26:28PM -0800, Dan Mick wrote: >> Here are all the offsets from my inetd: >> >> /devices/pseudo/mm@0:null offset:0 >> [...] >> >> so basically none of them are 'useful'. It's possible that the information >> that none of the devices increment a seek offset is itself useful, though, >> which is why I decided to output them rather than try to invent a heuristic >> for which dev types mattered and which didn't. > > offset == 0 -> don't print it? might well be relevant for seekable files. "why hasn't this process read anything from its input yet"? From dan.mick@sun.com Fri Nov 20 21:56:52 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 nAL5uqio011457 for ; Fri, 20 Nov 2009 21:56:52 -0800 (PST) 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.4) with ESMTP id nAL5upa2054683; Fri, 20 Nov 2009 22:56:51 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KTG0000136R3S00@brm-avmta-1.central.sun.com>; Fri, 20 Nov 2009 22:56:51 -0700 (MST) Received: from dm-eng-01.sfbay.sun.com ([129.145.155.198]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTG00EFA36QPX80@brm-avmta-1.central.sun.com>; Fri, 20 Nov 2009 22:56:50 -0700 (MST) Received: from [10.1.48.101] (angus.West.Sun.COM [10.1.48.101]) by dm-eng-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAL5ulOG003326; Fri, 20 Nov 2009 21:56:47 -0800 (PST) Date: Fri, 20 Nov 2009 21:56:47 -0800 From: Dan Mick Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <20091118180643.GA493719@eng.sun.com> To: Edward Pilatowicz Cc: Darren J Moffat , "Garrett D'Amore" , Nicolas Williams , Casper.Dik@sun.com, Dan Price , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <4B07811F.2020801@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: <200911132224.nADMOgro003960@sac.sfbay.sun.com> <20091116232022.GA20949@eng.sun.com> <20091116232152.GA773@Sun.COM> <20091116232915.GB773@Sun.COM> <200911170907.nAH97Hp5024799@dm-holland-02.uk.sun.com> <20091117164410.GK773@Sun.COM> <4B040E9A.8040909@sun.com> <4B041208.4060201@Sun.COM> <4B041950.3000100@sun.com> <4B041D67.9080605@Sun.COM> <20091118180643.GA493719@eng.sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070419) Status: RO Content-Length: 1506 >> putting offset on a new line by its own would >> be my preference. >> > > i realize that psarc isn't a democratic form, but regardless i'll put in > a vote for not having "offset:" on the same line as the filename. I don't care all that much. For the majority of outputs, "next to filename" is most useful to me, but "on a separate line" is fine as long as it's close to the filename (and is what I originally had, actually). Reproposed output form for consensus, and then I'll resend the entire fasttrack: dmick@angus> pfiles/i386/pfiles $$ 1237: ksh Current rlimit: 256 file descriptors 0: S_IFCHR mode:0620 dev:387,0 ino:1554593710 uid:23805 gid:7 rdev:24,1 O_RDWR|O_LARGEFILE /dev/pts/1 offset:1469081 1: S_IFCHR mode:0620 dev:387,0 ino:1554593710 uid:23805 gid:7 rdev:24,1 O_RDWR|O_LARGEFILE /dev/pts/1 offset:1469081 2: S_IFCHR mode:0620 dev:387,0 ino:1554593710 uid:23805 gid:7 rdev:24,1 O_RDWR|O_LARGEFILE /dev/pts/1 offset:1469081 3: S_IFCHR mode:0620 dev:387,0 ino:1554593710 uid:23805 gid:7 rdev:24,1 O_RDWR|O_LARGEFILE /dev/pts/1 offset:1469081 10: S_IFCHR mode:0620 dev:387,0 ino:1554593710 uid:23805 gid:7 rdev:24,1 O_RDWR|O_LARGEFILE FD_CLOEXEC /dev/pts/1 offset:1469081 63: S_IFREG mode:0600 dev:400,1 ino:254311 uid:23805 gid:10 size:44836 O_RDWR|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC /home/dmick/.sh_history offset:44836 From Darren.Moffat@Sun.COM Mon Nov 23 04:13:22 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nANCDMuX000324 for ; Mon, 23 Nov 2009 04:13:22 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nANCDMSG022566 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 23 Nov 2009 04:13:22 -0800 (PST) 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 <0KTK00I019YAAG00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 23 Nov 2009 04:13:22 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTK00F8D9Y9GK30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 23 Nov 2009 04:13:21 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nANCDKla003877 for ; Mon, 23 Nov 2009 12:13:20 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTK00F009JPBQ00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 23 Nov 2009 12:13:11 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTK00GHC9XTVX60@fe-emea-09.sun.com>; Mon, 23 Nov 2009 12:13:05 +0000 (GMT) Date: Mon, 23 Nov 2009 12:13:04 +0000 From: Darren J Moffat Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <4B07811F.2020801@sun.com> Sender: Darren.Moffat@Sun.COM To: Dan Mick Cc: Edward Pilatowicz , "Garrett D'Amore" , Nicolas Williams , Casper.Dik@Sun.COM, Dan Price , "Garrett D'Amore - sun microsystems" , PSARC-ext@Sun.COM Message-id: <4B0A7C50.80105@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: <200911132224.nADMOgro003960@sac.sfbay.sun.com> <20091116232022.GA20949@eng.sun.com> <20091116232152.GA773@Sun.COM> <20091116232915.GB773@Sun.COM> <200911170907.nAH97Hp5024799@dm-holland-02.uk.sun.com> <20091117164410.GK773@Sun.COM> <4B040E9A.8040909@sun.com> <4B041208.4060201@Sun.COM> <4B041950.3000100@sun.com> <4B041D67.9080605@Sun.COM> <20091118180643.GA493719@eng.sun.com> <4B07811F.2020801@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091027) Status: RO Content-Length: 842 Dan Mick wrote: > >> putting offset on a new line by its own would >>> be my preference. >>> >> >> i realize that psarc isn't a democratic form, but regardless i'll put in >> a vote for not having "offset:" on the same line as the filename. > > I don't care all that much. For the majority of outputs, "next to > filename" is most useful to me, but "on a separate line" is fine as long > as it's close to the filename (and is what I originally had, actually). > > Reproposed output form for consensus, and then I'll resend the entire > fasttrack: > > dmick@angus> pfiles/i386/pfiles $$ > 1237: ksh > Current rlimit: 256 file descriptors > 0: S_IFCHR mode:0620 dev:387,0 ino:1554593710 uid:23805 gid:7 rdev:24,1 > O_RDWR|O_LARGEFILE > /dev/pts/1 > offset:1469081 That looks great to me. -- Darren J Moffat From dan.mick@sun.com Mon Nov 23 18:52:05 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAO2q5dU009757 for ; Mon, 23 Nov 2009 18:52:05 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAO2q33v027859; Mon, 23 Nov 2009 20:52:05 -0600 (CST) 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 <0KTL00317EMS9Z00@nwk-avmta-2.sfbay.sun.com>; Mon, 23 Nov 2009 18:52:04 -0800 (PST) Received: from dm-eng-01.sfbay.sun.com ([129.145.155.198]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTL002VZEMR5350@nwk-avmta-2.sfbay.sun.com>; Mon, 23 Nov 2009 18:52:03 -0800 (PST) Received: from [10.1.48.101] (angus.West.Sun.COM [10.1.48.101]) by dm-eng-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAO2pxBA027755; Mon, 23 Nov 2009 18:51:59 -0800 (PST) Date: Mon, 23 Nov 2009 18:51:59 -0800 From: Dan Mick Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <4B0A7C50.80105@Sun.COM> To: PSARC-ext@sun.com Cc: Darren J Moffat , Edward Pilatowicz , "Garrett D'Amore" , Nicolas Williams , Casper.Dik@sun.com, Dan Price , "Garrett D'Amore - sun microsystems" Message-id: <4B0B4A4F.80006@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: <200911132224.nADMOgro003960@sac.sfbay.sun.com> <20091116232022.GA20949@eng.sun.com> <20091116232152.GA773@Sun.COM> <20091116232915.GB773@Sun.COM> <200911170907.nAH97Hp5024799@dm-holland-02.uk.sun.com> <20091117164410.GK773@Sun.COM> <4B040E9A.8040909@sun.com> <4B041208.4060201@Sun.COM> <4B041950.3000100@sun.com> <4B041D67.9080605@Sun.COM> <20091118180643.GA493719@eng.sun.com> <4B07811F.2020801@sun.com> <4B0A7C50.80105@Sun.COM> User-Agent: Thunderbird 2.0.0.0 (X11/20070419) Status: RO Content-Length: 3576 Revised proposal. I presume this restarts the timer?... 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: pfiles offset 1.2. Name of Document Author/Supplier: Author: Daniel Mick 1.3 Date of This Document: 23 November, 2009 4. Technical Description PROBLEM: pfiles(1) prints various information about open files in a process (the manpage describes it as fstat(2) and fcntl(2) information, as well as network endpoints, socket options, and the file path, if available). Occasionally it would be useful to see the file offset for files that support seek; for example, for long-running processes that process large files sequentially, it can be useful to discover the current position in the file to estimate time to completion. The information is readily available, and easy to output. pfiles(1) output is currently classified as Uncommitted. PROPOSAL: Add a new "offset:" output field to pfiles (in verbose mode, that is, lacking the -n switch). The field would be printed for any file that responds to lseek() with a valid offset, appearing on its own line after the pathname (if any). Several output formats were proposed and discussed; locating just after all the other field:value items would be consistent, but would almost certainly cause linewrap. Several people wished for the pathname to remain alone on its line, for two reasons: 1) parsing ease, and 2) the pathname may well grow long, and offset: would wrap anyway. There's some value in having the offset near the pathname, as that's likely the reference field of interest for the offset. As an example: here is output from a login ksh process before the change: 5968: ksh Current rlimit: 256 file descriptors 0: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 rdev:24,3 O_RDWR|O_LARGEFILE /dev/pts/3 1: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 rdev:24,3 O_RDWR|O_LARGEFILE /dev/pts/3 2: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 rdev:24,3 O_RDWR|O_LARGEFILE /dev/pts/3 3: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 rdev:24,3 O_RDWR|O_LARGEFILE /dev/pts/3 10: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 rdev:24,3 O_RDWR|O_LARGEFILE FD_CLOEXEC /dev/pts/3 63: S_IFREG mode:0600 dev:400,1 ino:254311 uid:23805 gid:10 size:23938 O_RDWR|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC /home/dmick/.sh_history and here is the proposed pfiles output: 5968: ksh Current rlimit: 256 file descriptors 0: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 rdev:24,3 O_RDWR|O_LARGEFILE /dev/pts/3 offset:32577 1: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 rdev:24,3 O_RDWR|O_LARGEFILE /dev/pts/3 offset:32577 2: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 rdev:24,3 O_RDWR|O_LARGEFILE /dev/pts/3 offset:32577 3: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 rdev:24,3 O_RDWR|O_LARGEFILE /dev/pts/3 offset:32577 10: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 rdev:24,3 O_RDWR|O_LARGEFILE FD_CLOEXEC /dev/pts/3 offset:32577 63: S_IFREG mode:0600 dev:400,1 ino:254311 uid:23805 gid:10 size:24000 O_RDWR|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC /home/dmick/.sh_history offset:24000 From gdamore@sun.com Tue Nov 24 01:34:13 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAO9YDsZ029459 for ; Tue, 24 Nov 2009 01:34:13 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAO9YC60013186 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 24 Nov 2009 03:34:12 -0600 (CST) 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 <0KTL0040DX90KR00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Nov 2009 01:34:12 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTL00FYKX8ZWG40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Nov 2009 01:34:11 -0800 (PST) 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 nAO9YBXT009069 for ; Tue, 24 Nov 2009 01:34:11 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTL00500X85U100@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Nov 2009 01:34:11 -0800 (PST) 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.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTL006O5X8YSR90@fe-sfbay-10.sun.com>; Tue, 24 Nov 2009 01:34:11 -0800 (PST) Date: Tue, 24 Nov 2009 01:34:10 -0800 From: "Garrett D'Amore" Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <4B0B4A4F.80006@sun.com> Sender: Garrett.Damore@sun.com To: Dan Mick Cc: PSARC-ext@sun.com, Darren J Moffat , Edward Pilatowicz , Nicolas Williams , Casper.Dik@sun.com, Dan Price , "Garrett D'Amore - sun microsystems" Message-id: <4B0BA892.80802@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: <200911132224.nADMOgro003960@sac.sfbay.sun.com> <20091116232022.GA20949@eng.sun.com> <20091116232152.GA773@Sun.COM> <20091116232915.GB773@Sun.COM> <200911170907.nAH97Hp5024799@dm-holland-02.uk.sun.com> <20091117164410.GK773@Sun.COM> <4B040E9A.8040909@sun.com> <4B041208.4060201@Sun.COM> <4B041950.3000100@sun.com> <4B041D67.9080605@Sun.COM> <20091118180643.GA493719@eng.sun.com> <4B07811F.2020801@sun.com> <4B0A7C50.80105@Sun.COM> <4B0B4A4F.80006@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 3966 Dan Mick wrote: > Revised proposal. I presume this restarts the timer?... No need to restart the timer. In fact, technically with a +1 on the revisions, we're probably done, but I'd prefer to wait until at least Wednesday before we close anything officially. - Garrett > > 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: > pfiles offset > 1.2. Name of Document Author/Supplier: > Author: Daniel Mick > 1.3 Date of This Document: > 23 November, 2009 > 4. Technical Description > > PROBLEM: > > pfiles(1) prints various information about open files in a process > (the manpage describes it as fstat(2) and fcntl(2) information, as well > as network endpoints, socket options, and the file path, if available). > > Occasionally it would be useful to see the file offset for files that > support seek; for example, for long-running processes that process large > files sequentially, it can be useful to discover the current position > in the file to estimate time to completion. The information is readily > available, and easy to output. > > pfiles(1) output is currently classified as Uncommitted. > > PROPOSAL: > > Add a new "offset:" output field to pfiles (in verbose mode, that is, > lacking the -n switch). The field would be printed for any file that > responds to lseek() with a valid offset, appearing on its own line after > the pathname (if any). Several output formats were proposed and > discussed; > locating just after all the other field:value items would be consistent, > but would almost certainly cause linewrap. Several people wished for the > pathname to remain alone on its line, for two reasons: 1) parsing > ease, and > 2) the pathname may well grow long, and offset: would wrap anyway. > There's some value in having the offset near the pathname, as that's > likely the reference field of interest for the offset. > > As an example: here is output from a login ksh process before the change: > > 5968: ksh > Current rlimit: 256 file descriptors > 0: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 > rdev:24,3 > O_RDWR|O_LARGEFILE > /dev/pts/3 > 1: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 > rdev:24,3 > O_RDWR|O_LARGEFILE > /dev/pts/3 > 2: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 > rdev:24,3 > O_RDWR|O_LARGEFILE > /dev/pts/3 > 3: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 > rdev:24,3 > O_RDWR|O_LARGEFILE > /dev/pts/3 > 10: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 > rdev:24,3 > O_RDWR|O_LARGEFILE FD_CLOEXEC > /dev/pts/3 > 63: S_IFREG mode:0600 dev:400,1 ino:254311 uid:23805 gid:10 size:23938 > O_RDWR|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC > /home/dmick/.sh_history > > and here is the proposed pfiles output: > > 5968: ksh > Current rlimit: 256 file descriptors > 0: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 > rdev:24,3 > O_RDWR|O_LARGEFILE > /dev/pts/3 > offset:32577 > 1: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 > rdev:24,3 > O_RDWR|O_LARGEFILE > /dev/pts/3 > offset:32577 > 2: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 > rdev:24,3 > O_RDWR|O_LARGEFILE > /dev/pts/3 > offset:32577 > 3: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 > rdev:24,3 > O_RDWR|O_LARGEFILE > /dev/pts/3 > offset:32577 > 10: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 > rdev:24,3 > O_RDWR|O_LARGEFILE FD_CLOEXEC > /dev/pts/3 > offset:32577 > 63: S_IFREG mode:0600 dev:400,1 ino:254311 uid:23805 gid:10 size:24000 > O_RDWR|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC > /home/dmick/.sh_history > offset:24000 From gdamore@sun.com Wed Dec 2 17:00:06 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 nB3105fm005690 for ; Wed, 2 Dec 2009 17:00:05 -0800 (PST) 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.4) with ESMTP id nB3104No034347 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Dec 2009 18:00:05 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KU100M0VXG4RN00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 17:00:04 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KU100FSQXG49OC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 17:00:04 -0800 (PST) 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 nB3104AG016589 for ; Wed, 02 Dec 2009 17:00:04 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KU100A00XBVSH00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 17:00:03 -0800 (PST) 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.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KU1009M8XG1D790@fe-sfbay-10.sun.com>; Wed, 02 Dec 2009 17:00:03 -0800 (PST) Date: Wed, 02 Dec 2009 17:00:01 -0800 From: "Garrett D'Amore" Subject: Re: pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009] In-reply-to: <4B0BA892.80802@sun.com> Sender: Garrett.Damore@sun.com To: Dan Mick Cc: PSARC-ext@sun.com, Darren J Moffat , Edward Pilatowicz , Nicolas Williams , Casper.Dik@sun.com, Dan Price , "Garrett D'Amore - sun microsystems" Message-id: <4B170D91.3050109@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: <200911132224.nADMOgro003960@sac.sfbay.sun.com> <20091116232022.GA20949@eng.sun.com> <20091116232152.GA773@Sun.COM> <20091116232915.GB773@Sun.COM> <200911170907.nAH97Hp5024799@dm-holland-02.uk.sun.com> <20091117164410.GK773@Sun.COM> <4B040E9A.8040909@sun.com> <4B041208.4060201@Sun.COM> <4B041950.3000100@sun.com> <4B041D67.9080605@Sun.COM> <20091118180643.GA493719@eng.sun.com> <4B07811F.2020801@sun.com> <4B0A7C50.80105@Sun.COM> <4B0B4A4F.80006@sun.com> <4B0BA892.80802@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 4168 This case was approved at PSARC today. - Garrett Garrett D'Amore wrote: > Dan Mick wrote: >> Revised proposal. I presume this restarts the timer?... > > No need to restart the timer. In fact, technically with a +1 on the > revisions, we're probably done, but I'd prefer to wait until at least > Wednesday before we close anything officially. > > - Garrett >> >> 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: >> pfiles offset >> 1.2. Name of Document Author/Supplier: >> Author: Daniel Mick >> 1.3 Date of This Document: >> 23 November, 2009 >> 4. Technical Description >> >> PROBLEM: >> >> pfiles(1) prints various information about open files in a process >> (the manpage describes it as fstat(2) and fcntl(2) information, as well >> as network endpoints, socket options, and the file path, if available). >> >> Occasionally it would be useful to see the file offset for files that >> support seek; for example, for long-running processes that process large >> files sequentially, it can be useful to discover the current position >> in the file to estimate time to completion. The information is readily >> available, and easy to output. >> >> pfiles(1) output is currently classified as Uncommitted. >> >> PROPOSAL: >> >> Add a new "offset:" output field to pfiles (in verbose mode, that is, >> lacking the -n switch). The field would be printed for any file that >> responds to lseek() with a valid offset, appearing on its own line after >> the pathname (if any). Several output formats were proposed and >> discussed; >> locating just after all the other field:value items would be consistent, >> but would almost certainly cause linewrap. Several people wished for >> the >> pathname to remain alone on its line, for two reasons: 1) parsing >> ease, and >> 2) the pathname may well grow long, and offset: would wrap anyway. >> There's some value in having the offset near the pathname, as that's >> likely the reference field of interest for the offset. >> >> As an example: here is output from a login ksh process before the >> change: >> >> 5968: ksh >> Current rlimit: 256 file descriptors >> 0: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 >> rdev:24,3 >> O_RDWR|O_LARGEFILE >> /dev/pts/3 >> 1: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 >> rdev:24,3 >> O_RDWR|O_LARGEFILE >> /dev/pts/3 >> 2: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 >> rdev:24,3 >> O_RDWR|O_LARGEFILE >> /dev/pts/3 >> 3: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 >> rdev:24,3 >> O_RDWR|O_LARGEFILE >> /dev/pts/3 >> 10: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 >> rdev:24,3 >> O_RDWR|O_LARGEFILE FD_CLOEXEC >> /dev/pts/3 >> 63: S_IFREG mode:0600 dev:400,1 ino:254311 uid:23805 gid:10 size:23938 >> O_RDWR|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC >> /home/dmick/.sh_history >> >> and here is the proposed pfiles output: >> >> 5968: ksh >> Current rlimit: 256 file descriptors >> 0: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 >> rdev:24,3 >> O_RDWR|O_LARGEFILE >> /dev/pts/3 >> offset:32577 >> 1: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 >> rdev:24,3 >> O_RDWR|O_LARGEFILE >> /dev/pts/3 >> offset:32577 >> 2: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 >> rdev:24,3 >> O_RDWR|O_LARGEFILE >> /dev/pts/3 >> offset:32577 >> 3: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 >> rdev:24,3 >> O_RDWR|O_LARGEFILE >> /dev/pts/3 >> offset:32577 >> 10: S_IFCHR mode:0620 dev:387,0 ino:1560118988 uid:23805 gid:7 >> rdev:24,3 >> O_RDWR|O_LARGEFILE FD_CLOEXEC >> /dev/pts/3 >> offset:32577 >> 63: S_IFREG mode:0600 dev:400,1 ino:254311 uid:23805 gid:10 size:24000 >> O_RDWR|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC >> /home/dmick/.sh_history >> offset:24000 >