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

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).

Encontrada vulnerabilidade na deduplicação do Btrfs e do ZFS

Encontrada vulnerabilidade na deduplicação do Btrfs e do ZFS

Encontrada vulnerabilidade na deduplicação do Btrfs e do ZFS

 Deduplicação é uma técnica muito interessante para evitar redundância e duplicação de dados e assim melhor aproveitar os dados e metadados do sistema de arquivos. Este recurso é utilizado em sistemas de arquivos como o ZFS, o Btrfs e o Hammer do DragonflyBSD. Porém, esta semana foi descoberta uma vulnerabilidade muito grave neste recurso.
 
 Membros da universidade de Vrije  (Vrije Universiteit Amsterdam) encontraram uma falha de segurança no recurso de deduplicação dos sistemas de arquivos ZFS e Btrfs. O erro foi encontrado pelo grupo de pesquisadores Andrei Bacs, Saidgani Musaev, Kaveh Razavi, Cristiano Giuffrida, Herbert Bos que pretende apresentar na conferência FAST'22 (20th USENIX Conference on File and Storage Technologies) e tornar seu conhecimento publico  no dia 23 de Fevereiro deste ano.

 Essa vulnerabilidade ocorre especificamente no inline deduplication que permite o invasor utilizar uma classe de ataque chamada DUPEFS e obter arquivos sensíveis do sistema (e até arquivos secretos dos usuários) mesmo remotamente (tanto em LAN quanto em servidores na internet). Em seu paper, os pesquisadores apresentam como cada sistema de arquivos trabalha com inline deduplication para assim melhor entender como explorar a vulnerabilidade.

inline deduplication no ZFS e no Btrfs
Como cada sistema de arquivos trabalha com inline deduplication.

 Este paper possui 15 páginas muito bem detalhado apresentando todo o cenário do ataque e todos os seus resultados tanto no Linux (utilizando ambos os sistemas de arquivos) quanto no FreeBSD. Eu incentivo a todos acompanhar sua apresentação no evento já que se trata de uma vulnerabilidade grave e que os desenvolvedores irão precisar concentrar esforços na solução do problema.

 Isso significa que estamos em risco? Em partes pode ser que sim como pode ser que não. Primeiro que, apesar da vulnerabilidade ser grave, não são todos que conseguem explorá-la; segundo que no paper os pesquisadores apresentam algumas formas de defesa (em Deduplication Defenses) como medidas paliativas como forçar a criptografia e ofuscação imposta por um gateway intermediário na rede até que soluções sejam apresentadas.

 E terceiro é que há um ponto a se considerar aqui tratando-se de Btrfs (já estou ouvindo o chilique de que sou fanboy de Btrfs). Em minha série ZFS VS Btrfs mencionei que ambos os sistemas de arquivos oferecem recursos iguais PORÉM, implementados de formas diferentes e com técnicas diferentes; deduplicação não é uma exceção a essa regra. No vídeo primeiro video da série que você pode conferir abaixo, eu explico a diferença na implementação de recursos entre os dois sistemas de arquivos. Confiram a diferença entre a deduplicação de ZFS e do Btrfs:


 Ou seja, essa vulnerabilidade não afeta o Btrfs como mencionado no paper apresentado pelos pesquisadores, pois inline deduplication já não é utilizado no Btrfs há um bom tempo. Inline deduplication para o Btrfs foi desenvolvido pela Fujitsu como pode ser lido clicando aqui e já não é mais mantido (ele foi simplesmente abandonado pois a Fujitsu não tem mais planos para ele), os patches eram incompletos e este recurso é muito complexo para ser implementado no kernel Linux.

 Qu Wenruo que foi um dos autores do inline deduplication para o Btrfs informou aos pesquisadores o:
 "Como um dos autores originais, eu e o meu empregador não temos mais interesse em continuar dedupe. Além do mais, a implementação original possui um limite, um extent tem que ser escrito no disco antes que possa ser utilizado pelo write-time dedupe."
 Para deduplicação o Btrfs utiliza a técnica out of band deduplication (como mencionei no meu vídeo), o módulo ioctl e ferramentas em userspace como BEES.

 Moral da história

 O que os pesquisadores utilizaram na verdade foi uma versão muito antiga do btrfs (talvez de 4 anos atrás) e deveriam ter testando ao menos uma versão que possui out of band deduplication (de preferencia versões mais recentes do kernel Linux).

 Vou reforçar que já estou ouvindo me chamarem de fanboy de Btrfs (SARCASMO ON: Não são eles que são fanboys de ZFS ou do Ext4, sou eu que sou fanboy de Btrfs... Eu não apresentei nenhum argumento técnico, foi só coisa de fanboy mesmo... Sempre assim...)

 E por ultimo vamos ver se os sites (como o que postou o artigo Examinando o Btrfs, o sistema de arquivos do Linux perpetuamente semi-acabado) chegarão a publicar sobre essa falha no ZFS (honestamente eu duvido) pois esse já não é a primeira que eu posto. Alias, vamos ver quanto tempo vai levar para isso ser corrigido no ZFS. Basta lembrar do caso do alto consumo de CPU no ZFS por exemplo que levou anos para ser corrigido. Este caso pode ser lindo clicando aqui.

