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

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.

Anunciado o fim do Project Trident

PROJECT TRIDENT SUNSET

 Project Trident iniciou em 2018 como uma distribuição para desktop baseado no TrueOS. Com o fim do TrueOS, dois membros adotaram porções do seu desktop e reconstruíram a distribuição e em 2019 anunciaram que iam abandonar a base do TruOS/FreeBSD e iam basear no Void Linux. A transição foi concluída em Fevereiro de 2020.

 Alguns dos principais recursos do Project Trident era a interface Lumina como ambiente gráfico padrão, o ZFS como sistema de arquivos padrão, criptografia para todos os dados, facilidade de uso e muito mais.

Ambiente gráfico Lumina

Lightweight Desktop Environment

 Infelizmente, o projeto anunciou o seu fim no dia 29 de Outubro devido a pandemia. Não está descrito exatamente assim, mas a informação do anuncio de seu fim deixa isso muito claro.
"Com as mudanças e eventos nos últimos dois anos na vida, trabalhos, família e etc; nossas prioridades individuais tem mudado também."

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.

ZFS VS Btrfs#1 Quem vence essa batalha?

ZFS VS Btrfs#1 Quem vence essa batalha?

 Que o ZFS é um sistema de arquivos poderoso, isso todo mundo sabe. Mas será que as pessoas  realmente conhecem o verdadeiro poder que o Btrfs possui? Assunto um tanto quanto polêmico, mas estou dando inicio a essa mini série analisando o que ambos os sistemas de arquivos  comparando o que possuem em comum e depois analisar seus prós e contras. Não entro no mérito de licenças pois, além de ser um assunto já muito debatido, entro na questão somente de recursos.


 Há algum recurso que tanto o Btrfs quanto o ZFS possuem em comum que você conhece e que eu não mencionei? Deixe seu comentário ;)

Lançado novo Minicurso de atributos no Linux

OpenZFS abandona o termo slave em seu código

OpenZFS abandona o termo slave em seu código
OpenZFS abandona o termo slave em seu código
 Na Quarta Feira (dia 10 de Junho) o desenvolvedor Matthew Ahrens da ZFS founding enviou  a pull request para o git do projeto OpenZFS. Não se trata de um bugfix ou adição de novos recursos e sim um cleanup alterando o termo "slave" para "dependents" de todo o código do OpenZFS.

 Na request, Matthew explica que sua motivação é que o efeito horrível da escravidão humana continua a afetar a sociedade e que o termo "slave" na computação é uma referencia desnecessária para uma dolorosa experiencia humana.

Pull Request de Matthew Ahrens
Pull Request de Matthew Ahrens
 A pull requeste foi aceita e a partir de agora iremos passar a utilizar o termo deps no ZFS. Então, fica a dica para irem se adaptando ao novo termo; não é algo que vai impactar no trabalho de ninguém, não é algo que necessite toda uma curva de aprendizado, é simplesmente uma mudança de termo.

 Esse já não é o primeiro caso que vemos acontecer no mundo de software que há a iniciativa de adotar um novo termo devido o anterior ser ofensivo. Pouco antes do escândalo em que Stallman se envolveu, um grupo resolveu criar um fork do editor de imagens Gimp pelo mesmo motivo. O fork recebeu o nome de Glimpse (vislumbre) já que o nome Gimp pode referir-se a vários termos ofensivos de acordo com o site Merriam.

Site oficial do editor de imagem Glimpse
Site oficial do editor de imagem Glimpse
 Será que o Bash não vai entrar na mesma onda? Há pouco tempo anarquistas apareceram segurando placas com a frase "IT TAKES A BULLET TO BASH A FASH" (é necessário uma bala para esmagar um arrogante). Em inglês, o termo bash tem os significados pancada, bater, xingar, esmagar, surrar.

 OK, podemos até afirmar que no caso terminal, Bash é o acrônimo de Born Again Shell fazendo referencia e homenagem ao terminal Born Shell e não tem nenhuma intenção de expressar nenhumas das palavras que mencionei. Sim, é verdade, mas o Gimp também não pois seu nome é a abreviação de GNU Image Manipulation Program e anteriormente (antes de integrar o projeto GNU) era General Image Manipulation Program e mesmo assim resultou em um fork por conta de seu nome... Como diria o grande pensador contemporâneo:
Se Gimp quer dizer GNU Image Manipulation Program e GNU quer dizer GNU is Not Unix e Unix quer dizer UNiplexed Information and Computing Service for UNIX; logo, o nome Gimp quer dizer GNU is Not UNiplexed Information and Computing Service for UNIX Image Manipulation Program.
 Se tem duas outras expressões que também deveriam pensar em mudar é o nome de #! (te garanto que vai encontrar certas coisas que não estava esperando) e do comando word counter (wc, parece banheiro em inglês). Geraçãozinha viu...

CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.
CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.

Lançado zfs on 0.8.4

Lançado zfs on 0.8.4
Lançado zfs on 0.8.4
 Mais ou menos no dia 13 de Maio foi lançada a versão 0.8.4 do Zfs on Linux (ou simplesmente ZoL). A situação ainda não melhorou desde que Linus disse para não utilizar o Zfs no Linux devido a incompatibilidade entre ambas as licenças. mesmo assim os projetos estão a todo o vapor querendo adotá-lo em seus repositórios.


 O ZoL 0.8.4 é compatível com o kernel 2.6.32  ao 5.6 (e já está trazendo compatibilidade com o kernel 5.7 que está em candidato a lançamento número 7 no exato momento em que escrevo). Não há grandes novidades nesta nova versão (mas que não desconsidero) que traz apenas correções de bugs e pequenas correções pequenos detalhes além da adições de recursos menos que estavam faltando e melhorias no desempenho. Tratam-se de recursos de baixo nível mais na linguagem de desenvolvedores. Tais informações podem ser lidas nos links na descrição deste artigo.


CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.
CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.

Bcachefs - O sistema de arquivos que promete desbancar o BTRFS e o ZFS

Bcachefs - O sistema de arquivos que promete desbancar o BTRFS e o ZFS
Bcachefs - O sistema de arquivos que promete desbancar o BTRFS e o ZFS
 bcachefs, um Sistema de arquivos CoW que está sendo desenvolvido pelo ex engenheiro de software do Google Kent Overstreet e que promete não apenas não desaparecer com seus dados mas também desbancar os sistemas de arquivos BTRFS e o ZFS. Este sistema de arquivos faz uso de uma tecnologia do Linux chamada Bcache (abreviação de block layer cache) que permite a melhoria do desempenho dos dispositivos de armazenamento. É possível entender melhor sobre a tecnologia Bcache através deste link da Suse



 Nesta live mencionei o que acredito que a equipe do bcachefs deveria fazer que é realizar seu trabalho em um dos dois sistemas de arquivos (no BTRFS ou no ZFS) criando um fork ao invés de desenvolver um sistema de arquivos do zero. Talvez isso faria com que a equipe do bcachefs gastasse menos energia, tempo e dinheiro (ou pode ser que não). Talvez você pode estar pensando que isso seria mais trabalhoso pois teriam que reescrever partes inteiras do sistema de arquivos para deixar nos padrões que queiram, mas já temos caso que ocorreram desta forma.

 Neste artigo que fiz para o lançamento do DragonflyBSD 5.6 descrevo que reescreveram grandes partes dos sistemas VM system e do PMAP systemNas notas de lançamento também é descrito que a parte de código do filesystem sync do HAMMER2 foi reescrito para obter melhoria de desempenho.

 Era isso o que eu acredito que Kent Overstreet e sua equipe deveriam ter feito.  Além do mais, estamos tratando de menos de 4 megabytes (no caso do Btrfs. Já o Zfs on Linux possui 29 Megabytes) e não de 700 Megabytes.

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)