Caixa Seca

Quando escrevi sobre o driver ntfs3 ( 1 , 2 , 3 ), imaginei que haveria tração suficiente da comunidade para aprimorá-lo, com uma manutenção competente da Paragon. Não foi o que aconteceu. Quatro anos depois, o código funciona, mas está longe de alcançar a estabilidade necessária. Ainda não suporta a montagem de volumes NTFS sujos — aqueles não desmontados corretamente —, processo conhecido como journal replay , no qual o driver consulta o histórico de transações e refaz as operações incompletas (e ignora as não commitadas) para restaurar a atomicidade e a consistência do sistema de arquivos. Esse recurso foi prometido desde o início e, até hoje, está quebrado. Além disso, o código usa APIs obsoletas do kernel, que, embora suportadas, revelam uma manutenção precária. A Paragon também prometeu ferramentas para criação e, especialmente, verificação de volumes NTFS, mas não cumpriu. Agora, surge o anúncio do ntfsplus : https://lore.kernel.org/lkml/2025...

Havia um antigo post aqui no blog, lá dos primórdios, não recomendando partição swap. Com a popularização dos arquivos de swap, o texto foi expandido, aceitando-os a contra gosto. Só que isso foi antes de tecnologias recentes do Linux, que resolveram problemas associados ao uso de swap: melhorias no kernel e, principalmente, daemons que monitoram informações de pressão de memória, E/S e CPU do kernel ( Pressure Stall Information , PSI, disponível a partir da versão 4.20) e agem antes . O mais usado é o systemd-oomd [1] . Para ser eficiente em instalações desktop, precisa que os aplicativos sejam postos cada um num cgroup diferente , o que é feito via systemd --user pelo GNOME e KDE. Em ambientes que não o façam, como o XFCE, não é recomendado habilitá-lo. Mesmo assim, o kernel não é mais tão burro como antigamente . Minha restrição às partições swap continua: são pouco flexíveis. Logo, use sim arquivos de swap! Btrfs: # btrfs filesystem mkswapfile -...

Há uma enorme confusão sobre esse assunto. Afinal, para instalar o Windows em UEFI, a mídia de instalação precisa estar particionada em GPT? BIOS UEFI [1] suportam particionamento MBR e GPT, enquanto BIOS antigos (não UEFI) apenas suportam MBR [2] . Tanto faz, portanto, com UEFI. Então por que muita gente acha que GPT é requerido? Presumo por dois motivos: → O Windows requer que o disco de destino, no qual será instalado, seja particionado em GPT. A exigência, contudo, não aplica-se à mídia de instalação. → O Rufus artificialmente restringe a criação de mídias compatíveis com UEFI ao particionamento GPT, ao contrário do Media Creation Tool (MCT) da Microsoft, que sempre particiona em MBR. Tal comportamento do Rufus tem como objetivo evitar confusão, pois discos em GPT não iniciam em máquinas com BIOS antigos. Assim, tem-se uma mídia UEFI-only . Já discos em MBR funcionam com BIOS antigos. Será que tais mídias iniciam também em UEFI...

O mantenedor do código apareceu. Patches fluindo lentamente. Kernel 5.19 trará algumas correções . Não havendo mais imprevistos , o processo de estabilização começa a partir dessa versão — alguns commits serão backportados para o 5.15 LTS, porém o desenvolvimento principal acontece na árvore mainline .

Quando postei Linux 5.15 contará com novo driver NTFS , esperava que, lançado o kernel 5.15 com o novo driver ntfs3 da Paragon Software, começasse o processo de correção de bugs logo em seguida, com a estabilidade continuamente melhorando a cada nova versão. Infelizmente, não foi o que aconteceu. Konstantin Komarov, mantenedor do código, desapareceu e, no repositório oficial, o último commit é de 12 de outubro de 2021. Desde que a versão 5.15 foi lançada, nenhuma mudança relevante foi aplicada — apenas adequações à API interna do kernel feitas por outros desenvolvedores. No repositório de desenvolvimento , há nove commits adicionais, sendo o último de 24 de novembro de 2021. Andei testando-o no Fedora nas últimas semanas (5.15.x até 5.16.8 enquanto escrevo). O desempenho é muito melhor do que o NTFS-3G, porém é instável. É fácil fazê-lo travar com o rsync (o kernel fica em pé pelo menos) e links simbólicos e pontos de junção não são resolvidos corretament...

