View Single Post
  #27   Report Post  
Mike Mol
 
Posts: n/a
Default

John Stumbles wrote:
Mathew J. Newton wrote:
Rob Bradford wrote:
"John Stumbles" wrote in message

snip

Rob, I suspect your answer may not be of use more for the fact that
John's message/request dates back to 8th July 2004...

# dd if=test.file of=/dev/sda1 bs=1M
dd: writing `/dev/sda1': No space left on device
249+0 records in
248+0 records out

(Hmmn, 260,046,848 bytes: card seems a bit short, but I don't think I
can be mistaken about a "256M" card being 256*1024*1024 - it's still
more than 256,000,000. I'm assuming it successfully wrote 248 records
and failed on the 249th)


Assuming you're running a sufficiently recent kernel (2.6.x, for
stable), look at /sys/block/sda/sda1/size to get the size of the
device, as the kernel sees it. Hard disk drive manufacturers measure
disk sizes in si units instead of traditional computing units. (1KB to
them is 1000 bytes, not 1024 bytes.) This means my "10.2GB" seagate
drive actually only holds 9.6GB of data. (Flamewars of GiB vs GB aside,
of course) It's possible that the manufacturer took advantage of the
same marketing-freindly measuring system.


# dd if=/dev/sda1 of=test.out bs=1M
248+1 records in
248+1 records out

(Why am I getting 248+0 when writing, 248+1 when reading back?
What does the + figure mean? man dd and info coreutils dd invocation
doesn't tell me.)


I'm not sure, but dd might not be counting partial records after an
aborted write. (i.e. when the end of the disk is reached.) If that's
the case, you're seeing a bug in your version of dd.

The y in "x+y records in/out" refers to a partial record. Since you're
using a huge blocksize (1M), and the device's size apparently isn't a
round number of MB, dd can't write a complete 249th record, typically
either because there isn't enough space, or there isn't enough data
with which to write.

This behavior is normal. If dd reads or writes a partial record, it
*should* report "+1" instead of "+0".


# dd if=test.file of=test.248 bs=1M count=248
248+0 records in
248+0 records out

# ll test.out test.248
-rw-r--r-- 1 root root 260046848 2005-04-06 12:27 test.248
-rw-r--r-- 1 root root 260292608 2005-04-06 12:26 test.out

(Something wrong he why am I getting different file sizes?
Maybe it's related to dd reporting 248+1 records for some operations
and 248+0 for others.)


You're on the right track. Judging from the differences in file sizes,
the +1 referred to an additional 240K beyond the 248MB you specified by
combining the bs argument with the count argument.

test.out is an image of all the data on your flash disk. test.248 is
only the first 248MB, and lacks the final 240K.


I then tried truncating both files to 247M and comparing, and found

no
difference, so looks as if the fault isn't showing up with this test
either - seems to be intermittent.


You'll find that test.248 is identical to the first 248MB of test.out,
because test.248 represents a subset of all the space on your disk,
while test.out represents the entire disk.


Can anyone help me with the + number issue with dd though?


HTH

Mike