[Bug 247136] Handbook, section 2.3.1.1: dd(1) command uses "bs=1M" (slow), should be "bs=4k" (/much/ faster)

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247136

            Bug ID: 247136
           Summary: Handbook, section 2.3.1.1: dd(1) command uses "bs=1M"
                    (slow), should be "bs=4k" (/much/ faster)
           Product: Documentation
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: Documentation
          Assignee: doc at FreeBSD.org
          Reporter: t.eichstaedt at gmx.net

Dear documenters,

1. unless there's any technical reason to use a blocksize of 1M, this should be
changed.  Unfortunately I do not have the insight to judge that, so please
check w/ s/o who knows more about this.  All images I wrote w/ "bs=1k" so far
worked, so I'd assume that either all those images were integer multiples of
1M, or there's no technical reason to pad the end w/ zeroes to the next 1M
boundary.

Rationale:
(AFAIK) The native blocksize of USB media is 4k.  Writing an image w/ the
native blocksize is about 7 times faster (at least on USB 2).

2. I'd like to suggest to add "status=progress" to the dd(1) arguments, because
this command can take a few minutes (on USB 1/2) and it's much nicer to have
some reply about what's going on.  Somehow like this: "older versions of dd(1)
do not support 'status=progress'.  If it fails, simply use the command w/o it."

I just stumbled over this when I was preparing the media for an installation,
and instead of just doing what I used to do ("dd bs=1k conv=sync"), I checked
the handbook to see if s/th changed.  Nothing changed, but using "bs=1M" was
significantly slower than "bs=1k".  So I thought: both is wrong, should be 4k! 
And yes - using "bs=4k" is in fact much faster.

The same bad example occurs in the man page of dd(1) (last example)

With kind regards, Torsten

-- 
You are receiving this mail because:
You are the assignee for the bug.