Discrepancy between ps -i -o inblk and figuring numbers by hand

[Giorgos Keramidas]

On 2005-03-25 20:17, Jonathan Stewart <jonstew1983 at yahoo.com> wrote:
>--- Giorgos Keramidas <keramida at ceid.upatras.gr> wrote:
>>On 2005-03-25 10:08, Jonathan Stewart <jonstew1983 at yahoo.com> wrote:
>>>--- Giorgos Keramidas keramida at ceid dot upatras dot gr wrote:
>>>> So, what you are looking for is a single byte count that increases
>>>> sequentially for all read() and write() system calls?
>>>
>>> Pretty much, yes. To be specific all read() and write() calls for a
>>> given process.  Even something that counted in 512 byte or UFUFSlocks
>>> would be useful.
>>
>> To what end, may I ask?  Per process statistics may include byte
>> counts from a
>> few thousand threads that read and/or write from a few hundred
>> descriptors.
>>
>> Even per file descriptor statistics quickly get useless when one
>> considers
>> that a single byte read may cause the read-ahead of a few thousand
>> bytes or
>> that a single write may reach the corresponding device several
>> seconds later.
>
> As I mentioned in an earlier email my main use of this is really just
> for one program.  I can do a du to find out how much information it
> needs to read and then by watching how much it has read get a rough
> idea of how much longer it will be.  Not really a necessary feature
> just a "nice to have" kind of thing.

I can try hacking something together, but the main difficulty of making
modifications to the struct filedesc of each file descriptor is that
userlevel programs need some way of getting access to this information
too, i.e. through an ioctl() on the descriptor.