dd block size deficiency (bug or feature ?)

[Oskar Schirmer]

Hello,

we are using the dd command on a gnu/linux box (kernel 2.4.21 something)
as follows, to generate a specific flash prom image with
defined length (8*21 kbyte):

$ cat bigfile | dd of=/tmp/xyz bs=8k count=21


this normally results in a file with a correct size, it says:

21+0 records in
21+0 records out
$ ls -l /tmp/xyz
-rw-r-----    1 oschirm  emlix      172032 Jun 17 11:17 xyz


but, on rare occasions, it says something like:
19+2 records in
19+2 records out
$ ls -l /tmp/xyz
-rw-r-----    1 oschirm  emlix      160060 Jun 17 11:17 xyz


Looking at strace, we found that the last to read(2) system calls
where deficient, which is ok according to the definition of read(2):

"\2606\0\0\27\n3\0\0\0\0\0\230:\0\0\10\0023\0\0\0\0\0\200"..., 8192) = 8192
 "\2606\0\0\27\n3\0\0\0\0\0\230:\0\0\10\0023\0\0\0\0\0\200"..., 8192) = 8192
"\31\20\20\23\24\32\26\26\26\26\26\33\20\20\20\20\34\27"..., 8192) = 8192
 "\31\20\20\23\24\32\26\26\26\26\26\33\20\20\20\20\34\27"..., 8192) = 8192
"0\0\362\241\350\0\362\241\3\0\0\0\1\0\0\0\360\322\360\241"..., 8192) = 316
 "0\0\362\241\350\0\362\241\3\0\0\0\1\0\0\0\360\322\360\241"..., 316) = 316
"\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 8192) = 4096
 "\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 4096) = 4096
 "19+2 records in\n", 16)       = 16
 "19+2 records out\n", 17)      = 17


The immediate cause for this, so it seems, is random context switches
that occur prior to full 8k are available. Just a thought.
Now for the deeper reason:


Having a closer look to the coreutils sources, we found that in
src/dd.c the function "safe_read" is used to read blocks, while
for writing "full_write" is used. Provided we understood it right,
"safe_read" does a single device access attempt, while "full_read"
would reattempt to receive more data, when the first read was short.

Question 1:
  should dd.c use "full_read" instead of "safe_read" ?

We are aware, that dd is historically used for tape/disk access etc,
where block sizes and "short block results" might be a feature, so
maybe old software might break, when dd is changed here.

On the other hand, we cant see how decisions were taken, when
to use "safe_read" and when to use "full_read".

Question 2:
  should other tools in coreutils use "full_read" instead of "safe_read" ?
  It seems, that "safe_write" is no longer used, in favor of "full_write".

Question 3:
  If not so, should there be a command line option (something --fullread),
  to let the user select the method? (Answer probably no).

Question 4:
  Should we send a patch, for one or more answers 1 thru 3 given "yes" ?


Thanks a lot,
  Oskar Schirmer
-- 
oskar schirmer, emlix gmbh, http://www.emlix.com, mailto:address@hidden
fon +49 551 37000-37, fax -38, keplerstraße 24, 37085 göttingen, germany

emlix - your embedded linux partner