Mostrando postagens com marcador filesystem. Mostrar todas as postagens
Mostrando postagens com marcador filesystem. Mostrar todas as postagens

Android 13 pode receber ExFAT no lugar do FAT

FAT can be replaced by ExFAT on Android 13

Android 13 pode receber ExFAT no lugar do FAT

 Em Maio eu publiquei que o Android 13 poderia ter o sistema de arquivos ext4 substituído pelo ERFS da Hawei. Agora há rumores que o FAT também poderá ser substituído pelo ExFAT também. Se é verdade ou não, eu não sei pois não encontrei fontes sobre o assunto (caso você tenha encontrado no site do Google, deixe nos comentários para nos ajudar).

 Mas caso essa informação seja verdadeira, A empresa Google irá fazer um grande favor para todos nós. Vale lembrar que em Abril a Sony enviou vários patches para o Linux melhorando enormente o desempenho do ExFAT.

 O Android 13 será lançado em breve, enre o final de Julho e meados de Agosto e trará muitas novidades que podem ser conferidas no próprio blog clicando aqui.

Android 13 release preview
Previsão de lançamento do Android 13


ext4 deixará de ser o sistema de arquivos padrão do Android

Phones launching with Android 13 will use a new, space-saving file system format

ext4 deixará de ser o sistema de arquivos padrão do Android


 Foi publicado no site Android Police que o sistema de arquivos ext4 poderá deixar de ser utilizado como sistema de arquivos padrão no Android abrindo caminho para o EROFS (Enhanced Read-Only File System) da Huawei. A migração está prevista para o Android 13 e alguns dos benefícios de sua adoção estão relacionados a redução do tempo de boot (em torno de 22.9%) e potencial redução no tempo de downloads para as atualições além de menor perda de espaço de armazenamento.

 A Huawei já havia postado em seu Twitter em 2019 (e até mesmo enviado seu patch para o kernel neste mesmo ano) um pequeno comparativo entre o ext4 e o Erofs que apresenta ganhos superiores a 20% tanto em desempenho quanto em armazenamento.

Comparativo entre o ext4 e o erofs

 O EROFS não proporciona tais ganhos (armazenamento e desempenho) somente nas atualizações e no processo de boot, mas em todo o seu uso do sistema. Há mais comparativos com inclusive outros sistemas de arquivos que podem ser conferidos no próprio site Android Police. Todas as informações sobre o EROFS podem ser conferidos no próprio site do kernel (clicando aqui).

 O EROFS, de autoria de Xiang Gao, já utilizado no Android da Huawei em mais de 10 milhões de dispositivos. É um dos sistemas de arquivos com o melhor desempenho em compressão/descompressão e leitura por utilizar o algorítimo de compressão/descompressão LZ4 (sendo o mais rápido do mundo para tamanhos fixos).

 E falando de sistema de arquivos, compressão/descompressão e desepenho, não deixe de conferir o meu minicurso de atributos nos sistemas de arquivos do Linux que eu estou deixando com desconto para vocês bastando. Utilizado o cupom EROFSLZ4 você paga apenas US$12,99 (invertendo para LZ4EROFS você paga apenas US$9,99. Mas tem a duração de 5 dias somente)

CONCLUSÃO

 Este não é o fim do ext4 no Android; ele somente deixará de ser utilizado como sistema de arquivos padrão mantendo assim o seu suporte no sistema operacional. Conforme pode ser lindo no Source do Android clicando aqui, o Android possui suporte a ext4, f2fs, fuse, incfs, Vfat, EROFS e exfat a partir do kernel 5.10 (uma pena pois o kernel do meu Android é o 4.14 e assim acabo não tendo suporte ao exfat. Paciencia né; fazer o que?) e quem tem a ganhar é o usuário.


BTRFS vs ext4

BTRFS vs ext4

BTRFS VS EXT4


 No site reddit, um cara chamado leo_vir postou que havia formatado seu cartão SD do seu Steam Deck com o Btrfs reduzindo os jogos de 19.7GB para 14.6GB.


 Depois disso algumas pessoas começaram a perguntar se houve impacto do desempenho devido o recurso de compressão do sistema de arquivos. Com isso, Leo_vir postou outro teste demonstrando o desempenho com dois cartões microSDs de 16GB, sendo um formatado com o ext4 e outro com Btrfs+Zstd.

