It’s been a while since the last installment in my Little Things Doth Crabby Make series. The full series can be found here. So, what’s made me crabby this time? Well, when a Linux utility returns a success code to me I expect that to mean it did what I told it to do. Well…
What’s 4K Between Friends?
Really? I’m just picky! If I use dd(1) to write 2GB (2 * 2^30 sort of 2GB by the way) I’m not looking for a successful transfer of (2 * 2 ^ 30) – 4096 bytes! Imagine that.
Folks, don’t trust the return code from dd(1). I’ve been burned more than once.
Is He Totally Crazy? Using dd(1) with a 2GB write size?
Sure, why not? If it doesn’t want to do what I ask it is supposed to fail the command, not lose data.
I just did this on a 2.6.18 Kernel:
# file /tmp/OH.tar /tmp/OH.tar: POSIX tar archive # ls -lh /tmp/OH.tar -rw-r--r-- 1 oradb oinstall 19G Jun 16 17:23 /tmp/OH.tar # dd if=/tmp/OH.tar bs=2147483648 count=1 | wc -c 0+1 records in 0+1 records out 2147479552 2147479552 bytes (2.1 GB) copied, 2.52849 seconds, 849 MB/s # echo $? 0 # bc -l bc 1.06 Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 2147483648-2147479552 4096
Kevin Closson's Blog: Platforms, Databases and Storage 
Jeeeez! That’s a trap if ever I saw one!
Thanks for the warning, Kevin!
Kevin,
dd will indeed return a 0 exitcode, but in your example, would the exit code not come from wc instead of dd?
regards
Yes, Freek, good catch. I discovered the erroneous success code before I plugged the wc in. I though the wc would make the point easier to understand. I’ll quicklu follow up with proof that it fails the same was with a file to file dd.