[colug-432] creating sparse disk images

[Matthew Hyclak]

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.

https://unix.stackexchange.com/questions/44234/clear-unused-space-with-zeros-ext3-ext4
looks like a good starting point.

Matt

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

>
> 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