Does anyone know if it's possible to make lsof (or any other utility) print file descriptor offsets under Linux? It seems like this ought to work, it being 2004 and all.
Gerald Combs wrote:
Does anyone know if it's possible to make lsof (or any other utility) print file descriptor offsets under Linux? It seems like this ought to work, it being 2004 and all.
I'm interested in knowing this as well. Some Googling hasn't turned up anything useful, so far. Just to be clear, you want to know what byte offset that a particular file descriptor for a particular process is sitting at, right?
On Tue, November 2, 2004 12:44 pm, Jason Clinton said:
Gerald Combs wrote:
Does anyone know if it's possible to make lsof (or any other utility) print file descriptor offsets under Linux? It seems like this ought to work, it being 2004 and all.
I'm interested in knowing this as well. Some Googling hasn't turned up anything useful, so far. Just to be clear, you want to know what byte offset that a particular file descriptor for a particular process is sitting at, right?
$ lsof -o > /dev/null lsof: WARNING: can't report offset; disregarding -o.
From the manpage:
-o This option directs lsof to display file offset at all times. It causes the SIZE/OFF output column title to be changed to OFFSET. Note: on some UNIX dialects lsof can't obtain accu- rate or consistent file offset information from its kernel data sources, sometimes just for particular kinds of files (e.g., socket files.) Consult the lsof FAQ (The FAQ section gives its location.) for more information.
The -o and -s options are mutually exclusive; they can't both be specified. When neither is specified, lsof displays what- ever value - size or offset - is appropriate and available for the type of the file.
From the FAQ: http://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/lsof/FAQ
3.20 Why doesn't lsof report file offset (position)?
Lsof won't report a file offset (position) value if the -s option has been specified, or if the dialect doesn't support the displaying of file offset (position).
That lsof is reporting only file size is indicated by the fact that the appropriate column header says SIZE instead of SIZE/OFF.
If lsof doesn't support the displaying of file offset (position) -- e.g., for Linux /proc-based lsof -- the -h or -? output panel won't list the -o option.
Sometimes the availability of file offset information depends on the dialect's kernel. This is particularly true for socket file offsets.
Maintenance of offsets for pseudo-terminal devices varies by UNIX dialect and is related to how the dialect kernel implements pseudo-terminal support. Kernels like AIX, for example, that short-circuit the transfer of data between socket and pseudo devices to reduce TCP/IP daemon interrupt rates won't advance offsets in the TCP/IP daemon socket files. Instead they will advance offsets in the open standard I/O files of the shell child precess where the pseudo-terminal devices are used.
When in doubt about the behavior of lsof in reporting file offset information, do some carefully measured experiments, consult the lsof sources, or contact me at [email protected] to discuss the matter. Please follow the reporting guidelines in the "How do I report an lsof bug?" section of this FAQ.
I'm guessing maybe there's something involved in the kernel?
Jeremy
Jason Clinton wrote:
I'm interested in knowing this as well. Some Googling hasn't turned up anything useful, so far. Just to be clear, you want to know what byte offset that a particular file descriptor for a particular process is sitting at, right?
Exactly. If I'm waiting on tar to extract three files from the middle of a multi-gigabyte archive, I want to know how far into the file it is so that I can adjust my patience level accordingly. I was able to get offsets for regular file descriptors, special devices (e.g. tape drives, which is _really_ handy) and even sockets under Solaris 10 years ago. What's taking Linux so long?
While we're on the subject, why doesn't "top" under Linux print I/O wait statistics, like its Solaris counterpart does? Have a look at the CPU lines in the following:
Linux:
top - 13:41:07 up 69 days, 3:24, 1 user, load average: 0.10, 0.11, 0.12 Tasks: 260 total, 1 running, 259 sleeping, 0 stopped, 0 zombie Cpu(s): 0.8% user, 3.1% system, 0.0% nice, 96.1% idle Mem: 1550600k total, 1468416k used, 82184k free, 0k buffers Swap: 996020k total, 66568k used, 929452k free, 1147744k cached
Solaris:
load averages: 0.32, 0.24, 0.23 13:41:36 91 processes: 88 sleeping, 1 running, 2 on cpu CPU states: 50.5% idle, 45.0% user, 4.4% kernel, 0.1% iowait, 0.0% swap Memory: 512M real, 119M free, 757M swap in use, 1637M swap free
If the system is having performance problems, a high "iowait" tells me at a glance if the problem is disk-bound vs CPU-bound.