Support compression

[TPS]

@ventoy All the listed currently-supported disk image formats are typically uncompressed, which is wasteful when supporting multiple disk images on an often limited-space USB drive. Could compression be supported in @ least 1 of these ways?:

• Explicit & complete support for compressed disk image formats (e.g., .wim @ WIM made with LZX max compression (inside ISO) will not boot #288, .dmg @ Support for .dmg files #665, .cso, .dax, .imz, .vhdz, .chd @ Support compression #817 (comment), &c)
• Explicit & complete support for compressed file systems both for host (e.g., USB's) & within the disk image file(s) (e.g., btrfs @ [Feature Request] Btrfs support #645 (comment), zfs, ntfs /refs, &c)

[ventoy]

As I said in #645
Ventoy depends on the file's location on the disk and map these blocks to a virtual device.
So the file in the filesystem can NOT be compressed.
So brtfs and other filesystems with compression enabled can NOT be supported.

[TPS]

Are the rest possible?

[whocares0101]

How about mame chd support?
https://github.com/rtissera/libchdr

[HaleTom]

For other Googlers, to find this issue:

error: module `ntfscomp` isn't loaded
error: read MFT 0x53 fails.

Work-around: You don't need to uncompress the whole drive, just the .iso itself, or perhaps the folder containing your boot ISOs :)

[derzahla]

cant img/iso files compressed with various tools be uncompressed to a ramdisk and treated the same as uncompressed images? That would be a great feature

[HaleTom]

@derzahla that's a good idea -- feel free to raise it as a separate issue :)

Even so, the ISO couldn't be loaded into ramdisk as per your suggestion because of this current issue: the data in the ISO couldn't be read if the ISO was compressed and residing on NTFS.

[polarathene]

Ventoy depends on the file's location on the disk and map these blocks to a virtual device.
So the file in the filesystem can NOT be compressed.
So brtfs and other filesystems with compression enabled can NOT be supported.

Is there a particular resource that clarifies this limitation?

I would have thought that the filesystem was responsible for managing it's data and how it compresses and stores the extents of a file. Other software would just take the file and could modify any part of it completely oblivious to filesystem features like compression, without any issue.

What is different with how Ventoy approaches it?

---

A 128 GB fixed size .img (with a linux OS install) compressed to 7GB disk usage on host BTRFS (with compression enabled) disk, but without using specialized utility like compsize, most generic software still considers it as 128 GB file.

I would have thought that Ventoy would map the 128GB file as per usual, and BTRFS would handle the compression behind the scenes without any issues/differences?

I tried to look up compression limitation with device mapper but wasn't finding any helpful results :(