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
>
