Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 Mar 2013 03:32:01 -0700
From:      "Ronald F. Guilmette" <>
To:        Quartz <>
Subject:   Re: Copying memstick image to a USB (flash/thumb) drive
Message-ID:  <>
In-Reply-To: <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

In message <>, you wrote:

>> I have filed the following PR:
>Er, don't take my word for law:

I didn't.  I won't.

>I have *no* idea if 1M is a good idea 

Any size which is an exact multiple of the physical block size for
the target device should provide performance which is as good as
it gets.

I googled around and read various comments.  Some of these kinds
of devices have a physical block size of 64KiB.  Some have 128KiB.
Some have 256KiB.  Some have 1MiB.

For all of these devices, seting blocksize to 1MiB will provide optimal
performance with at worst only a _relatively_ tiny waste of space.

>As for the conv=sync option, I'm not convinced it's necessary either 

Neither am I, but I would rather have it there, than not and take

It won't hurt anything, and it appears that it _may_ perhaps help.

>I don't think modern systems really care what the end is padded with 

That wasn't my concern.  My concern is that I personally do not know
what the officially defined semantics are in cases where dd is asked
to copy data in a specific input block size _and_ the actual data
available from the input device doesn't perfectly fill up that last

It is possible, I would guess, that dd may notice the EOF occuring
before it has filled up an entire input buffer, and then just quit
at that point, _without_ writing the partial last block to the
output device.

It seems to me that conv=sync is cheap insurance against this

I have always been a belt and suspenders kind of guy.


Want to link to this message? Use this URL: <>