Novidades no Btrfs 5.17

Btrfs 5.17

Novidades no Btrfs 5.17


 Essa semana foi lançado o kernel Linux versão 51.6 e muitos sites como o OMG! Ubuntu e o XDE Developers descrevem que os gamers vão amar esta versão devido o recurso de futex2. Particularmente não encontrei essas notas no anuncio do Linus Torvalds. Eu encontrei até mesmo sobre o Batman (batman-adv e b.a.t.m.a.n. Abreviação de better approach to mobile ad-hoc networking) mas não sobre o que são demonstrados nos sites. Esse release está mais relacionado a correções e reversões do que novidades em si.
"Portanto, isso contém principalmente algumas correções de driver (principalmente rede e rdma), uma correção de uso de credencial do cgroup, algumas correções de rede principais, um algumas reversões de última hora e algum outro ruído aleatório. O shortlog anexado é tão pequeno que você também pode rolar isto."
 Bom, mas novidades também estão vindo aí no Btrfs (e provavelmente no kernel 5.17 já anunciado o seu desenvolvimento). David Sterba da equipe do Suse anunciou no dia 11/01/2022 a atualizações do Btrfs 5.17.

NOVOS RECURSOS

 Agora é possível que o send trabalhe com a realocação de grupo de blocos evitando que falhas ocorram; nova operação de exclusão 'balance paused' que, como o próprio nome já diz, permite adicionar um novo dispositivo ao sistema de arquivos com balance em pausa. o Btrfs também está com novo arquivo sysfs para armazenamento do fsid (em per-device directory) que ajuda a distinguir dispositivos quando seeding estiver habilitado.

MELHORIAS NO DESEMPENHO

 A exclusão de diretórios ficou entre 20% a 40% mais rápidos devido; o zoned mode ficou em torno de 50% durante a montagem; indexação e busca por tamanho com a latência de -30% e menos contenção de tree node locking que permite ganho de até 20%. A parte de desempenho já é uma característica muito boa do Btrfs e de longa data. Eu já até mesmo apresentei essa características em vídeos como benchmarks e comparações com ZFS.



CORREÇÕES DE BUGS

 Houveram correções de bugs (lógico) como falha no ENOSPC quando há escrita direta no range NOCOW; na quota de deablock (e outras operações de quotas); no free space tree e no zoned.

OUTRAS

 Houveram também outras melhorias e limpesas como na parte de HDD e SSD, como o file system lida com erros. Essas novidades ocorreram desde o kernel 5.16-rc8 e estarão disponíveis no link abaixo (um total de 115 mudanças).

Docker consumindo muito armazenamento no Btrfs

