Subject: disk transfer byte counting


In response to recent mail from augustss@cs.chalmers.se, I've done some poking
about in order to check the disk transfer byte counting.  Lennart submitted
a bug report kern/2669, in which he notes that iostat produces (on an sd disk)
transfer values about 1/2 of what he expects.  As I did the update of iostat
to use jason's subr_disk routines, I took a look into the matter.

Indeed, the reported value of bytes copied is not what one would expect.  My
test case is: "dd if=source of=/tmp/FOO bs=1024 count=1024"; copying roughly
1 meg of data.  My /tmp is not MFS.

The raw # of bytes returned from the kernel seems wrong.  If I copy a 1 meg 
file, the counters should update by 1 meg, yes?  Here is the result of a copy
of ~1meg on i386/fd:

start: 
gabriella# obj/iostat -Id fd0 1
A: 17969174             fd0 
   K/t xfr Mb   
 15.10 1162 17.14 
A: 17969174  15.10 1162 17.14 
A: 17969174  15.10 1162 17.14 
A: 17969174  15.10 1162 17.14 
A: 17969174  15.10 1162 17.14 
A: 17989648  15.08 1165 17.16 
A: 18108401  15.06 1174 17.27 
A: 18177970  15.04 1180 17.34 
A: 18292549             fd0 
   K/t xfr Mb   
 15.05 1187 17.45 
A: 18407116  15.06 1194 17.55 
A: 18538039  15.06 1202 17.68 
A: 18701674  15.07 1212 17.84 
A: 18816206  15.07 1219 17.94 
A: 18947089  15.08 1227 18.07 
A: 19110674  15.09 1237 18.23 
A: 19212879  15.08 1244 18.32 
A: 19343714  15.09 1252 18.45 
A: 19507239  15.10 1262 18.60 
A: 19621694  15.10 1269 18.71 
A: 19752489  15.11 1277 18.84 
A: 19915964  15.11 1287 18.99 
A: 20046729  15.12 1295 19.12 
A: 20177482  15.12 1303 19.24 
A: 20312268  15.12 1312 19.37 
A: 20442985  15.12 1320 19.50 
A: 20557353  15.13 1327 19.61 
A: 20720718  15.13 1337 19.76 
A: 20851395  15.14 1345 19.89 
A: 20965728             fd0 
   K/t xfr Mb   
 15.14 1352 19.99 
A: 21129043  15.15 1362 20.15 
A: 21231056  15.14 1369 20.25 
A: 21361673  15.15 1377 20.37 
A: 21508602  15.15 1386 20.51 
A: 21639191  15.16 1394 20.64 
A: 21769768  15.16 1402 20.76 
A: 21916652  15.17 1411 20.90 
A: 22034913  15.16 1419 21.01 
A: 22116807  15.17 1424 21.09 
A: 22264204  15.17 1433 21.23 
A: 22407488  15.17 1442 21.37 
A: 22440226  15.16 1446 21.40 
A: 22440226  15.16 1446 21.40 

The first #, "A:" is the return value of bytes from the kernel.  Notice that
from start to finish, the kernel seems to xfer 22440226 - 17969174 = 
4471052 bytes?  4 meg?  disk_unbusy() doesn't do anything interesting at all
so it must be the fault of the routines calling disk_unbusy().  Comments?

-j

--TAA15627.839041142/gabriella.abattoir.com--