Is it possible to have an exFAT partition inside an ISO file?

Question

I'm using an USB 2.0 Stick with 16GB of storage and I have an installer ISO which is 2.8GB. When flashing this ISO to the stick I notice that the speed is very slow (5 minutes) compared to copying the ISO file itself to the stick (4 seconds).

Why does flashing take 75 times as long as just copying the file to an existing partition?

My hypothesis is that it's because of the old ISO 9660 file system present on the ISO. Can someone confirm that this file system is slow?

I'm also wondering if it is possible to make an ISO with partitions of newer file systems (e.g. exFAT). If not, why is ISO still the standard format for OS installer images? If it is possible, why would someone decide against exFAT and use ISO 9660 instead?

Info about the ISO:

> isoinfo -d -i EndeavourOS_Galileo-Neo-2024.01.25.iso
Setting input-charset to 'UTF-8' from locale.
CD-ROM is in ISO 9660 format
System id: 
Volume id: EOS_202401
Volume set id: 
Publisher id: ENDEAVOUROS <HTTPS://ENDEAVOUROS.COM>
Data preparer id: PREPARED BY MKARCHISO
Application id: ENDEAVOUROS LIVE/RESCUE CD
Copyright File id: 
Abstract File id: 
Bibliographic File id: 
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 1347830
El Torito VD version 1 found, boot catalog is in sector 126

Joliet with UCS level 3 found.
SUSP signatures version 1 found
Rock Ridge signatures version 1 found
Rock Ridge id 'RRIP_1991A'
Eltorito validation header:
    Hid 1
    Arch 0 (x86)
    ID ''
    Cksum AA 55 OK
    Key 55 AA
    Eltorito defaultboot header:
        Bootid 88 (bootable)
        Boot media 0 (No Emulation Boot)
        Load segment 0
        Sys type 0
        Nsect 4
        Bootoff 7F 127

Thanks in advance!

Edit: I also tried to flash the ISO using:

dd bs=4M if=my.iso of=/dev/sda conv=fdatasync status=progress

It took 15 damn minutes and here's the output:

2747269120 bytes (2.7 GB, 2.6 GiB) copied, 160 s, 17.2 MB/s2760355840 bytes (2.8 GB, 2.6 GiB) copied, 160.008 s, 17.3 MB/s
   
658+1 records in
658+1 records out
2760355840 bytes (2.8 GB, 2.6 GiB) copied, 856.116 s, 3.2 MB/s

Here's some info about the flashed partitions:

> lsblk -f /dev/sda
NAME   FSTYPE  FSVER            LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda    iso9660 Joliet Extension EOS_202401  2024-01-25-18-25-14-00                              
├─sda1 iso9660 Joliet Extension EOS_202401  2024-01-25-18-25-14-00                              
└─sda2 vfat    FAT16            ARCHISO_EFI 8093-0377                 

Answer 1

Why does flashing take 75 times as long as just copying the file to an existing partition?

Most of the file wasn't copied into the partition yet – it's waiting in the OS buffer/cache to be flushed at some later point. If you try to sync or umount the file­system after doing so, it'll still take several minutes while it flushes the pending writes.

My hypothesis is that it's because of the old ISO 9660 file system present on the ISO. Can someone confirm that this file system is slow?

It's not. As a read-only filesystem, it did the job in 1990s and it's not any slower with modern CPUs. (At least not in comparison to exFAT, which is not a modern filesystem by any means – exFAT isn't even extent-based, it still uses cluster chains like its 1980s predecessors).

But that aside, "flashing" a disk image generally implies writing it 1:1, sector by sector, in which case the file­system is not involved in the process at all – the entire filesystem structure is just copied as a continuous series of sectors without any attempts to interpret it. The process of writing e.g. a 1GB image to a disk using gnome-disks should take exactly the same amount of time regardless of the contents of that image.

(An exception to that is programs which don't really "flash" or "write" the image but instead extract its contents into a newly prepared filesystem (Rufus is one such example). In such cases, the "speed" of the new destination filesystem (which is almost always FAT32) will matter more than the source, as updating data structures is slower than reading them – and often, extracting a few hundred smaller files will indeed be noticeably slower than copying a single large file – but even if the file­system structures are suboptimal, the difference between e.g. ISO 9660 and exFAT will be hardly noticeable on any sort of modern CPU.)

Edit: I also tried to flash the ISO using:

In this specific example, you didn't specify a block size with bs= so I suspect at least part of the issue was that 'dd' defaults to reading and writing only 512 bytes (a single sector) at once. Something around bs=1M will usually go somewhat faster.

I'm also wondering if it is possible to make an ISO with partitions of newer file systems (e.g. exFAT). If not, why is ISO still the standard format for OS installer images? If it is possible, why would someone decide against exFAT and use ISO 9660 instead?

ISO 9660 is still used because "ISO" images are CD/DVD images first and foremost, and that's the standard filesystem for them. (Though if they're DVD images, then they will be using the newer UDF instead of ISO 9660. For example, any recent Windows.iso is actually a UDF image with only a "stub" ISO 9660 filesystem.)

The Linux image you have happens to have been prepared using isohybrid to simultaneously work as a bootable CD/DVD disc (using the El Torito standard) and a bootable HDD (using the typical BIOS and UEFI boot formats), using some creative interleaving of the different partition tables involved; but in general terms, "ISO" images are meant to be burned into CDs.

So the real question is why OS install images are still made as CD/DVD images and not as regular disk images. (I don't know the answer to that.)

As for CDs/DVDs using other filesystems, it's probably technically possible the same way as with UDF, due to the way CD/DVD boot process works – it should be technically possible but at least the specific sector 0x11 needs to look like a valid ISO 9660 "Boot Record" for the PC firmware to recognize the CD as bootable, therefore the new filesystem has to be wrapped in a dummy ISO 9660 structure, and the OS needs to expect and recognize that – which it probably won't.