[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
dd block size deficiency (bug or feature ?)
From: |
Oskar Schirmer |
Subject: |
dd block size deficiency (bug or feature ?) |
Date: |
Thu, 17 Jun 2004 17:21:17 +0200 |
User-agent: |
Mutt/1.3.22.1i |
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
- dd block size deficiency (bug or feature ?),
Oskar Schirmer <=