Cartão MicroSD formatado com o sistema de arquivos ext4

Cartão MicroSD formatado com o sistema de arquivos Btrfs

 Leo_vir utilizou o game Cities: Skylines com seu recurso loading screen mod não sendo necessário gravar manualmente quanto tempo leva para ser carregado já que recurso faz isso automaticamente. Outro ponto que que Leo_vir nota é que ele carregou o cenário 'Fix the Traffic' três vezes em cada microsd gerando os seguintes resultados:
btrfs+zstd                         ext4
First load = 1:01              First load = 1:29
Second load = 0:43          Second load = 0:54
Third load = 0:43             Third load = 0:52
 Depois Leo_vir criou uma partição no nvme do seu Steam Deck formatando-a com os dois sistemas de arquivos e realizando os mesmos testes. Os resultados podem ser conferidos a seguir:

btrfs + zstd                     ext4
First load = 0:43            First load = 0:43
Second load = 0:28        Second load = 0:27
Third load = 0:28           Third load = 0:27

 No caso do NVME, Leo_vir nota que não há diferença entre ambos os sistemas de arquivos a não ser pelo fato de compressão do Btrfs (eu notaria os demais recursos que você pode conferir nas minhas aulas como checksum, deduplicação e muito mais).

Sony melhora o desempenho do ExFat para Linux em mais de 73%

exfat: reduce block requests when zeroing a cluster

Sony melhora o desempenho do ExFat para Linux em mais de 73%

 Em Agosto de 2019 a Microsoft anunciou que estava trabalhando no suporte do ExFAT para Linux. Bom, o seu suporte apareceu no kernel 5.4 em Outubro dde 2020.
 A Microsoft chegou a abrir a especificação técnica do ExFAT, o que foi motivo o suficiente para que eu pudesse debater um assunto muito interessante, disponibilizar especificação técnica é mais importante do que abrir o código fonte:


 No dia Yuezhang Mo da Sony enviou o patch 1d404b899e322a3fed5d7af243d83bb9e71b1b78 intitulado exfat: reduce block requests when zeroing a cluster (exfat: reduza as solicitações de bloco ao zerar um cluster) que melhora o desempenho do ExFat entre 73.8% a 85.4%. Os testes foram realizados em um imx6q-sabrelite que tem como configuração CPU: 792 MHz x4; 1GB DDR3; cartão microSD SanDisk 8GB Class 4 e os testes foram feitos criando 1000 diretórios.

 Estas melhorias estarão disponíveis a partir do kernel 5.19.

Novidades no Btrfs 5.18

Btrfs 5.18

Novidades no Btrfs 5.18

 Em Janeiro eu publiquei sobre o lançamento do Btrfs 5.17. No inicio de Março foi anunciado os patches para a nova versão. Gabriel Niebler da empresa Suse anunciou o envio de 98 patches desenvolvidos pela equipe do Btrfs para a versão 5.18 do sistema de arquivos. Essa nova versão além de traz novos recursos, novas atualizações relacionadas ao VFS (o que é realmente necessário) e mais melhorias de desempenho.

 O ioctls permite que o user space ler ou escrever dados diretamente aos extents (futuramente permitindo compactação e encriptação), será utilizado pelo send/receive v2. O zoned trabalha com DUP metadados no mkfs.btrfs por padrão; melhorias nas mensagens de erros.

 Na parte de melhoria de desempenho, teve mais de 90% no directory logging; mais de 60% no avoid logging; também mais de 60% no avoid inode logging; rendimento de mais de 7% em extents; o fsync() para de copiar extents de arquivos antigos e melhoria logging de extents antigos depois de truncados.

 Agora o VFS permite reflinks/deduplication de dois pontos de montagem diferentes (do mesmo sistema de arquivos) além de exportar e adicionar helpers na verificação de leitura/escrita no ioctls.

 Como é de costume em qualquer software também houveram correções de bugs e limpezas. Essas atualizações estarão disponíveis no kernel Linux 5.18.

Reiserfs pode ser removido do kernel Linux

Reiserfs pode ser removido do kernel Linux

