Bug 247136 - Handbook, section 2.3.1.1: dd(1) command uses "bs=1M" (slow), should be "bs=4k" (/much/ faster)
Summary: Handbook, section 2.3.1.1: dd(1) command uses "bs=1M" (slow), should be "bs=4...
Status: Closed Not A Bug
Alias: None
Product: Documentation
Classification: Unclassified
Component: Documentation (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Gordon Bergling
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-10 07:22 UTC by Walter von Entferndt
Modified: 2020-07-05 10:39 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Walter von Entferndt 2020-06-10 07:22:01 UTC
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
Comment 1 andrew 2020-06-10 07:42:07 UTC
My experience and benchmarks differ - from a freebsd stable/11 system to a random USB2 thumb drive, I get a slowdown on the order of 8x from using 4k rather than 64k block size.

Block sizes of 64k, 128k, 256k, 1m give me indistinguishable speeds (note, there is basically no reason to ever use a blocksize greater than MAXPHYS when writing to a raw device, and that is 128k in standard builds). All block sizes below 64k are slower for me.

status=progress is not needed on freebsd since you can always just use control-T.
Comment 2 Gordon Bergling freebsd_committer 2020-07-05 10:39:44 UTC
After internal discussions the blocksize of 1M should be the better option for most systems, because there's a lot more system calls for example.