(I know that this question might be more reasonable on a kernel list, but a while back I posted the question twice and got no answers.)
The acct struct is defined in /usr/include/sys/acct.h includes both ac_io and ac_rw for bytes transferred and blocks read or written, respectively. Fair and good - works (on paper) similarly to unix, solaris, hp-ux, etc.
However, in the kernel code [kernel/acct.c], ac_io (char) and ac_rw (blocks) are always set to 0 by these two lines:
ac.ac_io = encode_comp_t(0 /* current->io_usage */); ac.ac_rw = encode_comp_t(ac.ac_io / 1024);
For most purposes, this probably wouldn't be an issue, but I also do extensive performance analysis on several platforms and have written a fairly compresive accounting package (as a wraparound for psacct or as a standalone) including both an improved acctcom and a built-in reporter for it.
Does anyone know wby the kernel zero's out the bytes transferred data? (Overhead comes to mind.) Not that it makes a huge differnce for my purposes (I had to write some wraparound code to make a "best-guestimate" about the data I'm missing), but curiosity is bugging me now. When I compile my program on other OS's I get useful data for char and block i/o and I'd like to find out whether there is something obvious that I'm just totally missing here...).
Thanks
Peter Jones wrote:
Not that I've got an answer for your question, but you might want to tell your computer that it's not 2006.
William W. Austin (or possibly his ISP, Speakeasy) is actually resending mail which was originally sent back in 2006. I got 2 extra copies of a mail I already received back in 2006.
Kevin Kofler
On Thu, 19 Oct 2006 08:23:49 -0400 "William W. Austin" waustin@speakeasy.net wrote:
(I know that this question might be more reasonable on a kernel list, but a while back I posted the question twice and got no answers.)
Possibly because the system you are sending email from thinks it's 2006, so many people wouldn't notice your old post if they are sorting by date?
<snip question>
Fix your date and try the kernel list again?
kevin