[colug-432] creating sparse disk images

Matthew Hyclak hyclak at gmail.com
Tue Nov 13 12:12:28 EST 2018

Been a while since I did this, but I believe you have to make sure the
filesystem you want to be sparse actually contains 0's in the places you'd
like to be sparse before creating the sparse file.

looks like a good starting point.


On Tue, Nov 13, 2018 at 11:53 AM Rick Hornsby <richardjhornsby at gmail.com>

> 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.
> _______________________________________________
> colug-432 mailing list
> colug-432 at colug.net
> http://lists.colug.net/mailman/listinfo/colug-432
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.colug.net/pipermail/colug-432/attachments/20181113/43aa0da3/attachment.html 

More information about the colug-432 mailing list