[GTALUG] Compressing an image of a microSD card

Lennart Sorensen lsorense at csclub.uwaterloo.ca
Thu May 14 12:32:02 EDT 2020


On Thu, May 14, 2020 at 12:10:53PM -0400, Giles Orr via talk wrote:
> I have an Anbernic RG350, a very nice hand-held gaming console:
> 
> https://retrogame300.com/products/rg350
> 
> It uses a Linux distro that was developed for an older hand-held game
> console.  It turns out that the OS and "internal storage" are on an
> actual microSD card inside the case: four screws and a gentle tug to
> get the card out, and you can image the "main drive."
> 
> It's a 16G SD card with two partitions that occupy the whole card.
> Between them, they have 1.4G of used space.  I imaged the whole card:
> 
>     # time dd if=/dev/sdi bs=4M of=./RG350.SD.2020-05-14.img
> conv=fsync status=progress
> 
> This produced a roughly 16G image as expected.  Then I compressed it:
> 
>     # time xz --threads=5 RG350.SD.2020-05-14.img
> 
> This produced a 10G image.
> 
> My assumption was that compression would see the empty partition
> space, presumably as a bunch of zeroes, and compress the crap out of
> it so that the final image would be the same size or smaller than the
> 1.4G of used space.  I'm aware that the free space may not be zeroed
> out ...  It's not encrypted, so that's not the issue.  Is there a sane
> way to back this up that would produce a smaller image?  I prefer to
> image the whole card ... and I like 'dd' because I'm familiar with it,
> although maybe I should move on ...  Is somehow zeroing the empty
> space on the card a possibility?  Suggestions welcomed ...
> 
> I can live with the 10G backup if I have to, but would prefer a
> "better" solution if it's available.

Any idea what filesystem it uses?

Certainly something like clonezilla knows how to deal with filesystems
and partitions and ignore the parts of the filesystem that are not in use
(even if not zeroed).  If you can mount the saved image (using loop
device) you might be able to zero the unused space which would reduce
the compressed size a lot).

-- 
Len Sorensen


More information about the talk mailing list