[Wolves] dd usage?

Kevanf1 kevanf1 at gmail.com
Thu Jun 5 13:41:17 UTC 2014

Brilliant and thank you both.  I actually do believe I'm getting my
head around all this :)  Don't ask me to repeat it all yet but for
once it is slotting into place in the old grey matter (what's left of

That little fix for Fedora seems to be working....  I have third party
repo's ticked so it threw a bit of a wobbly.  The fix was to add
--nogpgcheck at the end of the command for fedup.  It's a
project/experimental system anyway (thank you Ron) so if I do break
anything I don't lose any vital data.  I've opted to use Fedora for
now to expand my cli knowledge purely because Mint, which I use day to
day, just works.  It's the system I always wanted for years.  One
which I could just get on with everyday tasks and not have to be
tinkering.  But I needed a system to tinker with too..  hence the Fed

I'll let you know how I get on but this is not a 5 minute thing it is
more like 5 days as I'm v.busy with sorting out the
recycling/reuse/repurposing network at the moment too.

On 4 June 2014 22:38, Chris Ellis <chris at intrbiz.com> wrote:
> 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
> _______________________________________________
> Wolves LUG mailing list
> Homepage: http://www.wolveslug.org.uk/
> Mailing list: Wolves at mailman.lug.org.uk
> Mailing list home: https://mailman.lug.org.uk/mailman/listinfo/wolves


Linux user #373362

'Just Free it.'

More information about the Wolves mailing list