O driver ntfs do Linux é um código deficiente, com suporte à escrita quebrado, e sem manutenção. Tanto que algumas distribuições desativam-no e fornecem apenas o lento NTFS-3G , que roda no espaço de usuário. Depois de um ano de discussão, o novo driver ntfs3 da Paragon foi aceito e estará disponível na versão 5.15. Suporta leitura e escrita, compressão, ACLs, arquivos esparsos, replay do journal — processo de colocar o sistema de arquivos num estado consistente caso não tenha sido desmontado corretamente da última vez. Como todo novo código, será azeitado nos próximos meses, com a Paragon se comprometendo em mantê-lo (lista de discussão aqui ). Considero um driver muito promissor e importante para uma melhor interoperabilidade com o Windows. Os ganhos no desempenho serão significativos e tendem a melhorar com o tempo. Junto com os drivers exfat , presente desde a versão 5.7 , e vfat , fará o kernel ter suporte de primeira aos sistemas de ...

Um dos maiores trunfos do Linux é podermos usar instalações realmente pequenas para funções específicas. Tratarei aqui de um mecanismo de backup automático, sem intervenção do usuário: ao plugar um HDD externo, o mesmo será montado, uma pasta será copiada com o rsync e, por fim, o disco será desmontado e desconectado. A distribuição usada é o openSUSE Leap 15.2, porém pode ser adaptado para qualquer outra [1] . Identifique o dispositivo onde será feito o backup: # blkid /dev/sdb1 /dev/sdb1: LABEL="BACKUP123" UUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" TYPE="ext4" PARTUUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" Crie a regra para o udev: /etc/udev/rules.d/99-hdd-externo.rules ACTION=="add", SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ext4", ENV{ID_FS_LABEL}=="BACKUP123", TAG+="systemd", ENV{UDISKS_IGNORE}="1", ENV{SYSTEMD_WANTS}+="meubackup@%N.service" ENV{UDISKS_IGNORE}=...

Novidades desde a última vez . A partir da versão 12.0.0.11181 (Ghost Solution Suite 3.3 RU4) e 12.0.0.11197 (Deployment Solution 8.5 RU4) [1] : - EXT4 com recurso metadata_csum ainda é problemático. Captura funciona pelo menos, com reclamação. Não é mantido ao restaurar. EXT4 com metadata_csum - XFS é suportado. Desde a 12.0.0.10618, há a opção -ISR , que habilita um tal de "Smart Raw Imaging for use with XFS filesystems", cuja descrição é "only sectors that by along with their locations on disk rather than capturing full disk sectors". Na nova versão, a opção passou a ser habilitada automaticamente. Pelo jeito, o formato do arquivo mudou, pois a Broadcom diz que imagens contendo XFS criadas com versões anteriores precisam ser refeitas. Pelo pouco que pude testar, funciona direito. - Aliás, agora é Broadcom Ghost, pois a Symantec foi vendida. - Clonagem de disco...

Melhor forma de saber, com precisão, o espaço usado em volumes NTFS: fsutil volume allocationreport X: (como Administrador, substituindo X pela unidade desejada) Suportado a partir do Windows 8.1. Explicação (Ntdebugging Blog): NTFS Misreports Free Space? Ntfs Misreporting Free Space (Part 2) NTFS Misreports Free Space (Part 3)

Para descrição detalhada de cada recurso, olhe a página de manual mkfs.xfs(8) . Tabela de compatibilidade: kernel mkfs.xfs ≥ 2.6.23 e ≤ 3.12 -m crc=0 -n ftype=0 3.13 e 3.14 -m crc=0 -n ftype=1 3.15 -m crc=1,finobt=0 -i sparse=0 ≥ 3.16 e ≤ 4.7 -m crc=1,finobt=1 -i sparse=0 ≥ 4.8 -m crc=1,finobt=1 -i sparse=1 Cuidado ao criar XFS V4 com versões não arcaicas do mkfs.xfs . Mesmo especificando -m crc=0 , -n ftype=1 é usado por padrão desde a versão 4.2.0. Tais sistemas requerem kernel 3.13 ou superior. A recomendação é sempre usar -m crc=0 -n ftype=0 , que garante ampla compatibilidade, pelo menos desde o 2.6.23 — requerido por -l lazy-count=1 . Versões requeridas do mkfs.xfs : -m crc ≥ 3.2.0 (habilitado por padrão a partir da 3.2.3) -m finobt ≥ 3.2.1 (habilitado por padrão a partir da 3.2.3) -n ftype ≥ 3.2.0 (sempre habilitado quando -m crc=1) -i sparse ≥ 4.2.0 (habilitado por padrão a partir da 4.16.0) XFS V5 ...