Moby/Docker gradually exhausts disk space on BTRFS
Docker consumindo muito armazenamento no Btrfs

 Containers são combinações de recursos do Linux como o namespace e cgroups. Recursos esse que eu já apresentei aqui no meu artigo Linux: Mais do que um Unix e trata-se dos mesmos recursos que são utilizados pelo systemd e por várias outras aplicações. Ferramentas como Docker e Kubernetes servem na verdade para facilitar o uso de tais recursos já que raramente as pessoas criam containers manualmente. Devido o Docker trabalhar com o recurso Copy-on-Write, o sistema de arquivos indicado na criação de seus containers é o Btrfs.

 No dia 02 de Novembro, Chris Murphy reportou a equipe do Btrfs um bug que ocorre no Docker que consome muito espaço de armazenamento. Esse é um bug que já havia sido reportado em Outubro de 2016 por um usuário chamado no GitHub de Ghost e ainda permanece em aberto.
 Ghost explica como reproduzir tal bug e acaba sendo de forma muito simples:
  1. Instale o docker em um sistema com btrfs
  2. Utilize o docker intensivamente por um tempo e certifique-se de remover & recriar os containers, rebuild com a opção no cache e reiniciar o sistema, ...
  3. Após isso, confira o espaço em disco
 Chris chega a mencionar que não sabe de quem é o bug; se do Docker, ou do driver btrfs "graph" que o Docker utiliza, ou se é um bug do kernel (btrfs) e que pode haver mais de um bug.

Docker gradually exhausts disk space on BTRFS #27653
Docker consumindo muito armazenamento no Btrfs

 Nikolay Borisov da Suse que isso pode estar relacionado ao comportamento das pessoas não sabendo como utilizar Docker. Nikolay reforça que apenas excluir um container não significa que obterá o espaço livre sendo necessário executar prune -a.
"Eu realizei um monte de testes hoje inciando um container, parando, excluindo-o, podando (pruning) images e tudo funcionou como esperado." Mencionou Nikolay
 Chris diz que agora se questiona se esse é um comportamento único do btrfs graphdriver e que talvez precisam realizar o mesmo conjunto de testes com o btrfs graphdriver, reset, depois repetir a operação  com o overlay2 graphdriver e verificar se há uma diferença significativa.

 No decorrer das semanas veremos se realmente há um problema que irão trabalhar para solucionar ou se trata-se de um falso positivo.

O estranho caso do ZFS consumir muita CPU

O estranho caso do ZFS consumir muita CPU
O estranho caso do ZFS consumir muita CPU

 Por mais que muitos pintam a imagem do ZFS como um sistema de arquivos indestrutível, ele também possui suas ventagens e desvantagens (como tudo no mundo, lei natural). Eu já abordei esse assunto em uma série do meu canal chamado ZFS vs Btrfs. Quem vence essa batalha.
 E por mais que seus defensores não consigam admitir, o ZFS também possui seus defeitos. Dois deles já foram mencionados aqui sendo o um o seu alto consumo de RAM e o outros o grande problema com de fragmentação.
 No dia seis de Setembro, Brendan Gregg relatou em seu blog um problema muito estranho que ocorre com o ZFS. Uma equipe de microsserviços o contatou apresentando o caso em que o ZFS estava consumindo sozinho 30% da capacidade de CPU. E por que exatamente a Brendan Gregg? Para quem não o conhece, Brendan Gregg já foi representante senior Solaris na Netflix, engenheiro de kernel, já foi desenvolvedor do Solaris onde ficou conhecido na área de performance concentrando seus esforços na primeira nuvem baseada em container do mundo e no primeiro dispositivo de armazenamento ZFS no mundo.

 Brendan ainda é engenheiro senior de performance na Netflix voltando seus esforços para o Solaris, Linux e FreeBSD e ainda mantem seus trabalhos voltados ao ZFS sendo o desenvolvedor do ZFS L2ARC e de várias outras ferramentas que geraram economia mundial de US$1bilhão (além de suas ferramentas terem dado origem a várias startups). Brendan é também internacionalmente conhecido como expert em performance na área de computação sendo desenvolvedor de várias ferramentas de analise para tal fim, 
