[colug-432] creating sparse disk images

[Rick Hornsby]

On November 12, 2018 at 8:20:54 PM, jep200404 at columbus.rr.com (
jep200404 at columbus.rr.com) wrote:

On Mon, 12 Nov 2018 19:02:25 -0300, Rick Hornsby <richardjhornsby at gmail.com>
wrote:


In response to one of the other replies — I definitely need to preserve the
boot loader and boot sector, so copying the whole SD card is required and
seems like the most straight-forward approach. I don’t think copying the
two individual partitions will work. First, because it would copy the 14GB
ext partition as 14GB (the problem I’m trying to solve), and that doesn’t
preserve the boot loader portion.

I _think_ Raspian uses Grub, but offhand I don’t remember. Whatever it
uses, I don’t want to introduce any changes to the boot loader.

> Maybe I’m not understanding what “sparse” means in this context?

Maybe so.

What does sparse mean to you?

What does the following mean to you?

[rjh at colug ~]$ man dd | grep sparse
sparse try to seek rather than write the output for NUL input blocks
[rjh at colug ~]$

So in my head, sparse meant it the way that it is meant in terms of VM
disks (?) when configured to be sparse (lazy?), particularly VMware. A
sparse disk only uses the amount of physical storage required. So a 40GB
disk may only consume 3GB of underlying physical disk. In this case, I was
thinking it meant that I could only write the first X blocks that were
actually in use, or rather, that were not 0x00. Essentially at the point
where the data stopped and 0x00 started and went to the end of the disk
could just be ignored/truncated and not written to the image.

I began to question myself because of exactly what you quoted from the man
page. If a sequential write seeks, it simply bypasses sequences of 0x00
bytes moving the write pointer to the next non-null byte where it begins
writing again. The result is still a 16GB image file. The advantage is that
dd doesn’t spend the time writing a long sequence of 0x00. I think.

hmm.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.colug.net/pipermail/colug-432/attachments/20181113/1eeb31a6/attachment.html