[Wolves] dd usage?

[Andy D'Arcy Jewell]

On 04/06/14 21:32, Kevanf1 wrote:
> Thank you, Chris :)  Can you expand a little on the block size option
> please?  I know I should really have got a grasp on all of this years
> ago....  I didn't, I admit that I was led by the nose in using Windows
> and the various GUI environments in Linux.  I still use a GUI
> (currently Cinnamon in Linux Mint 15 and 16 on separate netbook and
> laptop and Mate in Fedora 19) but I am slowly really starting to enjoy
> the cli.
Apologies for butting in here, but here's my penyy's worth:

bs=nn simply makes dd grab nn bytes of data per read, but if you don't 
specify it, it defaults to *one* byte of data per read. This means that 
if you are copying 1k of data, dd will make 1024 calls to read(), but 
with bs=1k, it will make just one call. The time spent making all those 
calls adds up to a large overhead when you are copying gigabytes or 
terabytes of data. On top of that, disk drives also have caches/buffers, 
and if you make your reads exactly the same size as this, you get even 
more efficiency, as the drive can read a sequential list of sectors off 
the disk, and into the buffer more quickly in one go, because of the way 
it works mechanically. If you read only one sector at a time, other 
reads or writes might have moved the disk heads by the time you request 
your next read, so the heads have to bounce round a lot more, and you 
have also to wait for the sector you want to spin round to be under the 
read-write heads. Reading a cache-full at a time avoids most of this 
waiting round. There are many other factors too, which can have an 
affect, but these are probably the most important.

The cli is the route to a fuller understanding of the system, and more 
powerful control of it!

>
> By the way, my upgrade of Fedora 19 to 20 failed :(  I know the reason
> why though as it's a documented item in Bugzilla.  I also know the fix
> which is even better.  All this again through the cli.
>
I gave up on fedora for exactly this sort of reason!

-Andy DJ