gwhiz
gwhiz, uma das ferramentas desenvolvidas por Brendan Gregg em perl que eu gosto.
 
 Mas voltando ao caso do ZFS, esse é um caso que Brendan já apresentou em 2017 na kernel recipes e sua primeira ideia foi algum engano que cometeram durante a configuração:
"Eu trabalhei nos componentes internos do ZFS na Sun Microsystems e, a menos que esteja mal configurado, não há como consumir tanta CPU."
 Foi aí que começou toda a surpresa. Brendan começou utilizando uma ferramenta da Netflix de monitoramento e nuvem chamada Atlas e de cara o ZFS estava consumindo 38% de CPU; algo muito incomum nada carga de trabalho na nuvem da Netflix. Depois de outras analises com outras ferramentas como o Vector e supos através disso que o problema estava relacionado a containers. O que para a surpresa de todos é que eles não estava utilizando containers e nem o ZFS...

Ferramenta Vector da Netflix
Ferramenta Vector da Netflix

 Brendan então começou a debugar o sistema com comandos do sistema mesmo como df -h, mount e zfs list e estranhamente e ZFS não estava montado. Brendan então deduziu que containers poderiam ter sido criados anteriormente e destruídos; então Brendan decidiu analisar os arcstats que são contadores do kernel que rastreiam estatísticas do ZFS e o resultado foi que os contadores estavam zerados, o ZFS não estava montado e mesmo assim o ZFS estava consumindo 30% de CPU.

arcstats do ZFS
arcstats do ZFS

 Foi aí que Brendan decidiu olha o flame graph do Vector mais de perto e depois verificar no código fonte e no histórico de alterações e encontrou o erro no ARC que tinha como intenção melhorar o desempenho e acabou gerando tamanho problema.

 Brendan abriu a requisição de numero 6531 no GitHub da equipe do Open ZFS em 2017 (ano em que abordou esse assunto) que desde então vem dando atenção especial ao ARC e assim, não teve mais notificações por parte do cliente.

Marcadores

A pior história sobre Linux que já ouvi (5) A.I (1) ambiente gráfico (19) AMD (14) analise (9) Andriod (14) android (5) artigo (5) aws (1) bc (15) benchmark (3) BSDs (27) btrfs (30) bugs (1) Caixa de Ferramentas do UNIX (19) canto do Diego Lins (2) certificações Linux (7) Código Fonte (53) comandos (24) comp (1) compressores (5) container (6) CPU (19) criptografia (4) crowdfunding (9) cursos (24) daemons (13) Debian (31) desenvolvimento (80) desktop (19) DevOps (3) DevSecOps (3) dic (1) Dica de leitura (86) 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 (20) ead Diolinux (2) edição de vídeo (5) EMMI Linux (4) emuladores (5) endless (5) English interview (3) Enless OS (2) entrevista (17) espaço aberto (82) evento (6) facebook (1) Fedora (10) filesystem (75) 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 (101) hash (1) helenos (3) I.A (1) init system (8) Intel (15) IoT (1) ispconfig (1) jogos (36) kde (1) kernel (134) lançamento (60) 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 (4) mesa redonda (27) microsoft (6) microst (1) muito além do GNU (146) 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 (82) 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 (60) 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 (1) runlevel (2) segurança digital (19) servidores (1) shell (3) sistema operacional (22) smartphones (3) Software livre e de código aberto (150) sorteio (3) Steam (9) Steam no Linux (7) supercomputadores (4) suse (7) systemd (7) terminal (83) terminal de comandos (11) toca do tux (1) toybox (23) tutorial (6) Tux (3) unboxing (7) UNIX (16) UNIX Toolbox (14) vartroy (1) vga (1) vulnerabilidade (4) wayland (5) whatsapp (1) Windows Subsystem for Linux (2) wine (14) WoT (1) ZFS (13) zsh (2)