[Wolves] dd usage?

Chris Ellis chris at intrbiz.com
Wed Jun 4 21:38:25 UTC 2014


Hi

On Wed, Jun 4, 2014 at 9:56 PM, Andy D'Arcy Jewell <andy at wild-flower.co.uk>
wrote:

> 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
>
>
As Andy pointed out, setting the block size controls how much data will be
read from the device and written to the device in a single read() ->
write() copy operation.  A larger block size will mean fewer context
switches and can often let the destination device manage how it wants to
queue the data to write.  Larger block sizes can often be quicker when
writing to flash drives / USB sticks.  I tend to use a block size of 1MiB.

To copy a smaller disk to a larger one and then to resize, I would roughly
do:

0. Take a backup!
1. Boot a live disk.  You cannot dd a mounted drive!
2. Copy, using: dd if=/dev/sda of=/dev/sdb bs=1M
2. Resize the partition, use fdisk or what ever tool you like.
3. Grow the FS, using the FS specific tool

Personally, I'd use YaST or MCC (as I'm an OpenSUSE / Mageia user) to
resize the partition and grow the FS rather than faffing with fdisk.

Another trick to know when using dd, is that you can send the USR1 signal
to it to show the progress, by default dd will print nothing until it
completes, in another terminal you can execute:

pkill --signal USR1 ^dd

This will make dd display its progress (to the terminal dd is running in).

If you're just increasing drive capacity, you shouldn't need to reinstall
the boot loader / rebuild the initrd, this assumes you copy the whole
drive, as mentioned above.  If you change things like
the drive controller (IDE to SATA, or RAID) etc then the initrd will need
to be rebuilt.

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/wolves/attachments/20140604/e3df7d68/attachment-0001.html>


More information about the Wolves mailing list