Reiserfs pode ser removido do kernel Linux

 Reiserfs ter os seus dias contatos no kernel Linux. Matthew Wilcox publicou a thread intitulada É hora de remover o reiserfs? explicando que "Manter o reiserfs na arvora tem certos custos." e que talvez pode não valer a pena. Existem certos recursos antigos mantidos no kernel Linux que são utilizados somente pelo Rieserfs e que acabam atrapalhando no desenvolvimento e implementação de novos. Além disso, o Reiserfs vem recebendo poucas correções de bugs (sendo a sua ultima em 2019 e não recebeu correção para o erro de y2038k) e pouco se tem noticia de pessoas que ainda fazem seu uso.

 O único motivo de ainda estar sendo mantido no kernel é devido não terem informações o suficiente da base de usuários; portanto, removê-lo poderia afetá-los diretamente. Então a primeira opção é esperar ter informações o suficiente e assim deixá-los ciente para que possam migrar para outro sistema de arquivos. Outra opção sugerida seria rebaixá-lo para somente leitura.

 Edward Shishkin pediu para que considerarem o patch que rebaixam as flags do Reiserfs escrito por Jan Kara da Suse que rebaixam as flags do reiserfs. No final das contas, todos (com exceção de Byron Stanoszek) estão concordando em sua remoção até mesmo para evitar que venha a ser utilizados em equipamentos mais recente que serão mantidos nos próximos 15 anos. O próprio Jan afirmou que a base de usuários do reiserfs é bem pequena e vem diminuindo e apesar de continuarem com builds do reiserfs nos kernels do openSUSE / SLES, o reiserfs não é mais oferecido para ambientes corporativos e também não possui mais módulo rpm.

 O rieserfs passou a ganhar muito destaque com recurso tail-packing que economizava espaço. Eu passei a entender seu conceito após ler a segunda edição do livro Descobrindo o Linux já citado muitas vezes por mim. Depois do que Hans Reiser (o autor do reiserfs e principal mantenedor) foi preso por assassinar sua esposa, o desenvolvimento do reiserfs desacelerou. Chegaram a desenvolver o reiser4 que implementa algorítimos balanced tree e o Reiser5 em 2019 mas não há muita esperança.

 A sugestão final foi de inserir uma mensagem de aviso que será descontinuado no hora de montar dispositivos e se ninguém se manifestar nos próximos dois anos, a equipe seguira em frente com o plano. Honestamente eu acho uma boa ideia já que nem se tem noticias de alguém que ainda utilize reiserfs e hoje temos sistemas de arquivos mais modernos; o próprio autor do Btrfs foi antigo mantenedor do reiserfs no Suse e incorporou certos conceitos no reiserfs no Btrfs. Então, segue-se adiante.
Thread do assunto

OpenZFS receberá suporte a expansão de RAID

RAID expansion comes to OpenZFS at last

OpenZFS receberá suporte a expansão de RAID


 Adicionar novos dispositivos a um sistema de arquivos Btrfs ou redimensiona-lo é algo muito simples devido a sua flexibilidade e eu ensino no meu curso de migração para Linux. O Btrfs ainda não implementa todos os recursos que o ZFS mas tratando de implementação dos mesmos recursos, o Btrfs está muito a frente do ZFS.

 Porém, e quanto ao ZFS? Esse é um recurso muito esperado no ZFS e que desde que surgiu (há uns 16 anos) que não havia sinais de um dia ter. Uma coisa que geralmente os admiradores do ZFS não contam (ao menos não no Brasil) é que o ele também possui suas limitações (algo que eu cheguei a abordar na minha série ZFS vs Btrfs).



 Porém, parece quem em breve o OpenZFS receberá suporte a expansão de RAID e a galera do FreeBSD comemorou com bastante entusiasmo.


 Até com certa razão porém, não vá com muita sede ao pote pois o recurso ainda tem suas limitações. Por enquanto parece que o recurso só funcionará no FreeBSD. Vamos aguardar para ver quando estará disponível para Linux.

 Eu promovo o Btrfs pois acho mais viável para o Linux. Apesar de ser possível utilizar o ZFS no Linux (o próprio FreeBSD passou a utilizar o ZFS on Linux como seu ZFS padrão), tanto é que Canonical passou a integrá-lo ao Ubuntu em 2016 e o habilitou no root em 2019, o problema do ZFS para o Linux está atrelado a incompatibilidade entre as duas licenças (a GPLv2 é incompatível com a CDDL). Lembrem que isso foi um problema muito grande no Debian quando Jörg Schilling mirgou o cdrtools de GPL para CDDL levando o debian a criar um fork.
 Outro problema que percebo e que geralmente as pessoas não admitem é que os bugs que levam muito tempo para serem corrigidos. Dois deles eu já postei aqui sendo o primeiro foi reportado pelo engenheiro que trabalhava exatamente no ZFS e que levou coisa de dois anos para ser corrigido e o outro está no seu recurso de deduplicação e que não há previsão para ser corrigido.

 De todos os recursos presentes no Btrfs (que não são poucos), dificilmente alguma coisa é instável (seu status pode ser acompanhado aqui). O que é um marco pois eles contam com uma equipe consideravelmente pequena e é mais novo que o ZFS.