A Microsoft publicou no mês passado a especificação do sistema de arquivos exFAT , bem como prometeu adicionar as patentes relacionadas no pool da Open Invention Network. Isso permitirá a distribuição de código que implemente-o no kernel Linux. Em 2013, de forma conturbada , a Samsung disponibilizou o driver exfat-nofuse , nunca incorporado ao kernel pelas incertezas sobre o licenciamento da tecnologia. Com o sinal verde da Microsoft, não demorou para o código entrar na árvore staging . E já começou a ser melhorado. Pela sua importância, acredito que em poucos lançamentos passará a ser habilitado por padrão pelas distribuições — no Android, assumirá o posto no lugar do driver off-tree . Assim, o driver fuse-exfat , que roda no espaço de usuário (intrinsecamente mais lento), que é a solução usada atualmente pelas distribuições convencionais, não será mais necessário. As ferramentas exfat-utils, do mesmo autor, por outro lado, continuarão sendo usadas. exFAT é um FAT32 sem o limi...

Local → Partition → From Image É possível especificar a mesma partição onde está a imagem como a de destino. Todos os arquivos existentes no volume serão apagados, com exceção da imagem se escolhermos preservá-la. Interessante. Parece que o sistema de arquivos é recriado, pois podemos restaurar imagem contendo NTFS sobre um volume FAT32 (provavelmente o contrário também funcione).

