[sf-lug] dd(1), bs, obs, ibs (was:debian vs ubuntu question)

Michael Paoli Michael.Paoli at cal.berkeley.edu
Mon Feb 18 15:11:07 PST 2019


> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [sf-lug] debian vs ubuntu question
> Date: Sat, 16 Feb 2019 18:14:01 -0800

> probably want to crank up dd's the 'bs' (blocksize) value, as otherwise
> it'd probably be excruciatingly slow.  On that:

Often I bump up just obs.  That's the output block size.
Typically I'll bump it up to the largest (possibly) applicable
block size for the existing target ...
e.g. if it's ext2/3/4 on spinning rust, and I know none of them
use a block size >4KiB - and any on there that might be smaller would
be some integral power of 2 factor smaller, then I'd use 4KiB.
If there's additional layers involved that do or may have larger block
size, I scale up accordingly, e.g. zfs, LVM, etc.
If flash is involved, I'll use/guestimate the largest
write/erase block size that might be applicable, notwithstanding
something that I'd already pick larger for.

Anyway, obs covers the output block size, ibs likewise input,
and bs does both at once.  There's generally negligible advantage in  
increasing ibs, as OS will generally buffer whatever it physically  
reads, so not much is lost if ibs is smaller than ideal.  If ibs is  
larger than optimal, it just wastes some RAM, while dd holds/buffers  
more data between reads and writes.
And having both ibs and obs be the same size (bs) can be slightly more  
efficient - if that's also optimized for obs, but obs is the more  
critical, ibs not so much.

In any case, not a huge difference, at least in most cases, if one optimizes
obs - or sets bs for what one would use to optimize obs.




More information about the sf-lug mailing list