[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
dd (Re: Help Creating A Bootable USB Disk)
From: "tom r lopes" <tomrlopes@gmail.com>
Subject: Re: Help Creating A Bootable USB Disk
Date: Sun, 2 Aug 2020 04:14:38 -0700
On Sun, Aug 2, 2020 at 3:21 AM Michael Paoli <Michael.Paoli@cal.berkeley.edu>
wrote:
> From: "'Christian Peeples' via BerkeleyLUG" <
berkeleylug@googlegroups.com>
> Subject: Help Creating A Bootable USB Disk
> Date: Sun, 2 Aug 2020 08:24:07 +0000 (UTC)
So, now just dd to write the USB device:
# dd if=ubuntu-20.04-desktop-amd64.iso obs=4194304 of=/dev/sdb
I didn't know about the "obs" option. I've always used "bs"
So reading the manpage I see obs is the blocksize for writing (output)
ibs for reading (input) and bs to specify both. I would have thought
making the read and write block size the same is best.
Yes, it's the output write block size that's often critical -
especially for flash, but for any device that's
block-oriented write at the physical level (and
also when applicable, erase block size), good to have the
output blocks writes set at (or some integer multiple of) that.
Also, if there's some higher level blocking also involved, e.g. on
LVM, zfs, ext[234], etc., might gain a wee bit more on performance by ensuring
obs is integer multiple of LCM of that block size and the physical
write (and erase, if applicable) block size. So, typically
that might be, e.g. 4MiB or some multiple thereof.
ibs doesn't much matter - may save teensy bit of overhead in
the program, but not much else. OS will read input
device/stream at whatever it's physical block size is (if it's
a block device) - and it'll buffer that for the application to
read from - so doesn't much matter. On the other hand, obs matters
up to hugely. E.g. if we have an obs that's a fraction of the
write, or erase, block size, on the output devices, it may require
multiple writes, or erase/write cycles, to complete the writing of
the physical write/erase block - whereas if we picked obs
at the size (or integer multiple of) the physical, then the
(erase/)write is done in single pass/cycle. So, too small,
and the output can go orders of magnitude slower, and also
likewise increase the write wear - most notably on flash/SSD,
even on rotating rust it'll generally be more head passes, rotations,
and bit more seeks, so can also slow it down quite a bit.
Also you can abbreviate 4194304 by 4M (so obs=4M)
Depends on your vintage/flavor of dd.
Integer always works - and is bytes.
Let's see ... standards ...
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/dd.html
At current, b for 512 byte blocks, k for KiB.
None other are standard.
Hmm, "ancient" history ...
https://plan9.io/7thEdMan/v7vol1.pdf
ibs, obs, b, and k all work there too.
But none 'o that newfangled M - nor is that in current standards.
And I like to add "status=progress" because if your USB doesn't have
any lights it is hard to know if anything is happening.
I usually don't bother with that. But if/when I want to know ...
GNU's dd will give current status to stderr upon receipt of
SIGURS1. So, I'll sometimes use that. The -o option to lsof can
also sometimes come in handy (and even more so when what's
reading/writing isn't dd). Can also use the proc filesystem
to determine the file(s) ... but I don't know off-hand if
offset of read/write is available or easily determined from there.
I have been also doing "conv=sync" Because I am just copying something
I read somewhere. I had thought it was like doing "sync" command after dd
is done. But NO!! I should check the manpages more often. "conv=sync"
pads the output block with zeros.
Yeah, most of the time one doesn't want to pad out the last output block
written.
Why would you want to do that?
https://askubuntu.com/questions/706670/why-is-the-sync-option-used-with-the-dd-command
Second answer by Mark Plotnick
I think what I want is "oflag=sync"
I don't really see a reason for that.
After the dd, one can always do:
$ sync && sync
And ... why the double sync?
Because sync can return before it's completed.
But another sync, can't return
until earlier sync has completed.
That's why, for, e.g. fast emergency shutdown/halt, one may see
something like:
# sync && syncn && halt
... or nowadays on GNU/Linux, with all the goop added to halt
to keep folks from shooting themselves in the foot:
# sync && sync && halt -f -f
or:
# sync && sync && halt -d -f -f -n
... or something like that.
Future versions will probably require:
# sync && sync && halt -d -f -f -f -f --force='really really please I
mean it!' -n --reason='power supply on fire! Please halt now now now
now now!' --comment='I though one of the reasons we went from Windows
to Linux was so we would't have to ask Mother May I Please?'
--
You received this message because you are subscribed to the Google Groups "BerkeleyLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to berkeleylug+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/berkeleylug/20200802095547.54964zimvv6wqgw0%40webmail.rawbw.com.