Btrfs Status
Status do Btrfs

Além do mais, o recurso que todos tanto gostam no ZFS e esperam um dia ver no Btrfs, que é a criptografia transparente, está sendo trabalhando por um engenheiro do Facebook (leia sobre isso clicando aqui).

Marcadores

A pior história sobre Linux que já ouvi (5) A.I (1) ambiente gráfico (19) AMD (14) analise (10) Andriod (15) android (7) artigo (5) aws (1) bc (18) benchmark (5) BSDs (27) btrfs (31) bugs (1) Caixa de Ferramentas do UNIX (19) canto do Diego Lins (2) certificações Linux (7) Código Fonte (53) comandos (26) comp (1) compressores (5) container (6) CPU (19) criptografia (4) crowdfunding (9) cursos (24) daemons (13) Debian (31) desenvolvimento (82) desktop (19) DevOps (3) DevSecOps (3) dic (1) Dica de leitura (87) dica DLins (2) dicas do Flávio (27) Dicas TechWarn (1) diet libc (1) diocast (1) dioliunx (3) distribuições Linux (13) Docker (11) DragonflyBSD (21) ead Diolinux (2) edição de vídeo (5) EMMI Linux (4) emuladores (6) endless (5) English interview (3) Enless OS (2) entrevista (17) espaço aberto (82) evento (6) facebook (1) Fedora (10) filesystem (78) financiamento coletivo (2) fork (4) fox n forests (4) FreeBSD (20) Funtoo Linux (13) games (90) gerenciadores de pacotes (3) GOG (3) google (8) gpu (3) hardware (102) hash (1) helenos (3) I.A (1) init system (8) Intel (15) IoT (1) ispconfig (1) jogos (36) kde (1) kernel (134) lançamento (62) leis (1) LFCS (1) licenças (8) Linus (16) linus torvalds (2) Linux (194) linux foundation (3) linux para leigos (1) live (5) LPI (8) LTS (1) machine learning (1) matemática (5) mesa redonda (27) microsoft (6) microst (1) muito além do GNU (149) não viva de boatos (9) navegadores (3) NetBSD (7) novatec (17) novidades (1) nuvem (1) o meu ambiente de trabalho (3) off-topic (12) open source (83) OpenBSD (5) OpenShift (1) os vários sabores de Linux (39) padrim (2) palestras e eventos (5) partições (6) pentest (8) pipewire (1) processadores (27) professor Augusto Manzano (11) Programação (61) promoção (1) propagandas com Linux (8) Red Hat (21) redes (3) resenha nerd (4) Resumo da Semana do Dlins (2) resumo do Tux (19) retrospectiva Linux (1) risc-V (12) RISCV (11) runlevel (2) segurança digital (19) servidores (1) shell (3) sistema operacional (23) smartphones (3) Software livre e de código aberto (151) sorteio (3) Steam (9) Steam no Linux (7) supercomputadores (4) suse (7) systemd (7) terminal (84) terminal de comandos (12) toca do tux (1) toybox (23) tutorial (6) Tux (3) unboxing (7) UNIX (16) UNIX Toolbox (14) vartroy (1) vga (1) virtualização (1) vulnerabilidade (4) wayland (5) whatsapp (1) Windows Subsystem for Linux (2) wine (14) WoT (1) ZFS (14) zsh (2)