Creating ext4 filesystem A partir da suíte Ghost Solution Suite 3.0 , suporte ao Linux foi melhorado. Binários ELF x86-32 passaram ser distribuídos e suporte ao EXT4 foi adicionado. Contudo, há limitações. - Apenas EXT2/3/4 são suportados sem recorrer à opção -ia , que faz ineficiente cópia bit-a-bit. - Versão 12.0.0.10517+ é requerida para sistemas EXT4 com recurso 64bit ativo. - EXT4 com recurso metadata_csum não é suportado até a versão 12.0.0.10618 (última enquanto escrevo). Passou a ser usado por padrão a partir da versão 1.44 da suíte e2fsprogs (Debian e derivados adotaram a mudança na 1.43). É possível editar o arquivo /etc/mke2fs.conf antes de iniciar o instalador para reverter: --- /etc/mke2fs.conf 2018-03-24 19:13:28.000000000 +0000 +++ /etc/mke2fs.conf 2018-10-14 11:20:19.918861668 +0000 @@ -11,7 +11,7 @@ features = has_journal } ext4 = { - features = has_journal,extent,huge_file,flex_bg,metadata_csum,64bit,dir_nlink,extra_isize + features = has_jou...

Fiz algumas melhorias no suporte aos sistemas de arquivos EXT nesta versão. - UUID é definido pelo mke2fs no momento da formatação se o programa não for pré-histórico (1.41.4+). - Quando uma imagem contendo outro sistema de arquivos é convertida para EXT2/3/4, ext_attr é habilitado e inodes de 256 bytes são usados [1] e, para EXT4, além de extent , que é mandatório, huge_file , flex_bg , uninit_bg , dir_nlink e extra_isize são habilitados. É o conjunto de recursos base da suíte e2fsprogs 1.41, que manteve-se na série 1.42 em dispositivos menores que 16 TiB. 64bit não é habilitado incondicionalmente [2] como na versão 1.43, nem metadata_csum como na 1.44. - No upgrade de EXT2 para EXT3, tamanho original do inode é mantido. Assim, imagens de distribuições muito velhas, que usem EXT2 com inodes de 128 bytes, têm mais chance de serem transplantadas com sucesso para EXT3. - Upgrade de EXT2 revisão 0 para EXT3/4 funciona. Apenas para exatidão do código mesmo, pois tais siste...

Os programas cfdisk , fdisk e sfdisk , da suíte util-linux, voltaram a ser desenvolvidos de uns anos para cá. São particionadores modernos, que levam em conta a topologia do disco ao alinhar as partições e suportam GPT. Me concentrarei no sfdisk , a ferramenta scriptável. Existem duas formas de fornecer-lhe entrada . Esta é mais simples: início tamanho tipo booteável Os campos são separados por espaços, vírgulas ou ponto e vírgulas (uso vírgulas). Ao ser omitido, o programa adota um valor padrão para cada campo: início: primeiro setor livre tamanho: máximo disponível tipo: partição Linux, 0x83 (MBR/MS-DOS), 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (GPT) (ver sfdisk(8) para outros tipos) booteável: desabilitado (MBR/MS-DOS apenas) Ao criar mais de uma partição, cada uma é representada por uma linha. Exemplo: ,50G,L,* ,,L Primeira linha: - início: vazio (nada antes da vírgula), corresponde ao primeiro setor disponível, que, num disco limpo, considerando...

Mais recursos são preservados: 64bit , inline_data , metadata_csum , project , sparse_super2 . Ao restaurar imagens de sistemas de arquivos EXT num dispositivo igual ou maior do que 16 TiB (considerando blocos de 4 KiB), o programa comporta-se da seguinte forma. Sistema de origem EXT2 ou EXT3: - O programa abortará. EXT2 e EXT3 não suportam volumes dessa capacidade. A mensagem de erro recomendará adicionar mkfs=ext4 (exemplo: fsarchiver restfs imagem.fsa id=0,dest=/dev/sdxy,mkfs=ext4 ). É uma possível saída a partir do FSArchiver 0.8.5 . Sistema de origem EXT4: - Se e2fsprogs < 1.42, o programa abortará. É versão mínima que suporta 64bit . - Se e2fsprogs ≥ 1.42, os recursos 64bit e uninit_bg serão automaticamente habilitados, mesmo que não estejam presentes na imagem. O segundo é opcional, porém sem ele a formatação de dispositivos grandes demora uma eternidade (dependendo da velocidade, vários minutos!). Como trata-se de recurso antigo, presente desde o tempo em que ...

Fiquei um tempo afastado do EXT4. Por mais que mostre sua idade e seja considerado obsoleto pela Red Hat e Oracle, ainda é provavelmente o sistema de arquivos mais usado no mundo Linux. Existem trezentas opções que podem ser habilitadas ou não no momento da criação do sistema de arquivos. E mais! O mesmo pode ser feito em sistemas existentes. Antes que pensem que acho isso bom: não acho. Porém é assim que os EXT vêm sendo desenvolvidos há décadas; logo, saudemos a tradição! A partir do kernel 3.5, suporta checksums dos metadados. Considerado estável desde o 3.18. Quão estável? Não tenho ideia. Parte 1: 64bit Recurso adicionado na versão 1.42 da suíte e2fsprogs e presente desde o antigo kernel 2.6.28. O mke2fs (e atalho de conveniência mkfs.ext4 ) cria EXT4 com a opção 64bit ao detectar dispositivo igual ou maior que 16 TiB ( auto_64-bit_support = 1 em /etc/mke2fs.conf ) — mais especificamente 2 32 * tamanho_do_bloco (em 99% dos casos 4 KiB). Sem ele, não é possível format...

Aquele bug foi consertado na versão 12.0.0.10517 ( Ghost Solution Suite 3.1 Maintenance Pack 6 )! Volumes EXT4 criados com a opção 64bit são salvos e restaurados corretamente.

Desde 2015, o venerável Symantec Ghost [1] , parte da Ghost Solution Suite (atualmente na versão 3.1), voltou a ser atualizado , saindo da cansada versão 11.5.1 para a 12. Além de suportar oficialmente os Windows modernos (ver esta tabela ), também trouxe suporte [2] ao sistema de arquivos EXT4. Na 11.5.1, suportava apenas EXT2 e EXT3. Volumes EXT4 eram rejeitados com um tal erro 652 ( Attempted to access an inconsistent Linux partition ). Estranho não ter uma palavra sobre a novidade nas notas de lançamento . A versão 12 preserva todas as características de volumes EXT4 formatados com o mke2fs da série 1.42 [3] (via mkfs.ext4 ), com exceção de uninit_bg , que faz pouca diferença, pois afeta apenas o tempo requerido pelo e2fsck para verificar o sistema de arquivos. No entanto, se o sistema de arquivos tiver o recurso 64bit habilitado (a partir do mke2fs 1.43 o é por padrão), daí o programa falha por completo. Não é exibido erro algum ao criar e restaurar a imagem, porém o ...

EXT4 é legado Upcoming XFS Work in Linux v4.8 v4.9 and v4.10+ (Oracle Mainline Linux Kernel Development) Darrick J. Wong, da Oracle, juntou-se ao time de desenvolvimento do sistema de arquivos XFS e tem feito contribuições significativas. No kernel 4.8, foi adicionada mais uma árvore B+, que mapeia, dentro dos metadados, cada bloco a seu dono [1] . Na versão 4.9, foi introduzido suporte ao compartilhamento de extents, cujo pilar é outra outra árvore B+ [2] . Assim, copy-on-write [3] , um dos diferenciais do Btrfs, chega ao XFS [4] . Ambos recursos dependem do formato V5 e são experimentais. A árvore B+ adicionada no kernel 4.8 (rmapbt) será aproveitada a partir do kernel 4.11, que, confirmado o cronograma , trará capacidade de autoconsertar alguns problemas na estrutura do sistema de arquivos sem precisar desmontá-lo. Dependerá, no espaço de usuário, da ferramenta xfs_scrub da suíte xfsprogs [5] , que interagirá com o kernel através de uma nova requisição da chamada de s...