Copying memstick image to a USB (flash/thumb) drive
Ronald F. Guilmette
rfg at tristatelogic.com
Thu Mar 28 10:32:06 UTC 2013
In message <5153FEFF.4090305 at sneakertech.com>, 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
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
It seems to me that conv=sync is cheap insurance against this
I have always been a belt and suspenders kind of guy.
More information about the freebsd-questions