Estou usando um stick USB 2.0 com 16 GB de armazenamento e tenho um instalador ISO de 2,8 GB. Ao atualizar este ISO para o stick, noto que a velocidade é muito lenta (5 minutos) em comparação com a cópia do próprio arquivo ISO para o stick (4 segundos).
Por que o flash demora 75 vezes mais do que apenas copiar o arquivo para uma partição existente?
Minha hipótese é que seja por causa do antigo sistema de arquivos ISO 9660 presente na ISO. Alguém pode confirmar que este sistema de arquivos é lento?
Também estou me perguntando se é possível fazer uma ISO com partições de sistemas de arquivos mais recentes (por exemplo, exFAT). Caso contrário, por que o ISO ainda é o formato padrão para imagens do instalador do sistema operacional? Se for possível, por que alguém decidiria contra o exFAT e usaria a ISO 9660?
Informações sobre a 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
Desde já, obrigado!
Editar: também tentei atualizar o ISO usando:
dd bs=4M if=my.iso of=/dev/sda conv=fdatasync status=progress
Demorou 15 malditos minutos e aqui está o resultado:
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
Aqui estão algumas informações sobre as partições atualizadas:
> 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
A maior parte do arquivo ainda não foi copiada para a partição – ele está aguardando no buffer/cache do sistema operacional para ser liberado em algum momento posterior. Se você tentar fazer isso
sync
noumount
sistema de arquivos depois de fazer isso, ainda levará vários minutos para liberar as gravações pendentes.Não é. Como um sistema de arquivos somente leitura, ele funcionou na década de 1990 e não é mais lento com CPUs modernas. (Pelo menos não em comparação com o exFAT, que não é de forma alguma um sistema de arquivos moderno – o exFAT nem mesmo é baseado em extensão, ele ainda usa cadeias de cluster como seus antecessores dos anos 1980).
Mas, deixando isso de lado, "flash" uma imagem de disco geralmente implica escrevê-la 1:1, setor por setor, caso em que o sistema de arquivos não está envolvido no processo - toda a estrutura do sistema de arquivos é apenas copiada como uma série contínua de setores sem qualquer tentativa de interpretá-lo. O processo de gravação, por exemplo, de uma imagem de 1 GB em um disco,
gnome-disks
deve levar exatamente a mesma quantidade de tempo, independentemente do conteúdo dessa imagem.(Uma exceção a isso são os programas que realmente não "flash" ou "gravam" a imagem, mas em vez disso extraem seu conteúdo para um sistema de arquivos recém-preparado (Rufus é um exemplo). Nesses casos, a "velocidade" do novo o sistema de arquivos de destino (que quase sempre é FAT32) será mais importante do que a fonte, pois atualizar estruturas de dados é mais lento do que lê-los – e muitas vezes, extrair algumas centenas de arquivos menores será de fato visivelmente mais lento do que copiar um único arquivo grande – mas mesmo se as estruturas do sistema de arquivos são abaixo do ideal, a diferença entre, por exemplo, ISO 9660 e exFAT dificilmente será perceptível em qualquer tipo de CPU moderna.)
Neste exemplo específico, você não especificou um tamanho de bloco,
bs=
então suspeito que pelo menos parte do problema é que o padrão 'dd' é ler e gravar apenas 512 bytes (um único setor) de uma vez. Algo ao redorbs=1M
geralmente irá um pouco mais rápido.ISO 9660 ainda é usado porque as imagens "ISO" são, antes de mais nada, imagens de CD/DVD , e esse é o sistema de arquivos padrão para elas. (Embora se forem imagens de DVD, eles usarão o UDF mais recente em vez do ISO 9660. Por exemplo, qualquer Windows.iso recente é na verdade uma imagem UDF com apenas um sistema de arquivos ISO 9660 "stub".)
Acontece que a imagem do Linux que você tem foi preparada para
isohybrid
funcionar simultaneamente como um disco de CD/DVD inicializável (usando o padrão El Torito) e um HDD inicializável (usando os formatos típicos de inicialização BIOS e UEFI), usando alguma intercalação criativa dos diferentes tabelas de partição envolvidas; mas, em termos gerais, as imagens "ISO" devem ser gravadas em CDs.Portanto, a verdadeira questão é por que as imagens de instalação do sistema operacional ainda são feitas como imagens de CD/DVD e não como imagens de disco normais. (Não sei a resposta para isso.)
Quanto aos CDs/DVDs que usam outros sistemas de arquivos, é provavelmente tecnicamente possível da mesma forma que com UDF, devido à forma como o processo de inicialização do CD/DVD funciona – deveria ser tecnicamente possível, mas pelo menos o setor específico 0x11 precisa parecer um ISO válido 9660 "Boot Record" para o firmware do PC reconhecer o CD como inicializável, portanto, o novo sistema de arquivos deve ser encapsulado em uma estrutura fictícia ISO 9660, e o sistema operacional precisa esperar e reconhecer isso - o que provavelmente não acontecerá.