Embaixo dessa história toda tem uma decisão que quase ninguém faz conscientemente: o filesystem. O Synology usava btrfs o tempo todo. O QNAP usa ZFS. E a sua máquina Linux, muito provavelmente, veio de fábrica com ext4 sem ninguém te perguntar nada. É sobre isso.

De onde vieram os dois

O ext4 é o final de uma dinastia de mais de três décadas. O ext (extended filesystem) nasceu com o próprio Linux, o ext2 virou padrão nos anos 90, o ext3 adicionou journal em 2001 pra não precisar de fsck épico depois de cada queda de energia, e o ext4 chegou em 2008 com extents, alocação atrasada e volumes de até 1 exbibyte. O objetivo de design sempre foi o mesmo: ser o filesystem padrão, rápido, simples e previsível. Ele é excelente nisso. E parou aí.

O btrfs nasceu em 2007, na Oracle, com o Chris Mason, com um objetivo completamente diferente: ser a resposta do Linux ao ZFS. Em vez de escrever dado por cima de dado, ele é copy-on-write: toda escrita vai pra um bloco novo e os ponteiros são atualizados em cascata na árvore. Essa decisão única é a mãe de tudo que interessa nele.

O que cada um entrega, na lista:

ext4:

• journaling (metadados consistentes depois de queda)
• extents e alocação atrasada (boa performance)
• maduro, estável, em todo lugar, qualquer ferramenta funciona

btrfs:

• copy-on-write em tudo
• checksum de dados e metadados em cada bloco
• snapshots instantâneos e baratos
• subvolumes independentes dentro do mesmo volume
• compressão transparente (zstd, lzo, zlib)
• RAID nativo e scrub (varredura de verificação)
• send/receive de snapshots pra backup incremental
• reflinks (cópias que não duplicam blocos)

A lista já responde a pergunta do título. Vamos por partes.

Até o NTFS e o APFS passaram o ext4

E se a comparação com o btrfs parece injusta, olha pro lado. O NTFS nasceu em 1993, com o Windows NT, já com journaling de metadados e ACLs, e ainda nos anos 2000 ganhou o log de todas as mudanças do volume e as cópias de sombra (o “Versões Anteriores” do Windows). O APFS, que a Apple lançou em 2017 feito pra flash, é copy-on-write como o btrfs: snapshots nativos (é o que o Time Machine usa pra restauração local), clones instantâneos de arquivo que compartilham blocos, volumes compartilhando o espaço do mesmo container e criptografia por arquivo.

Leia de novo a lista do ext4 e compare: sem snapshot, sem checksum de dados, sem CoW, sem compressão. O filesystem do Windows e o do Mac, que ninguém considera exemplos de sofisticação, protegem os seus dados melhor que o padrão do Linux, cuja última grande feature saiu em 2008. O btrfs é o que coloca o Linux na mesma geração dos outros dois, e não uma década atrás.

Por que o btrfs é muito superior

O que é copy-on-write, pra quem nunca parou pra pensar

Nos filesystems clássicos, a escrita é destrutiva por definição: atualizar um bloco significa gravar o conteúdo novo por cima do velho, no mesmo lugar do disco. Se a máquina morre no meio da escrita, o arquivo fica metade velho, metade novo. O journal do ext3/ext4 cobre isso para os metadados (a estrutura de diretórios não corrompe), mas o seu dado em si fica por conta da sorte.

Copy-on-write inverte a ordem: nada nunca é sobrescrito. Escrever num arquivo aloca um bloco novo, grava o conteúdo novo ali, e só quando está tudo seguro no disco o filesystem troca os ponteiros pra versão nova, de forma atômica. A qualquer instante, você tem ou a versão velha inteira ou a versão nova inteira. Nunca uma mistura das duas.

O que isso compra na prática:

• Snapshots quase de graça. Os blocos velhos já persistem por natureza do CoW; um snapshot é só o filesystem segurando o ponteiro de raiz daquele instante, pura contabilidade.
• Queda de energia não corrompe. Uma escrita interrompida deixa a versão anterior intacta, porque ela nunca foi tocada. Pra quem já perdeu imagem de VM ou banco de dados pra queda no meio da escrita, isso vale o filesystem inteiro.
• Verificação possível. Como cada bloco é escrito uma vez e nunca mexido, faz sentido guardar checksum dele pra sempre. É a base da proteção contra corrupção que detalho mais abaixo.

O custo existe e eu pago ele sabendo: arquivos de escrita aleatória intensa (disco de VM, banco de dados) fragmentam e duplicam bloco, porque cada reescrita vira um bloco novo. Pra esses casos se desliga o CoW por diretório com chattr +C, que precisa ser marcado antes do arquivo ser criado. No meu layout, a imagem de VM feita com o +C certo ficou saudável; a feita sem virou o caso de fragmentação de livro-texto.

Snapshots são a feature que muda a sua vida

Snapshot no btrfs é uma foto instantânea de um subvolume, e custa quase nada, porque o CoW já mantém os blocos velhos enquanto alguém referencia eles. Criar um snapshot é operação de segundo, não de horas. Na prática: antes de cada upgrade, o sistema tira uma foto. Se o upgrade quebrar, você não “desinstala pacote”: você boota de volta na foto anterior e pronto. A seção de recuperação de boot, mais abaixo, mostra isso acontecendo de verdade.

Subvolumes são o jeito certo de organizar o disco

Subvolume é um namespace independente dentro do mesmo filesystem, com política própria de snapshot. E tem uma propriedade matadora: snapshot não é recursivo. Um subvolume filho dentro de outro fica automaticamente de fora do snapshot do pai.

Eu uso isso pra tudo. No meu desktop, os diretórios de cache que dá pra baixar de novo (mise, rustup, npm, opencode, caches de IA) estão virando subvolumes aninhados dentro do @home: ficam no mesmo lugar pra qualquer programa, mas de fora de qualquer snapshot. Só essa separação tira 165 GiB de escopo de snapshot, e os caches grandes (Hugging Face, yay, uv, pip) já moram fora do volume do sistema, com symlinks apontando pra eles: menos 148 GiB de snapshot, parte já migrada e parte em andamento. O snapshot fica pequeno, o restore fica rápido, e o que pode ser rebaixado da internet nunca entra na foto.

O custo real, medido no QNAP novo (ZFS, mas a matemática de CoW é a mesma): 27 snapshots de hora em hora de uma pasta com quase 80 TB, e quase todos consomem megabytes, porque entre uma hora e outra quase nada mudou. Snapshot barato é o que permite essa rotina existir sem culpa.

Deduplicação por reflink

Antes, a ressalva que importa: o btrfs não tem deduplicação online nativa igual ao ZFS (que mantém uma tabela de dedup em RAM e cobra caro por isso). O que ele tem são duas coisas práticas: reflink e dedup offline. Reflink é cópia que compartilha blocos: cp --reflink=auto cria um arquivo novo que aponta pros mesmos blocos do original, instantâneo e de graça, e cada um passa a divergir só onde for escrito. Na era de dezenas de checkouts, worktrees e builds parecidos, isso economiza uma montanha de blocos. Pra dedup retroativo existem ferramentas de userspace como duperemove e bees.

Proteção contra corrupção de verdade

Todo bloco do btrfs, dado ou metadado, carrega checksum. Quando o filesystem lê e o checksum não bate, ele sabe que o bloco apodreceu, e se houver uma segunda cópia (RAID ou metadata DUP) ele se autocorrige. O ext4 não checa dado nenhum: bit rot passa silencioso até você abrir o arquivo anos depois.

Duas peças da minha configuração mostram o que isso compra na prática, e o que o ext4 simplesmente não oferece. A primeira é o metadado em modo DUP. Num ext4, cada estrutura do volume existe uma vez só: um setor ruim bem posicionado corrompe a tabela de diretórios e o disco inteiro deixa de montar. No btrfs, mesmo com um único disco, todo bloco de metadado existe duplicado. O setor ruim continua existindo, mas o checksum acusa o bloco podre na leitura e a segunda cópia responde no lugar, sem você perceber. É a diferença entre perder o volume e anotar um aviso no log.

A segunda é o scrub mensal. Um ext4 nunca relê nada pra conferir saúde: se um bloco apodrece, você descobre no dia em que alguém tenta abrir aquele arquivo específico, talvez anos depois, quando já não tem conserto. O scrub é uma varredura agendada que relê o volume inteiro validando checksums, e encontra a podridão enquanto ela ainda é pequena e recuperável. Quando o contador do btrfs device stats sai de zero, é a sirene pra trocar o disco antes do desastre, não depois.

Compressão transparente, medida

Todo mount do meu desktop usa compress=zstd:1. O nível 1 custa uns pontos percentuais de um núcleo de CPU, e o btrfs detecta o que não comprime (blob de modelo, vídeo) e grava cru, sem custo. O resultado, medido essa semana nos meus dois discos novos:

São 630 GB de espaço grátis em 2,2 TB: 15% a mais de disco, sem pagar nada. Na migração inicial o ganho foi ainda maior, 45% no volume de sistema, porque havia mais texto e menos binário. Repare nos detalhes da tabela: programas e bibliotecas comprimem bem, camadas de Docker comprimem melhor ainda (39%), log de texto comprime 4,5x, e peso de modelo de IA não comprime nada, o que é esperado e não custa nada. Código-fonte, que é o que mais produzimos na era da IA, comprime lindamente.

Synology usa btrfs, QNAP usa ZFS

Sendo justo com o ZFS: pra NAS grande ele é superior, e foi o que eu escolhi pro QNAP. Checksum e autocorreção nativos, RAIDZ maduro, send/receive excelente. O preço é complexidade e recurso: o ZFS quer RAM pro cache ARC (meu QNAP tem 7 GB pra um pool de 174 TB, e sinto a falta), a deduplicação online dele precisaria de uns 190 GB de RAM só pra tabela no meu volume, e o modelo de provisionamento dele me deu um susto de graça quando o snapshot foi recusado com 20 TB livres (a história do thick vs thin está no artigo do NAS).

O btrfs é o equilíbrio certo pra máquina de consumo. Leve, nativo no kernel, faz quase tudo que o ZFS faz sem exigir um administrador de storage. Desktop, notebook, homelab, NAS pequeno ou médio: btrfs. O Synology provou na prática, duas vezes: o volume btrfs sobreviveu legível com dois discos fora, e os snapshots dele salvaram 11 álbuns que eu deletei por engano no meio da limpeza, byte a byte.

NAS grande e sério, com RAM de sobra: ZFS. Todo o resto: btrfs. E pra máquina Linux de uso pessoal, não é nem discussão.

Recuperação de boot por snapshot

A feature que já me salvou de verdade, contada nas duas máquinas.

No desktop, o Omarchy configura o snapper pra tirar snapshot antes de cada update e o limine-snapper-sync publica cada snapshot como entrada de boot no Limine. Kernel novo não sobe? No menu de boot você escolhe o snapshot de ontem e a máquina volta como se nada tivesse acontecido. Na minha máquina a rotina agendada roda via Timeshift em cron (a cada boot e de hora em hora), com o snapper cobrindo os pontos de update: o mecanismo de retorno é o mesmo. (A gotcha: cada entrada de snapshot carrega a imagem do kernel junto, então ESP pequena enche rápido. A minha de 1 GB já recusou um update de kernel por falta de espaço; o sistema seguiu bootável no kernel velho, que é o comportamento certo.)

No servidor, que roda openSUSE MicroOS, é ainda mais forte: o sistema inteiro é btrfs transacional, e cada update é um snapshot novo. Semana passada, o kernel 7.2.9 derrubou o controlador NVMe em silêncio, duas vezes, no meio do backup noturno. O conserto foi um transactional-update rollback e um reboot de volta pro 7.2.6, que rodou a carga inteira (754 GiB de leitura de backup com download concorrente) sem um soluço. Regressão de kernel virou reboot agendado, não madrugada de recovery. Uma ressalva documentada: o /etc mora dentro do snapshot, então o rollback desfaz mudanças de configuração junto. Depois de qualquer rollback, confira de novo as suas units.

Manutenção não é opcional (e o arquivo deletado que não some)

Filesystem CoW moderno entrega muito, mas cobra duas rotinas que o ext4 nunca pediu.

A primeira é o scrub, que já apareceu aqui: reler tudo e conferir checksums, mensalmente, em todas as máquinas. Ele é o detector de bit rot em ação, e sem ele o checksum só te avisa da podridão quando você tentar ler o arquivo. O segundo ponto é mais sutil: snapshot prende bloco de arquivo deletado. Quando você apaga um arquivo dentro de um subvolume com snapshot, o espaço não volta, porque o bloco continua referenciado pela foto. Foi exatamente o que aconteceu no meu NAS: a limpeza de 2,14 TB que rodei no Synology só liberou espaço de verdade depois que os snapshots velhos foram removidos; até lá, os blocos ficaram presos.

O tratamento é rotina simples. A retenção tem que ser automática, com o snapper ou o Timeshift apagando os snapshots antigos conforme a política (no QNAP, a política de retenção do Snapshot Manager faz o mesmo papel). Espaço que não volta depois de deletar snapshot velho geralmente é chunk alocado demais: um btrfs balance start -dusage=50 devolve os pedaços pouco usados pro pool livre (aqui em casa eu não agendo balance cego, eu monitoro o espaço não-alocado e ajo quando aperta). E no lado do restic, forget sozinho só remove a referência do snapshot: o espaço do repositório só é recuperado com o prune junto, forget --prune.

A limpeza da casa na era do AI coding

Agora a parte que quase ninguém conecta com filesystem: a era do agente produz lixo em velocidade industrial. Eu sei porque medi.

• Rust é o maior poluidor de disco do mundo dev. Cada build deixa pra trás binários de teste de 100 a 180 MB, e eles se acumulam a cada edição. No meu desktop, os diretórios target/ somavam 920 GiB. Só o ai-memory respondia por 704 GiB. A ferramenta de higiene que eu usava é o cargo-sweep, semanal. Um leitor avisou que o projeto se declara sem mantenedor, e o próprio README manda pro cargo-clean-all, que faz diferente: em vez de podar artefato velho dentro de um target/, ele acha todos os projetos Rust abaixo de um diretório e apaga o target/ inteiro dos que você filtrar, por exemplo cargo clean-all --keep-days 7 ~ pra limpar só o que não compila há uma semana.
• Docker não fica atrás. Na minha máquina achei 1,26 TB de build cache mais 938 GB de imagens. Uma faxina única recuperou uns 600 GB. No servidor, a limpeza semanal recolhe de 0,6 a 4,5 GB todo domingo.
• Caches de IA e de pacotes incham quietos. O cache do Hugging Face tinha 86 GB até eu apagar três modelos mortos e ele cair pra 21. Pacman tinha 22 GB de pacotes superados. yay, uv e pip, mais 125 GB.
• E os agentes criam diretórios temporários sem pedir licença. Projeto complexo com várias branches significa worktrees, e cada worktree de release tem seu próprio CARGO_TARGET_DIR cheio de binário de teste. No ai-memory isso já estourou o disco, e virou regra obrigatória no AGENTS.md do projeto: depois de cada release, cargo clean em cada worktree criado e remoção dos worktrees terminados, sem exceção.

A solução é automatizar o varrimento. O meu exemplo mínimo, um timer de usuário que roda dia 1 e 15 de madrugada, com Nice e I/O idle:

• apaga diretórios target/ de projetos parados há mais de 14 dias
• limpa o cache do yay
• poda só o build cache do Docker com mais de 30 dias, nunca imagem ou volume

E a parte que virou padrão aqui em casa: instruir os agentes a limpar o que criam. Três regras reais dos meus projetos, pra você copiar:

No AGENTS.md do desktop: “Nunca rode limpezas amplas como docker system prune sem autorização explícita do usuário depois de um inventário read-only. Limpeza usa lista exata de IDs; parado, antigo ou sem referência não significa descartável.”

No CLAUDE.md do homelab: “Antes de terminar qualquer tarefa, remova as coisas temporárias que a tarefa criou, e só elas. Nunca delete o que você não criou ou não consegue atribuir à tarefa. Na dúvida, liste pro dono.”

No AGENTS.md do ai-memory: “target/ cresce sem limite: cada edição num crate compartilhado deixa pra trás uma cópia de cada binário de teste de 100-180 MB (visto a 157 GiB). cargo sweep --time 7 semanal, e cargo clean obrigatório depois de cada release.”

E o backup de verdade: restic

Snapshot mora no mesmo disco, então snapshot não é backup: se o disco morre, o snapshot morre junto. O último item do kit é o restic, que pra mim é o melhor sistema de backup do Linux hoje.

O restic é um binário único, open source, escrito em Go, que faz backup deduplicado, criptografado e versionado pra praticamente qualquer destino: outro diretório, outro NAS via SFTP ou REST, S3, Glacier. O truque central é o content-defined chunking: ele fatia cada arquivo em blocos de tamanho variável definidos pelo conteúdo, tira o hash de cada bloco e só grava no repositório os blocos que ainda não existem lá. Por isso o delta é barato: o backup de hoje carrega os blocos que mudaram desde ontem, não os arquivos que mudaram. Editar um banco de 100 GB no meio custa alguns megabytes de backup, não 100 GB de novo. Cada execução vira um snapshot do repositório, um ponto de restauração que você navega com restic mount como se fosse filesystem, e o restic check audita a integridade do repositório inteiro quando você pedir.

A configuração importa mais que a ferramenta, então vai a nossa, com os erros inclusos. No desktop, o repositório mora no NAS e a retenção é keep-daily 7, keep-weekly 4, keep-monthly 6, keep-yearly 1. No servidor, o backup roda diário de madrugada pro repositório no QNAP, cobrindo /etc, /usr/local/bin, /home e os volumes dos containers, com a senha fora da máquina e pg_dump antes dos bancos, porque snapshot de filesystem não garante consistência de banco escrevendo. A primeira carga completa foi 729 GiB em menos de uma hora, e o restic atravessou ileso, na base do retry, a janela em que a montagem NFS ficou read-only por engano durante a migração.

A parte mais importante da configuração é o que não entra no backup. As nossas exclusões, todas com motivo:

• caches de modelo de IA (Immich, Hugging Face, EasyOCR): se perder, baixa de novo;
• métricas do Prometheus: histórico que se regenera sozinho;
• o banco do Fulcrum: reindexa a partir do bitcoind;
• os pesos dos classificadores de decisão: rebaixáveis por hash de revisão (e o glob dessa exclusão vai entre aspas dentro do array do bash, porque sem aspa ele vira fonte de backup em vez de exclusão);
• node_modules, target/, registry do cargo, toolchains do rustup: build artifact puro.

E um aprendizado de retenção pra fechar. Quando encurtamos a política do servidor pra “ontem, 2 diários, 2 semanais e 1 mensal”, a tradução correta pros flags é --keep-daily 3 --keep-weekly 3 --keep-monthly 2, não 2/2/1: os níveis do restic se sobrepõem, e o snapshot de ontem também é o mais novo desta semana e deste mês, então cada número precisa ser um a mais que os pontos antigos que você quer guardar. O detalhe pegou a gente no contrapé: o script estava com 2/2/1 literal, e com ele o nível mensal nunca seguraria nada mais velho que a noite passada. Na prática, a intenção era guardar 5 pontos de restauração, e o 2/2/1 entrega só 3: ontem, mais um diário, mais um semanal. Erramos, medimos, corrigimos.

Uma nota de humildade vinda do desastre: os repositórios antigos ficaram no Synology por decisão minha (quase 2 TB de histórico abandonado, porque o conteúdo já estava re-coberto no QNAP novo). Repositório de backup também envelhece, e revisitar o escopo dele faz parte da higiene.

Conclusão: na era da IA, disco não é detalhe

Agentes codificando o dia inteiro mudam a matemática do armazenamento nas duas pontas. Na ponta do volume: builds, caches, worktrees e modelos enchem o disco muito mais rápido do que qualquer hábito humano enchia, e sem rotina de limpeza você descobre quando estoura. Na ponta da segurança: quanto mais código gerado, mais você precisa de ponto de retorno barato, porque nem toda mudança de agente é boa.

O btrfs cobre as duas. A compressão transparente devolve 15% de disco de graça, e código-fonte é exatamente o tipo de dado que mais comprime. Snapshots e subvolumes te dão volta atrás instantânea no sistema e isolamento do que não precisa de proteção. Checksums e scrub vigiam a saúde dos blocos que o ext4 simplesmente ignora. O ext4 teve seus 15 anos de reinado merecido. Em 2026, escolher ele num Linux novo é abrir mão de proteção que você vai precisar, cedo ou tarde. Escolha btrfs e configure a limpeza hoje.

Naquele momento eu sabia que estava a um soluço de perder tudo. Este texto é o post-mortem do que aconteceu, e a primeira parte foi escrita no calor do desastre, com a cópia de salvamento ainda rodando.

Atualização de 11 de outubro: a cópia terminou e o final foi feliz. Nenhum arquivo se perdeu por acidente, os dois NAS estão saudáveis, cada um com seu RAID-6. A recuperação inteira está na segunda metade deste texto. A primeira parte fica como foi publicada, sem retoques.

Eu uso NAS faz muito tempo

Não sou marinheiro de primeira viagem. Fiz uma minissérie inteira de vídeos sobre armazenamento e sistemas de arquivos, e recomendo assistir antes de vir me perguntar “qual um bom NAS pra iniciante?”. Não existe isso.

Uso armazenamento externo desde a segunda metade dos anos 2000, quando era usuário de Mac e existia o Drobo. A empresa não existe mais, mas tive três DAS deles antes de migrar pra Synology, primeiro num modelo de entrada e depois no DS1821+, intermediário, que uso há mais de cinco anos. Já escrevi sobre ele aqui, configurando NFS no Linux e acessando por iSCSI.

Ele foi muito valioso pra mim, e você não tem que questionar por que eu preciso de tanto espaço. Não importa: cada um decide o que guarda no seu.

Quando eu produzia vídeo pro YouTube, editava material 4K direto do NAS, graças ao cache NVMe e à rede 10 GbE. Me acostumei com armazenamento grande a 10 gigabits e não consigo mais voltar atrás.

O array estava organizado em SHR, o RAID híbrido da Synology, que na prática se comporta como RAID-5 (mais sobre isso adiante): aguenta a perda de um disco sem perder dado nenhum. Sempre achei que isso bastava.

HD morre. Sempre

Não se engane: disco rígido estraga. Nunca, jamais confie num HD solitário esquecido num armário. Ele vai falhar, e você vai perder tudo o que está nele.

O melhor dado público sobre isso é o da Backblaze, que opera centenas de milhares de discos e publica a taxa de falha todo trimestre. No relatório do segundo trimestre de 2026, com 354.415 discos monitorados, a taxa anualizada foi de 1,73%, e a taxa acumulada da frota inteira está em 1,41% ao ano.

Parece pouco. Traduzindo pra escala de gente:

• Um disco sozinho, por 5 anos: a chance de ele morrer nesse período fica perto de 7%. É mais ou menos a chance de tirar um número específico num dado de 14 lados. Você apostaria todas as fotos da sua família nisso?
• Um disco sozinho, por 10 anos: uns 13%, um em cada oito.
• Oito discos, como no meu NAS, por um ano: a chance de pelo menos um falhar é de uns 11%. Em cinco anos, mais de 40%.

E esses números são de datacenter, com temperatura controlada, energia limpa e disco girando o tempo todo. HD de gaveta, que fica anos parado e leva tranco na mudança, não tem estatística tão bonita.

Cartão de memória é pior, e nem existe uma estatística equivalente pra consultar. O que existe é teste de tortura: o Great MicroSD Card Survey testou 216 cartões ao longo de um ano de escrita contínua, e 52 deles, um em cada quatro, já tinham morrido.

Cartão legítimo começou a dar erro, em média, depois de uns 2.500 ciclos de regravação; cartão falsificado, depois de 700. Cartão de memória é mídia de transporte. Guardar a única cópia de alguma coisa num microSD é pedir pra perder.

A conclusão prática é a mesma da minissérie: dado importante precisa de redundância. Um array com paridade existe justamente pra que a morte de um disco, que é questão de tempo, não leve nada junto.

O que aconteceu

Com tudo isso, eu deveria estar tranquilo com a minha configuração. Não estava.

Começou anteontem, domingo. Fazia tempo que eu via o volume chegando no teto.

No começo eram 8 discos de 10 TB. Com os anos fui trocando, um a um, por discos de 20 TB (o DSM mostra em base binária; na etiqueta são 12 e 22 TB). É um processo lento: cada troca leva dias, porque o array precisa reconstruir e redistribuir os dados.

Decidi trocar mais um, o sétimo. A Synology suporta hot-swap, então é simples: tira o disco velho, encaixa o novo, adiciona ao array e deixa o DSM cuidar da reconstrução.

No domingo à noite estava assim: reconstrução começando, os oito discos saudáveis, 108 TB alocados de 121,8 TB.

Na segunda, às 8 da manhã, o bipe. O disco 1, o novo, com 13 horas de uso, marcado como crítico:

E o disco 8, um dos antigos, com 22.095 horas ligado (dois anos e meio), também crítico, com erro de leitura às 08:05:

A mensagem do pool não deixava margem: “erros irrecuperáveis ocorreram porque erros de disco aconteceram depois da degradação do storage pool. Faça backup dos seus dados imediatamente.”

Por que dois discos é o fim

Em RAID-5, se dois discos caem, a redundância é zero, e em teoria o array inteiro vai junto. É uma situação irrecuperável.

Quem assistiu a minha playlist sabe o motivo. Um array desses não guarda “arquivos”, um por disco. Um arquivo é uma coleção de blocos, e os blocos ficam espalhados por todos os discos, junto com a paridade. Perder um disco é perder um pedaço de cada arquivo. Não adianta os outros sete estarem saudáveis, porque eles só têm partes.

A paridade serve pra recalcular o pedaço que falta quando um disco some. Com dois faltando, a conta não fecha.

E tem um detalhe cruel na reconstrução: pra recriar o disco novo, o array precisa ler todos os outros discos de ponta a ponta. São mais de 100 TB de leitura contínua. Se algum disco antigo tinha setor ruim escondido num canto que ninguém lia fazia tempo, é nessa hora que ele aparece. Foi o que aconteceu com o disco 8.

Pra onde copiar 90 TB?

A única saída, naquele ponto, era agradecer aos céus por os volumes ainda estarem acessíveis, com os arquivos aparecendo, e usar a janela pra copiar tudo pra fora imediatamente. Eu não podia encostar em mais nada.

O problema: copiar uns 90 TB pra onde? Ninguém tem um NAS de 100 TB vazio sobrando em casa.

Normalmente eu compraria esse tipo de peça nos Estados Unidos, numa viagem de turismo, e traria comigo. Sai muito mais barato. Não compensa comprar eletrônico caro no Brasil: o país cobra imposto de importação pior que as tarifas do Trump faz décadas, e o preço final costuma passar do dobro do preço de tabela americano.

Só que eu tinha que escolher. Quanto vale perder 90 TB de dados que levei anos juntando e que são quase impossíveis de recuperar de outro lugar? É uma daquelas situações em que a resposta é “não tem preço”, e então, qualquer que seja o preço, eu pago.

Achei um revendedor de storage perto de casa, a Controle Net. Gente boa, muito ágil na resposta, e me mandaram uma proposta de equipamento com entrega no mesmo dia.

A primeira sugestão deles foi um QNAP TS-832PX. Fui pesquisar antes de aceitar. Ele tem as mesmas 8 baias e já vem com 10 GbE, mas o processador é um ARM Cortex-A57 de 1,7 GHz (Annapurna Labs AL324) com 4 GB de RAM, metade do mínimo de 8 GB que o QuTS hero pede. Pra RAID-6 em ZFS, com checksum e paridade dupla em cada bloco, é hardware fraco, como eu explico mais abaixo. E seria um downgrade em relação ao DS1821+ que eu já tinha, que roda num Ryzen V1500B.

Pedi outra opção, e depois de algumas idas e vindas fechei num QNAP TS-873A, de 8 baias, com o mesmo Ryzen V1500B do meu Synology, 8 GB de RAM, e 10 discos Toshiba MG11 de 24 TB, classe enterprise.

É por isso que você tem que fazer a sua própria pesquisa e saber, objetivamente, o que quer fazer com o equipamento. O revendedor não agiu de má-fé: sugeriu um NAS de 8 baias pra quem pediu um NAS de 8 baias. Quem sabia que ia rodar ZFS em RAID-6 era eu. Se eu tivesse aceitado a primeira proposta no susto, teria pago caro por uma máquina pior do que a que estava substituindo.

R$ 185.320,00. De fazer o olho lacrimejar.

Quanto custaria nos Estados Unidos

Fui conferir o preço de tabela americano de hoje. Sobre o câmbio: o dólar está em R$ 4,97 agora, mas isso é efeito do resultado do primeiro turno da eleição de domingo, que derrubou a cotação mais de 4% na segunda. Até sexta ele fechava em R$ 5,22, e é essa a cotação justa pra comparar, porque foi nela que o estoque do revendedor foi formado:

A R$ 5,22, uns R$ 60 mil. Eu paguei R$ 185 mil, mais de três vezes isso.

A comparação não é perfeita: a proposta brasileira inclui instalação, treinamento e seis anos de suporte técnico, e o equipamento estava na minha mesa no fim do mesmo dia. Mas dá a medida do efeito Brasil.

Se a regra de bolso é “o dobro do preço americano”, o normal seria uns R$ 120 mil. Os R$ 65 mil a mais são, numa estimativa grosseira minha, a soma de serviço, estoque local de disco enterprise e a minha urgência. Quem compra numa segunda de manhã com o array morrendo não está em posição de pechinchar.

E o disco está caro no mundo inteiro

Pra piorar, o momento é o pior possível pra comprar HD. A bolha de IA está sugando a produção.

Eu achava que a Seagate tinha saído do mercado consumidor. Fui conferir, e não é bem isso: ela não saiu, mas em fevereiro 87% das vendas de HD dela já eram disco nearline, de datacenter, e a WD tira 89% da receita de clientes de nuvem e só 5% do varejo. O CEO da WD disse que a empresa está “praticamente esgotada para o ano de 2026”.

A Seagate declarou que não vai ampliar a capacidade de produção; o crescimento vem só de disco de maior densidade. Pra quem compra disco em casa, o efeito prático é parecido com terem saído: sobra o que os hyperscalers não quiseram, pelo preço que o vendedor pedir.

QNAP em vez de outra Synology

Depois de passar a manhã e a tarde entre negociação, burocracia e boleto, no fim do dia eu tinha o QNAP ligado ao lado do Synology.

A escolha pela QNAP foi além da disponibilidade. A Synology vem tomando decisão de negócio questionável.

Em 2025 ela lançou a linha Plus exigindo discos da própria marca ou certificados por ela.

Os da marca são discos de Seagate, Toshiba e WD rebatizados com firmware próprio, e quem usasse outro ficava sem criar pool, sem monitoramento de saúde, sem deduplicação e sem atualização de firmware. Depois da gritaria, voltou atrás no DSM 7.3 e liberou HD e SSD SATA de outras marcas.

Só que pool em M.2 continua exigindo a lista de compatibilidade. Ficou a incerteza no ar: o que impede de fazerem de novo?

Configurar o QNAP é muito fácil. O QuTS hero, o sistema deles baseado em ZFS, é tão simples de usar quanto o DSM da Synology.

Corrigindo o meu erro: RAID-6 e ZFS

Dessa vez eu sabia que tinha que configurar em RAID-6, que aguenta dois discos falhando ao mesmo tempo. A desvantagem é menos capacidade total, porque o equivalente a dois discos vira paridade em vez de um. A vantagem é que eu não deveria mais passar por uma emergência como esta.

Um dos pontos fortes da QNAP é suportar ZFS de fábrica, bem integrado e fácil de usar.

Pra quem não conhece: o ZFS nasceu na Sun Microsystems, pro Solaris, em meados dos anos 2000, e hoje vive como OpenZFS em Linux e FreeBSD. Ele junta num sistema só o que antes eram três camadas, o RAID, o gerenciador de volumes e o sistema de arquivos. Guarda um checksum de cada bloco, então percebe quando o disco devolve dado corrompido sem avisar, e conserta sozinho a partir da paridade. E nunca sobrescreve dado no lugar: toda escrita vai pra um bloco novo, o que torna snapshot praticamente gratuito.

A fama de devorador de RAM vem de duas coisas. A primeira é o ARC, o cache dele, que por desenho ocupa quase toda a memória livre da máquina. Isso assusta quem olha o gráfico, mas é cache: ele devolve a memória quando outro processo pede. A segunda é a desduplicação, que mantém uma tabela enorme com o hash de cada bloco e precisa dela na RAM pra não ficar inutilizável de tão lenta. A velha regra de “1 GB de RAM por TB de disco” vem daí, e só vale pra quem liga desduplicação.

Mesmo sem ela, ZFS pesa mais que um ext4 ou um Btrfs simples. Calcular checksum, compressão e paridade dupla de cada bloco gasta CPU, e com pouca memória o cache encolhe e tudo fica lento. Em hardware fraco, tipo um NAS de entrada com processador ARM e 2 GB de RAM, ele sofre.

A QNAP pede no mínimo 8 GB pro QuTS hero. O meu veio com 8 GB e um Ryzen de quatro núcleos, o que serve pro meu uso, que é guardar arquivo grande e servir pela rede. Desduplicação fica desligada.

Comprei 10 discos pra um NAS de 8 baias, então sobram dois na gaveta, de reserva, pro dia em que um falhar.

Pra minha configuração simples, três ajustes:

• Over-provisioning de 5%. É um pedaço do pool que o sistema reserva e nunca entrega pra dado. ZFS escreve sempre em espaço novo e fica lento quando o pool enche perto do limite; essa folga mantém o desempenho estável. Em pool de SSD ela também prolonga a vida útil, mas aqui são HDs, então o mínimo já serve.
• Espaço garantido de snapshot de 5%. É a reserva pra snapshot, as “fotos” do estado dos arquivos que permitem voltar atrás num apagão ou num ransomware. Garantir o espaço significa que os snapshots continuam existindo mesmo que eu encha o resto. Meus dados mudam pouco (é arquivo morto, na maior parte), então snapshot ocupa quase nada e 5% sobra.
• Alerta em 85%. O sistema me avisa quando o pool passar de 85% de uso, com folga pra eu agir antes de bater no teto. Foi exatamente a falta de folga que me fez sair trocando disco às pressas no Synology.

Somando as duas reservas, uns 13 TB ficam separados e sobram 112,9 TB pra uso.

Um detalhe do meu caso: estou copiando os 90 TB com os snapshots desligados, e só ligo o agendamento depois que a cópia terminar. Snapshot protege o estado anterior de um arquivo, e num NAS vazio que está recebendo a primeira carga não existe estado anterior que valha proteger. A fonte da verdade ainda é o Synology.

E tem um custo prático. Eu parei e recomecei o job várias vezes, apaguei pasta que tinha entrado por engano e copiei de novo. Com snapshot ligado, cada coisa apagada continuaria ocupando espaço dentro de algum snapshot, e eu estaria enchendo o pool com lixo da própria migração. Quando tudo estiver do lado de cá e conferido, aí sim: snapshot agendado, pra me proteger de apagar o que não devia e de ransomware.

Depois disso criei uma partição gigante “thick”. Em ZFS dá pra criar pasta “thin”, que só ocupa o que tem dentro e pode prometer mais espaço do que existe, ou “thick”, que reserva o tamanho inteiro na criação. Como é um pool com um dono só e um uso só, thick é mais previsível: o espaço é meu e ninguém compete por ele.

Por fim, criei os compartilhamentos e instalei o app HBS 3.

Copiando 90 TB

O HBS 3 (Hybrid Backup Sync) é o aplicativo da QNAP pra backup e sincronização. Ele conecta em outro NAS, em rsync, em FTP, em SMB ou em nuvem.

Conectei no compartilhamento SMB do Synology e mandei sincronizar tudo.

Tive que parar e recomeçar algumas vezes, mexendo nas configurações do job, porque estava absurdamente lento. E a contagem de arquivos não parava de crescer:

865 TB num NAS de 108 TB, e aí eu entendi o que estava acontecendo.

Excluí dois tipos de caminho do job:

• Os diretórios #snapshot. No Synology, quando você marca “tornar snapshot visível”, cada pasta compartilhada ganha uma subpasta #snapshot com uma visão completa da pasta em cada ponto no tempo. Dentro do Synology isso não ocupa espaço, porque snapshot só guarda a diferença. Visto de fora, por SMB, cada snapshot parece uma cópia inteira de tudo, e o HBS estava tentando copiar todas.
• Os diretórios de backup do restic. O restic guarda tudo em centenas de milhares de arquivos de pack de poucos megabytes cada. Cópia por rede é rápida com arquivo grande e sofre com arquivo pequeno, porque cada um custa abertura, metadado e fechamento. E esses backups eu refaço do zero no NAS novo.

Com isso a vazão subiu pra uma média de 400 MB/s.

Isso é menos da metade do que uma rede 10 GbE entrega, mas é mais de três vezes o gigabit que a maioria das pessoas tem em casa. Os dois lados estão de fato a 10 gigabits:

Por que não chega nos 1.000 MB/s? Minha hipótese principal é o disco 8. O array de origem está degradado, e cada leitura que passa pelos pedaços afetados precisa ser recalculada a partir da paridade, com um disco que ainda por cima devolve erro e repete tentativa. Faz sentido o Synology não conseguir ir mais rápido que isso.

Tem um segundo fator, que os meus próprios prints entregam: o Synology está com jumbo frame (MTU 9000), e a imagem do QNAP mostra o MTU padrão de 1500. Esse print é de antes; eu já mudei o QNAP pra 9000 também.

Por que isso importa: MTU é o tamanho máximo de cada pacote que trafega na rede. No padrão de 1500 bytes, encher um link de 10 gigabits significa processar mais de 800 mil pacotes por segundo, e cada pacote custa CPU dos dois lados, com cabeçalho, checksum e interrupção. Com jumbo frame cada pacote carrega seis vezes mais dado, então é um sexto dos pacotes pro mesmo volume, e sobra processador pra mover arquivo. Só funciona se todo mundo no caminho estiver igual: as duas placas e o switch. Se um lado fica em 1500, a conexão negocia pelo menor e o jumbo frame do outro lado não serve de nada.

A 400 MB/s, 90 TB levam uns dois dias e meio, e eu prefiro dois dias e meio garantidos.

O que a Synology explicou

Em paralelo, abri um chamado no suporte da Synology. Depois de algumas trocas, mandei os logs. Responderam rápido, no mesmo dia, e isso eu reconheço. A explicação do engenheiro, resumida:

• O disco 8 vinha registrando erro de mídia há mais de um mês. Erro de mídia é quando o NAS manda ler um setor e o disco responde que não conseguiu, mesmo tentando várias vezes. É sempre falha interna do disco, e ele deveria ter sido trocado.
• Foi a saúde ruim do disco 8 que o derrubou durante a reconstrução do disco 1.
• Na prática eu perdi dois discos, e o pool deveria ter caído por completo. Não caiu por causa do jeito como o SHR funciona.

O SHR não é um RAID-5 só. Pra aproveitar discos de tamanhos diferentes sem desperdiçar espaço, ele fatia os discos e monta vários RAIDs menores, um por faixa de tamanho, e junta tudo num volume. O engenheiro mandou este diagrama de exemplo:

No meu caso, o pool é feito de duas partições. Na primeira, a reconstrução do disco 1 já tinha avançado o bastante e a falha do disco 8 foi leve o bastante pra que os dois continuassem funcionando. Na segunda, os dois estão ausentes. É por isso que o pool não caiu inteiro e eu ainda enxergo os arquivos.

A recomendação dele foi a que eu já estava seguindo: copiar tudo pra fora antes de qualquer outra coisa, porque não dá pra saber se a situação piora nem se tem conserto. Depois do backup ele até pode tentar forçar o disco 8 de volta pro pool pra reconstrução continuar, mas não há garantia de que o disco aceite, nem de que aguente o processo. Nas palavras dele, copiar e recriar o pool do zero é provavelmente o caminho mais rápido.

RAID-5 clássico, aliás, exige todos os discos do mesmo tamanho, e pra aumentar a capacidade eu teria que trocar todos de uma vez. O SHR foi o que me permitiu ir trocando um por vez ao longo dos anos. Por ironia, foi também o que me salvou de perder tudo de uma vez.

Os dois erros

Do jeito que eu entendi, são dois erros, um meu e um deles, e é aí que mora o desastre inteiro.

O meu: subestimei o RAID-6, que na Synology se chama SHR-2. Com dois discos de paridade, a falha do disco 8 no meio da reconstrução seria só um susto. Eu troquei segurança por 20 TB de espaço e passei cinco anos achando que tinha feito bom negócio.

O deles: pelos logs, o software sabia que o disco 8 estava falhando havia pelo menos um mês, e eu nunca recebi notificação nenhuma. Eu tenho notificação por e-mail configurada. E ela funciona: quando a situação crítica estourou, recebi uma enxurrada de e-mails. Este aqui, sobre os setores ruins do disco 8, chegou à uma da tarde de segunda, cinco horas depois do desastre:

Antes disso, nada. Nenhum aviso sobre o disco 8 até ele falhar de forma catastrófica.

Se eu tivesse recebido, jamais teria tentado trocar o disco 1 antes de substituir o 8. A situação toda era evitável, e foi resultado de um erro humano somado a algum bug de software.

Esse é o outro motivo de eu não ter comprado outra Synology. Tenho um princípio: se o cavalo me derruba, eu sacrifico o cavalo. Não dá pra confiar de novo.

Onde estou agora

Até aqui copiei uns 20 TB dos 90 TB originais, e o HBS 3 segue trabalhando. Ainda não sei se perdi algum dado de forma permanente. Espero que não, mas o mais provável é que eu tenha perdido o que estava na fatia de RAID que o engenheiro descreveu como caída.

Tenho backup offsite no AWS Glacier do que é mais importante, mas não de tudo.

Muita gente pergunta por que eu não uso S3 ou outro armazenamento em nuvem pra tudo. Devolvo a pergunta: pensa por dez segundos. Quanto tempo leva pra transferir 90 TB pela sua internet? Faz a conta:

• Com 1 gigabit de upload cravado, sem cair um segundo: mais de 8 dias.
• Com 500 megabits: quase 17 dias.
• Com 100 megabits, que é upload bom pra muita casa: 83 dias.

E isso é pra subir. Na hora do desastre você precisa baixar tudo de volta, com o relógio correndo. Sem contar o aluguel: 90 TB em S3 padrão custam uns US$ 2 mil por mês no preço de tabela. Nuvem é ótima pro subconjunto crítico, que é como eu uso. Pro acervo inteiro, a física e a fatura não deixam.

Lições

Fui colocado numa situação impossível numa segunda de manhã, agi na hora do melhor jeito que consegui, e provavelmente vou sair dessa quase ileso. Vamos ver, o HBS 3 ainda está sincronizando. O que eu levo disso:

1. Paridade simples não basta pra disco grande. Com discos de 20 TB, a reconstrução leva dias e lê tudo. É nesse intervalo que o segundo disco costuma aparecer. RAID-6, SHR-2 ou RAIDZ2.
2. Não confie só na notificação do fabricante. Olhe o SMART e o log dos discos antes de começar qualquer troca. Eu não olhei, porque confiava que seria avisado.
3. Troque primeiro o disco doente, depois o disco pequeno. Upgrade de capacidade em array com disco suspeito é roleta.
4. Deixe folga. Eu estava trocando disco porque o volume estava no teto. Alerta em 85% existe pra isso.
5. Tenha pra onde copiar. A minha saída custou R$ 185 mil porque eu não tinha plano B. Um segundo NAS, mesmo modesto, com o que importa, teria me dado tempo pra comprar com calma.
6. RAID não é backup. Eu sei disso, ensino isso, e mesmo assim só tinha offsite de uma parte.

A cópia terminou e eu já sei o tamanho do estrago: zero. A recuperação completa vem a seguir.

Seis dias depois: o final da história

Quando publiquei a primeira parte, eu tinha uns 20 TB copiados e nenhuma certeza. O desfecho: terminei de evacuar os ~91 TB, verifiquei arquivo por arquivo, e não perdi nada por acidente. Nem o que estava na fatia de RAID caída, porque ela continuou legível até o fim.

Quem operou a recuperação foram os meus dois agentes. O agente do desktop controla meu PC e os dois NAS por SSH, e o agente do homelab cuida do servidor onde rodam meus 57 containers. Os dois se coordenam por mensagem: um deixa relatório na caixa do outro, e eu acompanho a conversa.

Essa parte importa porque nada do que vem a seguir foi eu digitando comando. Eu tomei as decisões; eles executaram, mediram e erraram feio algumas vezes, como você vai ver.

O HBS 3 estava me traindo quieto

Na primeira parte eu contei que o HBS 3, puxando os compartilhamentos do Synology por CIFS, chegou a 400 MB/s depois dos ajustes. O que eu não sabia: velocidade era o menor dos problemas dele.

Dois defeitos apareceram quando o agente conferiu o inventário da origem contra o que o HBS reportava:

• Ele não entrava onde não tinha permissão e não contava pra ninguém. O HBS monta o Synology como o meu usuário. O diretório Bitcoin/data, 901 GB com a wallet e o chainstate do meu nó, pertence ao uid 101 e é fechado pra qualquer outro. O CIFS não conseguia entrar ali, e o HBS reportava sucesso sem registrar a omissão. Um backup “verde” que deixa o nó de Bitcoin inteiro pra trás.
• Ele pulava arquivos com nome “não suportado”. 113 arquivos, registrados só numa tela de detalhe que ninguém abre durante uma cópia de dias.

Ferramenta de backup que reporta sucesso omitindo o que não conseguiu ler é pior que uma que falha gritando. Verifique o backup contra um inventário independente da origem, nunca contra o log da própria ferramenta.

Abandonamos o HBS. O agente abriu SSH nos dois NAS, habilitou o servidor rsync no QNAP e o Synology passou a empurrar direto pro rsyncd dele, sem nada passar pelo PC. O wrapper de cada job: rsync -a --numeric-ids -W --partial --timeout=600, tentativas com retry, e nunca --delete. O --numeric-ids preservou os uids originais sem precisar de chown depois, o --partial fez qualquer interrupção virar continuação, e a ausência de --delete fez do destino sempre um superconjunto: re-shardar ou matar um job nunca custava dados.

O gargalo não era o disco quebrado

Um contexto que faltou na primeira parte. Esse Synology nasceu com oito Seagate IronWolf de linha consumidora, e eu vinha trocando um por um por IronWolf Pro de 20 TB ao longo dos anos. A desgraça aconteceu exatamente num desses upgrades: eu troquei o disco 1 pelo Pro novo e, durante a reconstrução, o disco 8 falhou. Sobrou um único disco antigo no array: o disco 2.

E foi ele, não o disco 8, o gargalo da evacuação. Medido sob carga:

• Disco 2 (o consumidor antigo, com 37 mil horas de uso): 91% de utilização, entregando 27 MB/s, cada I/O demorando 4 a 15 vezes mais que os irmãos.
• Os seis Pro: entre 34% e 45% de utilização, parados esperando ele.

Em RAID-5 (e no SHR), uma leitura sequencial atravessa o stripe inteiro, e o stripe só completa quando o membro mais lento responde. Um disco lento limita o array inteiro: por causa dele, o array não passava de uns 200 MB/s enquanto seis discos bons sobravam. E o SMART dele estava limpo, zero setores realocados. Disco consumidor costuma vir sem limitação de tempo de recuperação de erro (ERC/TLER) ativa, então ele tenta reler setor marginal por segundos, internamente, sem contabilizar nada. O cache NVMe do Synology desviava parte da leitura dos pratos e ajudava a maquiar o sintoma.

O disco que falha e o disco que te atrasa não precisam ser o mesmo, e SMART “PASSED” não diz nada sobre latência. Array lento se diagnostica com utilização e tempo de resposta por disco, não com SMART.

Paralelizar rsync é ciência, não chute

Primeiro instinto: mais streams. Errado, e por duas vezes.

Na primeira, um bug nosso: um relançamento “limpo” de jobs não matou nada, porque o ps do busybox do Synology trunca a linha de comando e o grep de verificação não achou os processos velhos. Resultado: 32 rsyncs rodando pra 7 destinos, quatro a cinco escritores por árvore, o QNAP com os buffers de recepção entalados, e o cabo transmitindo 516 MB/s enquanto o array lia 140. Depois da limpeza (enumerando /proc/*/cmdline, nunca mais confiando no ps), a vazão útil subiu de 140 pra 181 MB/s com a carga total desabando.

Na segunda, a medida inverteu o senso comum: com árvores de arquivo grande, menos streams eram mais rápidos, porque o tamanho médio de cada requisição de leitura triplicava e o array fazia corridas sequenciais longas em vez de ficar pulando de posição.

Só que árvore de arquivo pequeno é outro esporte. O TERACHAD/Emulators tem 21 TB em 3,4 milhões de arquivos com média de 6 MB: trabalho limitado por latência (stat, criação, metadados), não por banda. E ali a paralelização agressiva funcionou, com um detalhe: o shard certo se escolhe por contagem de arquivos, não por tamanho. Um único diretório, ROMS_FINAL/xbox-hdd-ready, segurava 995 mil dos 1,59 milhão de arquivos do ROMS_FINAL, com média de 1,7 MB por arquivo. Isolando ele dos ISOs multi-gigabyte:

De 2,8 a 3,2 vezes a vazão média do stream único, na mesma máquina, na mesma rede. E tem um motivo bonito: com o array faltando um membro, leituras de dados que não moram no disco 2 não precisam dele, então a concorrência extra deixava os outros discos trabalharem enquanto ele engasgava.

“Mais paralelismo” e “menos paralelismo” são as duas respostas erradas como regra geral. Trabalho limitado por banda se divide pouco; trabalho limitado por latência se divide muito, e por contagem de arquivos. Meça antes de escolher.

Copiar é metade do trabalho; provar é a outra metade

Cada job que terminava passava por um dry-run do mesmo rsync, com os mesmos excludes: zero arquivos precisando transferência significa destino idêntico por tamanho e data. E mesmo assim quase deu errado, porque a verificação herdava os excludes da cópia: uma árvore excluída da transferência ficava excluída da própria prova. Refazendo a checagem sem excludes, apareceram 952 arquivos e 191 GB faltando no Downloads (exatamente os lotes que eu tinha separado como “única cópia existente”) e os repositórios restic antigos, que um nome de diretório parecido no QNAP fingia cobrir: o ID interno dos repositórios provou que eram outros, não cópias.

Teve também deriva de origem: uma árvore verificada como completa recebeu 16 GB de checkpoints novos no Synology depois da checagem, e só a re-verificação final pegou. Verificação tem prazo de validade.

E uma decisão consciente, registrada pra ninguém me acusar de esconder: os históricos antigos de backup (uns 2 TB de snapshots restic e um set de duplicity de 2025) ficaram pra trás por escolha minha, porque os repositórios novos no QNAP já cobrem o mesmo conteúdo a partir de agora. Perda deliberada de histórico, não de dado.

Fecho da conta: 17 jobs de rsync, todos exit 0, todos verificados, uns 5,9 milhões de arquivos byte-idênticos, e o desligamento do Synology só aconteceu depois de cada árvore provada.

Enquanto isso, no homelab

Do outro lado da casa, o servidor marvin, que monta o NAS por NFS e roda os 57 containers, quase morreu de pé. NAS morto mais montagem NFS “hard” mais 57 containers reiniciando sozinhos deu uma fila infinita de I/O ininterruptível: a máquina respondia ping, mas o sshd não conseguia completar um handshake. E cada tentativa insistente de SSH só piorava, porque o OpenSSH pune fonte repetitiva aumentando o banimento. A gente batia na porta e a porta aumentava a tranca.

A saída foi parar de bater: pausei os torrents pela API do qBittorrent (que continuava respondendo), fui no console físico, desabilitei o Docker, reinicie, e o servidor voltou. Um watchdog que eu nem lembrava que existia tinha, sozinho, derrubado os 14 containers dependentes do NAS antes de qualquer banco corromper: o LevelDB do bitcoind abriu limpo na primeira tentativa.

A migração em si foi elegante: o fstab apontou pro QNAP e os pontos de montagem antigos viraram symlinks pra dentro do novo. Nenhum docker-compose mudou. Aí veio a pegadinha do NFS da QNAP: permissão é por cliente. O desktop estava liberado sem squash, mas as escritas do marvin caíam como uid 1001, bloqueando tudo que escreve no NAS. A primeira tentativa de correção ainda virou a montagem pra read-only no meio do primeiro backup restic, que sobreviveu na base do retry. Configuração final: leitura e escrita, sem squash pra ninguém, testada com touch e ls -ln de cada cliente, porque “funcionou no desktop” não prova nada sobre o servidor.

Depois disso foi ressurreição árvore por árvore: cada serviço só subia quando a árvore dele estava verificada no QNAP. Em dois dias, 57 de 57 containers de volta, e um backup restic novinho rodando diariamente pro QNAP.

O kernel novo derrubou o NVMe

No meio da recuperação, um susto de graça do servidor. Sete minutos depois do backup noturno começar, o controlador NVMe sumiu em silêncio: todo binário tomou SIGBUS, Docker e sshd morreram, e nada restou gravado em lugar nenhum, porque o log mora no dispositivo que morreu. Nem kernel panic: só silêncio.

O mesmo workload tinha rodado bem horas antes no kernel 7.2.6 e morreu no 7.2.9. Desligar o APST (o gerenciamento de energia do NVMe) não resolveu: segunda queda idêntica, regressão do 7.2.9 confirmada por eliminação. O MicroOS é transacional e baseado em snapshot, então o rollback foi um reboot pra linhagem 7.2.6, não uma reinstalação. As atualizações automáticas ficaram propositalmente quebradas naquela linhagem pra ninguém voltar pro 7.2.9 sem supervisão, e o teste do 7.2.8 fica pra quando eu puder sentar do lado.

Sistema operacional transacional transforma regressão de kernel em reboot. Sem snapshot de sistema, essa noite teria custado muito mais caro.

O susto do thick provisioning

No QNAP, a cópia inteira rodou sem snapshot nenhum: numa migração em massa, snapshot é peso morto. Terminada a cópia, fui ligar a agenda de snapshots do ZFS e tomei um erro seco: “pool free space is not enough”. Com 20 TB livres.

As duas afirmações eram verdade sobre coisas diferentes. A pasta CHAD tinha sido criada como thick: dos 100 TB de quota, o ZFS reserva os 100 TB, e pra tirar snapshot de um dataset com reserva, o pool precisa garantir espaço pra sobrescrever todos os blocos referenciados enquanto o snapshot prende as cópias velhas. Na conta: 80 TB escritos mais 100 TB reservados, contra 126 TB utilizáveis do pool. Não fecha. E o df mente dos dois lados, porque mede a pasta contra a quota, não contra o pool.

A correção foi converter a pasta pra thin, que o QuTS hero faz in-place, escondido na tela de Management da pasta, não no diálogo de edição onde “Thick” parece texto estático. Em thin, o número vira teto em vez de reserva: a reserva de 10 TB evaporou, o pool passou a ter 39 TB livres, e o primeiro snapshot saiu consumindo 334 KB sobre 79,9 TB referenciados. O ZFS não precisava de quase nada; a reserva é que exigia garantia de 100 TB pra autorizar.

Agora o QNAP tem agenda de snapshots com política de retenção, como devia ser desde o primeiro dia:

Duas notas de rodapé pra quem montar um desses. Se a sua pasta thin tiver alerta de 80%, suba a quota pra folga estética, porque o alerta mede contra a quota e não contra o pool. E o gargalo real desse QNAP é RAM: 7 GB pra um pool de 174 TB. O mínimo oficial do QuTS hero é 8 GB, e a prática recomendada pra esse porte é 16 pra cima. O tamanho do cache ARC governa a velocidade de metadados, e foi por isso que as varreduras de árvore inteira durante a migração eram lentas. Upgrade de RAM vale mais que qualquer ajuste fino.

O Synology nasce de novo

Com tudo verificado no QNAP, o Synology finalmente pôde ser operado. Troquei os discos 2 e 8 por IronWolf Pro novos, apaguei o pool ferido e recriei do zero, desta vez em SHR-2, o modo com dois discos de paridade, o RAID-6 deles. O pool novo saiu com 100 TB, todos os discos saudáveis:

Ele volta a trabalhar como alvo de réplica, e não mais como ponto único de falha. O QNAP segue como principal, em RAIDZ2, com 87 TB dos 126 TB usados e os snapshots agendados:

O que eu levo da segunda metade

1. Desconfie do sucesso silencioso. O HBS reportava verde enquanto deixava 901 GB pra trás. Backup se verifica contra inventário da origem.
2. SMART não mede lentidão. O disco que quase matou a evacuação estava “saudável”. Utilização e latência por disco contam a verdade.
3. Paralelismo se calibra medindo. Bandwidth-bound divide pouco, latency-bound divide muito, e o shard se escolhe por contagem de arquivos.
4. Verificação não herda exclude. Se a prova usa os mesmos filtros da cópia, ela só reafirma as suposições da cópia. E verifique de novo imediatamente antes de destruir a origem.
5. Permissão de NFS é por cliente. Teste escrita de cada máquina que vai usar.
6. Não bata repetidamente num sshd morrendo. Cada tentativa alonga o banimento. Uma tentativa paciente, ou console físico.
7. O reparo perigoso vem por último. O array ficou degradado e lento até o último byte estar provado em outro lugar; só então reconstruir deixou de custar qualquer coisa.

Saí dessa melhor protegido do que entrei: dois NAS, cada um com seu RAID-6, snapshots agendados no QNAP, restic diário, e o Glacier pro que é crítico. O desastre me custou um QNAP, dois discos e uma semana. Podia ter custado 90 TB.

Você paga pelo livro, mas só consegue ler onde a Amazon deixa. Não existe um aplicativo nativo decente pra Linux. Mudar pra outro leitor vira um exercício de arqueologia. Comprei um Xteink X4 novo e, claro, minha biblioteca não podia simplesmente ir junto. O arquivo estava “na minha conta”, mas não estava sob meu controle.

Durante anos, eu contornei isso pelo caminho oficial. Entrava no site da Amazon, usava Download & Transfer via USB, baixava o .azw dos livros que comprei e importava tudo no calibre. Com o plugin DeDRM configurado pro serial do meu Kindle, convertia pra EPUB e pronto.

Em 26 de fevereiro de 2025, a Amazon desativou essa opção. Sem anúncio decente, sem substituto que entregasse o arquivo e sem qualquer preocupação com quem queria manter um backup local. Desde então, meus livros mais novos ficaram presos no ecossistema deles. Voltei a tentar no ano passado, atualizei plugin, copiei arquivos do meu Kindle Paperwhite, coloquei o serial correto e nada.

Pra ser justo, em 20 de janeiro de 2026 a Amazon passou a permitir que compradores verificados baixem EPUB ou PDF quando o publisher confirma o livro como DRM-free. Ótimo. Só não resolve os livros protegidos, e a decisão continua nas mãos da editora. Títulos antigos sem DRM também precisam ser confirmados individualmente pelo publisher. Minha biblioteca não ganhou botão de download por causa disso.

Resolvi tentar de novo agora. A versão nova do DeDRM conseguiu lidar com o DRM atual, mas o processo mudou bastante. Dá trabalho, precisa de Windows numa das etapas e envolve uma ferramenta comunitária em pre-release. Funcionou. Recuperei 106 livros comprados, testei a conversão pra EPUB e agora posso ler no aparelho que eu quiser.

Este é o estado do jogo em 30 de julho de 2026 (atualizado em 19 de agosto). A Amazon pode mudar a criptografia ou o aplicativo amanhã. Não conte com tutorial antigo dizendo pra instalar Kindle for PC 1.17, desabilitar update e colocar o serial do aparelho no Calibre. Esse mundo já acabou.

E o óbvio precisa ser dito: estou falando dos livros que eu comprei. Não estou falando de baixar Kindle Unlimited, empréstimo de biblioteca ou livro dos outros. Leis sobre circumvention de DRM variam por país. Pesquise a legislação de onde mora e assuma responsabilidade pelo que faz.

Antes de tudo: não jogue Kindle velho fora

Amazon também não facilita reaproveitar Kindle antigo. O hardware continua bom, a bateria costuma ser substituível, a tela de e-ink dura uma eternidade, mas o software vai ficando cada vez mais fechado e limitado.

Pra quem quer ressuscitar esses aparelhos, recomendo o canal Dammit Jeff. Ele acompanha jailbreaks, KOReader, lojas alternativas e formas de manter Kindles úteis depois que a Amazon perde o interesse. Este vídeo sobre o AdBreak e os jailbreaks recentes é um bom começo. Leia também o guia atualizado do Kindle Modding antes de fazer qualquer coisa, porque firmware e método compatível mudam o tempo todo.

Jailbreak do aparelho e remoção de DRM do ebook são problemas diferentes. Você não precisa desbloquear o Kindle pra seguir o resto deste artigo. Estou mencionando porque ambos partem da mesma ideia: hardware e mídia que já pagamos deveriam continuar úteis sem pedir bênção eterna ao fabricante.

Crash course: AZW, EPUB e KFX

DRM e formato de arquivo não são a mesma coisa. O formato diz como texto, imagens, fontes, índice e metadados são empacotados. DRM adiciona uma trava criptográfica por cima e decide qual conta, aplicativo ou aparelho consegue abrir aquilo.

Os três nomes que importam aqui são:

A extensão sozinha pode enganar. Parte de um livro KFX pode aparecer como .azw, .azw.res, .voucher e outras variações. O plugin KFX Input existe justamente pra entender esse conjunto.

O EPUB é bem menos misterioso. A especificação EPUB 3.3 o define como um container de arquivo único pra conteúdo Web estruturado. É basicamente um pequeno site empacotado. Qualquer leitor minimamente decente consegue implementar suporte sem depender de uma chave secreta da Amazon.

Calibre e os dois plugins

calibre é o canivete suíço de ebooks. É software livre, roda em Linux, macOS e Windows, organiza biblioteca, baixa metadados, edita capas, transfere livros e converte dezenas de formatos. Existe desde 2006 e nasceu justamente porque o primeiro Sony Reader não funcionava direito no Linux.

No Omarchy ou qualquer Arch, basta instalar o pacote:

sudo pacman -S calibre

Em outras distribuições, veja o download oficial. Não invente de instalar um pacote aleatório de site de downloads.

Uma pegadinha específica de ambientes com mise: se o Calibre morrer com ModuleNotFoundError: msgpack ou BrokenPipeError, provavelmente um shim de Python entrou antes de /usr/bin. O pacote do Arch precisa do Python do sistema. Inicie assim:

env PATH="/usr/bin:$PATH" /usr/bin/python3 /usr/bin/calibre

Isso não tem relação com DRM nem com os plugins. É só o helper do Calibre chamando o Python errado. No meu desktop deixei um launcher permanente com esse PATH.

O Calibre sozinho não remove DRM. Precisamos de dois plugins:

1. DeDRM reconhece e remove as travas de vários ecossistemas durante a importação. Ele só roda quando o livro entra na biblioteca. Clicar em Convert depois não remove nada.
2. KFX Input entende os containers modernos da Amazon, reúne as partes de um livro e permite converter o resultado pra EPUB.

No momento deste artigo, estou usando DeDRM 10.0.28, publicado em 14 de julho no fork mantido por Satsuoni. É um pre-release. Baixe o asset chamado DeDRM_tools.zip, nunca um executável solto de algum mirror obscuro.

Atualização (agosto de 2026): o aplicativo do Kindle na Microsoft Store não para quieto, e cada versão nova dele exige uma versão nova da ferramenta. Desde a publicação deste artigo, o app saiu da 1.0.18632: a 10.0.29 adicionou suporte ao app 1.22326 e a 10.0.30 suporta o app 1.0.22920. A regra prática é uma só: o nome do executável carrega a versão do app que ele entende (MSIXKFXArchiverMobi1_22920.exe pra Store app 1.0.22920, e assim por diante). Antes de começar, confira sempre a página de releases do fork do Satsuoni e baixe o pre-release mais novo. Todo o resto do processo descrito aqui continua igual.

Eu descompactei tudo numa pasta que depois fica compartilhada com a VM Windows:

mkdir -p ~/Windows/Kindle-DeDRM/v10.0.28
unzip ~/Downloads/DeDRM_tools.zip -d ~/Windows/Kindle-DeDRM/v10.0.28

O SHA-256 do DeDRM_tools.zip que usei foi:

520cce704edf9ae26e43196efe2871daf9b25d6cb489aa56051626801c362947

Confira com sha256sum. Isso não transforma um binário comunitário em software magicamente seguro, mas pelo menos garante que está usando o mesmo arquivo que eu testei.

Dentro da pasta existe DeDRM_plugin.zip. Não descompacte esse segundo ZIP. No Calibre, abra Preferences → Plugins → Load plugin from file, escolha DeDRM_plugin.zip, aceite o aviso e reinicie o programa.

Depois volte em Preferences → Plugins → Get new plugins, procure por KFX Input e instale. Meu teste usou a versão 2.33.0. Reinicie de novo.

Por que copiar do Kindle pelo USB não resolveu

O caminho mais simples ainda seria ligar meu Kindle Paperwhite novo no cabo, copiar o livro e configurar o serial do aparelho no DeDRM. Foi o primeiro teste que fiz.

O arquivo entrou como KFX-ZIP, o plugin rodou, mas continuou criptografado. Abri o Calibre em debug e o log mostrou que esse livro usava a estratégia ACCOUNT_SECRET. O serial estava certo. O problema é que a chave necessária não vinha mais apenas do aparelho.

É por isso que muita gente segue tutorial antigo, tenta cinco serial numbers diferentes e conclui que o DeDRM está quebrado. Pra livros novos com esse DRM, precisamos do segredo que o aplicativo Kindle atual guarda no Windows. E esse segredo é protegido pelas APIs do TPM.

Um Windows descartável dentro do Omarchy

Eu não vou manter dual boot só pra baixar ebook. Também não vou fingir que Wine roda tudo. Felizmente, o Omarchy já vem preparado pra instalar e abrir uma VM Windows: ela aparece no próprio menu do sistema, abre por RDP e compartilha ~/Windows automaticamente com o guest. Não precisei montar essa integração do zero.

Por baixo, ele usa o dockur/windows. O dockur empacota QEMU/KVM num container e automatiza a instalação do Windows. Continua sendo uma máquina virtual de verdade, com disco e kernel próprios. O container só organiza a distribuição, configuração e ciclo de vida.

Pra instalar pelo terminal, rode:

omarchy-windows-vm install

Escolha RAM, CPUs e tamanho do disco. O instalador cria ~/.config/windows/docker-compose.yml, guarda o disco virtual em ~/.windows e compartilha ~/Windows com o guest. Dentro do Windows, essa pasta aparece como Shared, normalmente em Z:, e também fica acessível por \\host.lan\Data.

O detalhe que fez diferença no meu caso foi habilitar TPM 2.0. Edite o Compose gerado e acrescente TPM: "Y" no bloco environment:

services:
  windows:
    image: dockurr/windows
    environment:
      VERSION: "11"
      TPM: "Y"

Depois recrie o container. O disco do Windows continua no volume persistente:

omarchy-windows-vm stop
omarchy-windows-vm launch -k

O -k deixa a VM ligada quando você fechar o RDP. Também dá pra acompanhar pelo navegador em http://127.0.0.1:8006.

Baixando os livros pelo aplicativo certo

Dentro do Windows, abra a Microsoft Store e instale Amazon Kindle: Reading App, produto 9P8JQ0JJSTLL.

Preste atenção aqui. O instalador antigo de Kindle for PC encontrado em blogs não é o mesmo aplicativo. A ferramenta que usei procura o pacote AMZNKindle.AmazonKindleReadingApp da Microsoft Store. Com o programa legado, ela simplesmente responde No AmazonKindleReadingApp installation found.

Entre na sua conta e mande baixar localmente cada livro que quer preservar. Abrir a capa ou ver o título na biblioteca não basta. O conteúdo precisa estar disponível offline dentro do app.

Infelizmente, a parte mais chata continua manual. A Amazon sabe colocar botão de compra com um clique, mas não achou espaço pra um “baixe tudo que eu já paguei”.

Eu fiz isso em 106 livros. Sim, foi um saco.

Gerando os KFX-ZIP e a chave K4I

O DeDRM_tools.zip que descompactamos no Linux já está visível no Windows por causa da pasta compartilhada. Abra PowerShell e entre nela:

cd \\host.lan\Data\Kindle-DeDRM\v10.0.28
.\MSIXKFXArchiverMobi1_18632.exe

O banner ainda pode mencionar uma build antiga 1.0.15230. O executável versionado acima procura a Store app 1.0.18632 e foi o que funcionou comigo. O número no nome do arquivo precisa bater com a versão do seu app: se a Store já te entregou uma versão mais nova, baixe a release correspondente na página do projeto (veja a atualização na seção dos plugins).

Esse executável localiza o cache da versão atual da Microsoft Store, reúne os componentes de cada livro e gera duas coisas:

• archived_kfx/, com um .kfx-zip pra cada ebook baixado;
• oldbooks.k4i, o keyfile que o DeDRM precisa pra abrir aqueles arquivos.

Na minha máquina, o processo encontrou e arquivou 106 livros. O SHA-256 do executável que rodei foi:

0c78b45ccea2c36a5fbb01b9f66bdd9e5d5960a68a340ba2ee96e138f5cddf4a

Ele é um binário de 32 bits. Se reclamar que falta MSVCP140.dll, instale o Microsoft Visual C++ Redistributable x86 oficial. Não procure DLL avulsa no Google. Esse é um ótimo jeito de transformar backup de livro em backup de malware.

O oldbooks.k4i é sensível. Ele deriva do segredo da sua conta naquela instalação do Kindle. Não publique, não mande em issue do GitHub, não tire screenshot do conteúdo e não coloque em repositório aberto.

Configurando a chave no DeDRM

De volta ao Linux, abra o Calibre e siga:

Preferences → Plugins → DeDRM → Customize plugin → Kindle for Mac/PC ebooks → Import Existing Keyfiles

Selecione:

~/Windows/Kindle-DeDRM/v10.0.28/oldbooks.k4i

Use Import Existing Keyfiles. Não use o botão genérico Set Keyfile da tela principal. Ele grava outro tipo de candidato e não cadastra a chave K4I no lugar certo.

Feche a lista de chaves, clique em OK na configuração principal e reinicie o Calibre. Se fechar com Cancel, ele joga a alteração fora sem cerimônia.

Importando e convertendo pra EPUB

Antes de despejar cem arquivos na biblioteca, teste um.

Escolha um .kfx-zip dentro de:

~/Windows/Kindle-DeDRM/v10.0.28/archived_kfx/

Use Add books no Calibre. A ordem interna é esta:

1. KFX Input reconhece o pacote;
2. DeDRM tenta as chaves K4I durante a importação;
3. KFX Input monta o livro descriptografado como KFX;
4. Calibre passa a conseguir abrir e converter o resultado.

Se o formato continuar aparecendo como KFX-ZIP, deu errado. Não adianta apertar Convert dez vezes. Remova aquela entrada da biblioteca, corrija plugin ou chave e importe de novo. DeDRM só atua na entrada.

Quando o livro aparecer como KFX, abra no viewer e confira algumas páginas. Depois clique em Convert books, escolha EPUB como saída e teste o arquivo resultante no leitor onde pretende usar. Só depois disso faça a importação em lote.

No meu caso, o KFX abriu, converteu e o EPUB funcionou fora do Kindle. Com isso eu sabia que o caminho inteiro estava funcionando: Microsoft Store, TPM, archiver, K4I, DeDRM 10.0.28 e KFX Input 2.33.0.

Faça backup do que realmente importa

Depois da conversão, eu preservo três coisas:

• os EPUBs finais, que leio em qualquer aparelho;
• os KFX-ZIP originais, até conferir que todos os EPUBs estão íntegros;
• o oldbooks.k4i, criptografado e separado da biblioteca.

Meu keyfile em texto puro fica com permissão 0600. Também mantenho uma cópia criptografada com SOPS e age, enquanto a chave privada fica em outro backup. Não coloque oldbooks.k4i cru no Git só porque o repositório é privado. Repositório privado vaza também.

Os EPUBs entram na mesma estratégia que uso pros outros arquivos importantes: cópia local, NAS e backup off-site. Já expliquei essa paranoia em Protegendo e Recuperando Dados Perdidos e mostrei a mesma filosofia aplicada a filmes no meu Netflix Pessoal.

Não apague os arquivos do Kindle ou da VM no minuto em que a conversão termina. Abra os EPUBs, veja capa, índice, imagens, notas e algumas páginas. Backup que nunca foi testado é só torcida organizada.

Conclusão

Amazon já apagou livros remotamente, editoras atualizam capas e conteúdo, aplicativos antigos param de funcionar e formatos mudam. O próprio fim do download via USB mostrou que uma função disponível por dezoito anos pode desaparecer com uma linha num aviso.

O exemplo clássico continua inacreditável: em 2009 a Amazon apagou 1984 e Animal Farm, de George Orwell, dos Kindles de clientes. Depois vieram revisões de Roald Dahl, R.L. Stine e Agatha Christie empurradas pra cópias digitais que já tinham sido compradas. O artigo da Vice resume esses casos. O Dammit Jeff também bate muito nessa tecla: até a capa original que você escolheu pode virar pôster feio da adaptação do streaming porque publisher e loja decidiram atualizar sua “compra”.

Não importa se a alteração futura é censura, correção legítima, nova capa horrorosa de adaptação da Netflix ou apenas um bug. Eu comprei uma edição. Quero preservar a edição que comprei.

DRM não impede pirataria. Livro popular aparece em torrent no dia do lançamento. DRM só atrapalha o cliente que pagou, dificulta acessibilidade, prende hardware ainda bom e transforma uma compra em aluguel por prazo indefinido.

Calibre, DeDRM, KFX Input e uma VM descartável devolveram minha biblioteca. Agora posso colocar os EPUBs no Xteink, num Kobo, num tablet, no celular ou num leitor que ainda nem existe. Posso trocar de sistema operacional e posso desligar a internet. Os arquivos continuam comigo.

Se não está na sua máquina, não é seu.

No dia seguinte o goodalexander reproduziu o mesmo comportamento num devnet descartável: um rsync --delete-delay contra / varreu /var, /etc e o estado dos validators dele, corrompendo o filesystem a ponto de precisar reinstalar o sistema operacional. A conclusão dele: “you can’t use this thing in prod”.

Casos assim aparecem de tempos em tempos desde que agentes de coding viraram mainstream. E toda vez a discussão descamba pros mesmos dois extremos: de um lado “viu? IA é perigosa, nunca deixe rodar nada sozinha”, do outro “quem deixa um agente solto no sistema merece o que acontece”. Eu acho os dois lados preguiçosos. Deixa eu contar minha experiência real e o que eu faço a respeito.

Cinco meses de maratona, zero acidentes

Desde fevereiro eu estou maratonando Claude Code, Codex e OpenCode. Quase todos os dias, quase o tempo todo, em sessões muito longas que às vezes atravessam dias. Estourando o limite do meu plano Max da Anthropic e do meu plano Plus da OpenAI com folga. O resultado concreto até agora: quase 40 repositórios novos no meu GitHub e mais de 500 mil linhas de código produzidas.

E nos últimos dois meses eu rodo tudo exclusivamente em “YOLO mode”. Pra quem não conhece o jargão: por padrão, esses agentes pedem permissão antes de cada comando que vão executar no seu terminal. O YOLO mode desliga essa trava. No Claude Code é a flag --dangerously-skip-permissions, no Codex é o --yolo, no OpenCode você configura as permissões pra aprovar tudo. O agente roda o que quiser, quando quiser, sem me perguntar nada.

Em cinco meses nesse regime, nem uma vez um agente apagou um arquivo que eu não pedi. Nem uma vez rodou um comando destrutivo fora do escopo. As frustrações que eu tenho com agentes são de outra natureza (teimosia, solução preguiçosa, contexto que se perde), coisas irritantes mas a quilômetros de distância de um rm -rf no meu home.

Então quando eu vejo esses relatos, minha primeira hipótese sempre vai pro mesmo lugar: o prompt. Pra um agente “enlouquecer” desse jeito, em geral o usuário escreveu instruções muito ruins. Vagas, ambíguas, pedindo limpeza sem definir o que é lixo, mandando o agente “resolver” sem dar contexto. Falta de habilidade de comunicação combinada com falta de conhecimento técnico pra perceber que o pedido estava mal formulado. O agente executa a instrução que você escreveu, com todas as ambiguidades que você deixou nela.

Dito isso, eu NÃO confio completamente em LLMs. Ninguém deveria.

A diferença é que a minha desconfiança vira engenharia em vez de virar tweet.

Camada por camada, é assim que eu durmo tranquilo.

Camada 1: sandbox com ai-jail

Quando eu realmente suspeito que uma sessão pode fazer besteira (vou mexer em scripts de sistema, vou deixar o agente rodar por horas sem supervisão num código que toca no filesystem), eu abro o harness dentro do ai-jail, uma ferramenta minha, open source, escrita em Rust.

O ai-jail é um wrapper de sandbox pra agentes de coding. No Linux ele usa o bwrap (bubblewrap, a mesma base do Flatpak), no macOS usa o sandbox-exec. A ideia: o processo enxerga um filesystem que parece normal, mas só o diretório do projeto atual é real e persistente. O resto do $HOME, os diretórios vizinhos, o /tmp, tudo vive em tmpfs e evapora quando a sessão termina. O estado do agente (~/.claude, ~/.codex etc) é montado de verdade pra ele continuar logado e configurado, mas ~/.ssh, ~/.gnupg, ~/.aws e perfis de browser nunca entram na jaula.

Instalar é um comando:

# Arch Linux
yay -S ai-jail-bin

# macOS / Linux via Homebrew
brew tap akitaonrails/tap && brew install ai-jail

# ou direto do crates.io
cargo install ai-jail

E usar é mais simples ainda:

cd ~/Projects/meu-app
ai-jail claude       # Claude Code na jaula
ai-jail codex        # Codex na jaula
ai-jail --dry-run claude  # mostra a política sem rodar

Se o agente resolver rodar rm -rf ~ lá dentro, ele apaga um tmpfs que ia sumir de qualquer jeito. Meu home real nem foi montado. Pra quem está começando com YOLO mode e ainda não tem calo, é o jeito mais barato de errar sem consequência.

Camada 2: BTRFS e snapshots (a rede de segurança de verdade)

Agora o ponto principal desse post. Eu advogo há ANOS que usuário de Linux deveria usar BTRFS em vez de EXT4. Fiz um episódio inteiro do Akitando sobre isso em 2023, muito antes de existir agente de coding pra levar a culpa. O argumento era o mesmo: seus dados precisam sobreviver a erro humano. Um LLM rodando rm -rf no lugar errado é só uma categoria nova de erro humano, terceirizado.

Por que BTRFS é superior pra desktop? Copy-on-write (CoW): o filesystem nunca sobrescreve um bloco no lugar, ele escreve a versão nova em outro bloco e atualiza os ponteiros. Checksum de dados e metadados, então bitrot silencioso é detectado em vez de corromper seu arquivo caladinho. Compressão transparente. Subvolumes, que funcionam como partições flexíveis sem tamanho fixo. E a consequência mais valiosa do CoW: snapshots leves.

Um snapshot BTRFS é instantâneo e custa perto de zero espaço no momento em que é criado. Ele congela os ponteiros dos blocos atuais em vez de copiar dados. Só o que divergir a partir dali (blocos novos ou modificados) passa a ocupar espaço extra. Na prática você pode tirar dezenas de snapshots por dia sem sentir. Neste exato momento minha máquina mantém 23 snapshots do sistema, e o custo é a diferença entre eles, alguns poucos gigas.

Agendando snapshots

As duas ferramentas clássicas são o Timeshift e o snapper. O Timeshift é o mais amigável: interface gráfica, você marca “quantos snapshots manter” por hora/dia/semana/mês e ele cuida do resto. Ele espera o layout de subvolumes @ (raiz) e @home, que é o padrão da maioria das distros que instalam em BTRFS hoje. O snapper (nascido no openSUSE) é mais granular: configs por subvolume, timeline automática, integração com o gerenciador de pacotes pra tirar snapshot antes e depois de cada instalação.

# Timeshift: snapshot manual antes de uma sessão suspeita
sudo timeshift --create --comments "antes de soltar o agente"

# snapper: criar config pro /home e ligar a timeline
sudo snapper -c home create-config /home
sudo systemctl enable --now snapper-timeline.timer

Meu setup roda Timeshift agendado, mais o grub-btrfsd de plantão (já explico por quê).

Recuperando arquivos apagados

Aqui está a mágica que todo mundo que perdeu arquivo pra um agente gostaria de ter tido. Snapshot BTRFS é navegável como um diretório comum. O agente apagou seu projeto às 15h? O snapshot das 14h ainda tem tudo:

# com Timeshift, os snapshots ficam montados em /run/timeshift
sudo ls /run/timeshift/backup/timeshift-btrfs/snapshots/

# achou o snapshot de antes do estrago? copia de volta e pronto
sudo cp -a /run/timeshift/backup/timeshift-btrfs/snapshots/2026-07-11_14-00-01/@home/akitaonrails/Projects/meu-app ~/Projects/

Com snapper é a mesma coisa via .snapshots dentro do subvolume, e ele ainda tem o snapper undochange pra reverter mudanças específicas entre dois snapshots. Recuperação em segundos, sem drama, sem ferramenta forense.

E se o sistema nem ligar mais?

O caso do goodalexander foi além de perder arquivos: o agente varreu /var e /etc e o sistema ficou imprestável, precisou reinstalar o OS. Com BTRFS nem isso seria necessário. É pra esse cenário que existe o grub-btrfs: um daemon que observa seus snapshots e regenera o menu do GRUB com uma entrada de boot pra cada um.

Sistema não sobe mais? Reinicia, segura o menu do GRUB, escolhe “snapshots” e dá boot direto num snapshot de ontem, read-only. De dentro dele, roda timeshift --restore, escolhe o snapshot bom, reinicia de novo. Sistema inteiro de volta ao estado de antes do desastre, em menos tempo do que você levaria pra achar o pendrive de instalação. No pior caso absoluto (o próprio GRUB foi junto), um live USB qualquer monta a partição BTRFS, aponta o subvolume padrão de volta pro snapshot bom e resolve.

E no macOS? E no Windows?

Usuário de Mac tem o equivalente direto: o APFS, filesystem padrão desde o High Sierra (2017), também é copy-on-write e também tem snapshots leves. Quem gerencia é o Time Machine: com ele ativado, o macOS tira snapshots locais automáticos de hora em hora e guarda as últimas 24 horas no próprio disco, independente do backup externo. E dá pra criar um na mão antes de soltar o agente:

# criar um snapshot local do APFS agora
tmutil localsnapshot

# listar os snapshots existentes
tmutil listlocalsnapshots /

Pra recuperar, abre o próprio Time Machine (“Browse Time Machine Backups” na barra de menu): ele navega pelos snapshots locais mesmo sem nenhum disco externo plugado, e você restaura o arquivo dali. Quem prefere terminal monta o snapshot read-only com mount_apfs -s e copia de volta. Ou seja, o caso do Matt Shumer lá do começo tinha solução nativa no próprio Mac dele: um snapshot de uma hora antes teria devolvido quase tudo.

No Windows a história é mais fraca. O NTFS tem o Volume Shadow Copy (VSS), que alimenta os restore points e a aba “Versões Anteriores”, mas é voltado pra arquivos de sistema e raramente está cobrindo seus dados na hora que você precisa. Nada com a leveza e a previsibilidade de um snapshot CoW agendado. Se você desenvolve no Windows, trate backup externo como obrigatório, sem discussão (e o restic da próxima seção roda em Windows numa boa).

Camada 3: backup externo com restic

Snapshot mora no mesmo disco que os dados. Se o NVMe morrer, morrem os dois juntos. Por isso a outra coisa que eu repito há anos: todo mundo precisa de backup externo, seja num HD externo, seja num NAS. Eu uso um Synology na rede local, montado via NFS, e documentei o setup completo aqui.

Em cima dele roda o restic, que na minha opinião é a melhor ferramenta de backup pra essa finalidade: deduplicação, criptografia, snapshots incrementais e restore simples. Minha configuração real é um script disparado por um timer do systemd todo dia às 3 da manhã. Ele confere se o NAS está montado, faz o backup do /home e do /mnt/data/Projects pulando caches (node_modules, target/ do Rust, __pycache__ e afins, tudo num arquivo de excludes), e depois aplica a política de retenção: 7 diários, 4 semanais, 6 mensais, 1 anual.

Reproduzir o essencial é isso aqui:

# uma vez: criar o repositório no NAS
restic init --repo /mnt/nas/desktop-backup

# todo dia (via cron ou systemd timer):
restic -r /mnt/nas/desktop-backup backup ~ /mnt/data/Projects \
    --exclude-file=~/.config/restic/excludes --exclude-caches

restic -r /mnt/nas/desktop-backup forget \
    --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --keep-yearly 1 --prune

E se o dia ruim chegar de verdade (agente destrutivo, disco morto, ransomware, tanto faz a causa):

# listar os snapshots disponíveis
restic -r /mnt/nas/desktop-backup snapshots

# restaurar um arquivo ou diretório específico
restic -r /mnt/nas/desktop-backup restore latest \
    --target /tmp/recuperado --include /home/akitaonrails/Projects/meu-app

# ou montar o repositório inteiro como filesystem e navegar com calma
restic -r /mnt/nas/desktop-backup mount /mnt/restic

Repara na arquitetura em camadas: o snapshot BTRFS resolve o acidente de minutos atrás em segundos. O restic resolve o desastre de dias atrás, incluindo hardware morto. Um agente de IA teria que ser muito dedicado pra atravessar as duas camadas, e mesmo assim ainda existiria a cópia de ontem no NAS, que ele nem alcança.

E nas empresas? Profissionalismo

Tudo acima é sobre a minha máquina pessoal. Agora sobe o sarrafo: ambiente corporativo.

A regra número um é simples e inegociável: nenhum agente de IA deve ter acesso a produção. Nunca. Nem SSH direto em servidor de produção, nem credencial de banco de produção, nem token de admin de serviço em produção. Se o seu agente consegue rodar um DELETE na base que atende clientes, o problema deixou de ser a IA faz tempo: qualquer estagiário com o mesmo acesso é a mesma bomba-relógio, só com menos velocidade de digitação.

Agente em staging, por outro lado, eu defendo. É pra isso que staging existe. Mas mesmo em staging tem jeito certo: você resiste à tentação de pedir ações one-shot (“roda um apt install aí”, “dá um systemctl restart”, “conecta no postgres e executa isso”). Comando avulso executado na mão é conhecimento que evapora. Sua infraestrutura precisa ser automatizada e reproduzível: Ansible, Kubernetes, Terraform, o que fizer sentido pro seu stack. O papel do agente passa a ser escrever e refinar essas receitas, que ficam versionadas em git.

Um exemplo pequeno, aqui da minha mesa

Eu tenho um ambiente de jogos no meu PC principal, mas eu me recuso a misturar pacote de emulador com meu ambiente de desenvolvimento. Então isolei os jogos dentro de um distrobox. Pra quem não conhece: o distrobox cria containers (via podman ou docker) que se integram com seu desktop como se fossem nativos. Compartilham seu home (ou um home dedicado), acesso a GPU, Wayland, áudio. Na prática é uma distro completa dentro da sua distro, com espaço de pacotes separado.

O distrobox-gaming é um repositório de playbooks Ansible que constrói uma box Arch chamada gaming do zero: ES-DE de frontend, emuladores standalone (shadPS4, RPCS3, PCSX2, Dolphin, DuckStation, Eden e mais uma dúzia), cores do RetroArch, configs otimizadas por jogo, atalhos no launcher do host. E o distrobox-llm faz o mesmo pra uma box de trabalho com LLMs locais: CUDA, cuDNN, Ollama, whisper.cpp e LM Studio isolados numa box com --nvidia, enquanto o host só carrega o driver. Upgrade de versão maior do CUDA deixa de chacoalhar meu ambiente de desenvolvimento.

Quem escreveu a esmagadora maioria desses playbooks? Os agentes. Em vez de pedir “instala o RPCS3 pra mim”, meu prompt é “escreve a receita Ansible idempotente que instala e configura o RPCS3, roda ela, verifica o resultado e corrige até passar”. Olha um trecho real do role que cria a box do LLM:

- name: Check if distrobox exists
  ansible.builtin.shell: "distrobox list 2>/dev/null | awk '{print $3}' | grep -qx {{ dl_box_name }}"
  register: _box_exists
  changed_when: false
  failed_when: false

- name: Create distrobox
  ansible.builtin.command: >-
    distrobox create
    --name {{ dl_box_name }}
    --image {{ dl_image }}
    --home {{ dl_box_home }}
    {{ '--nvidia' if dl_nvidia_enabled else '' }}
  when: _box_exists.rc != 0

Idempotente: confere se a box existe antes de criar, rodar duas vezes dá no mesmo. Se meu PC pegar fogo amanhã, eu recrio os dois ambientes inteiros com um ansible-playbook site.yml em cada repo. O conhecimento está na receita, versionado, auditável. Zero comando perdido no histórico do shell.

Escalando o mesmo princípio pra produção

Numa empresa, troca distrobox por Kubernetes e o princípio é idêntico. O agente escreve o manifesto, testa no cluster de staging, você promove pra produção manualmente:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: minha-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: minha-api
  template:
    metadata:
      labels:
        app: minha-api
    spec:
      containers:
        - name: minha-api
          image: registry.exemplo.com/minha-api:v42
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
          resources:
            limits:
              memory: 512Mi

O fluxo profissional: o agente produz e ajusta o manifesto (ou o chart do Helm, ou o módulo do Terraform), aplica em staging (kubectl apply -n staging), roda os testes, observa efeitos colaterais, bugs, comportamento não intencional, e itera até você estar satisfeito. Aí VOCÊ, humano, promove pra produção (via PR revisado num fluxo GitOps, ou um kubectl apply manual e consciente), monitorando cada passo. O agente fez todo o trabalho pesado: os artefatos, os procedimentos, os checklists. Dá até pra pedir pra ele gerar a documentação de auditoria no final. Mas o dedo que aperta o botão de produção tem CPF.

Até o SQL “simples” de manutenção

Um caso que parece inofensivo e me incomoda muito: comando SQL de manutenção em produção. Muita gente sempre rodou esses comandos na mão, direto no client de produção, e agora está pedindo pro agente escrever E executar. Isso é inaceitável, com ou sem IA. Seu sistema deve ter um fluxo de migrations: a mudança vira código versionado, roda em staging primeiro, é validada, e só então executa em produção dentro do processo normal de deploy.

E “produção”, por definição, significa duas coisas que muita empresa finge ter. Primeiro: backups de verdade, testados, com restore ensaiado.

Jamais rode em produção qualquer coisa da qual você não consegue se recuperar.

Segundo: monitoramento. Se você não tem visibilidade do estado do sistema, você não tem produção, tem um servidor ligado na tomada e reza.

Monitoramento: até no meu humilde PC

E monitoramento é tão parte da disciplina que eu aplico até na minha máquina pessoal. Recentemente eu desenvolvi um widget de system health pro meu clock-tui (meu fork mantido do clock-tui original, com widgets de comando no modo relógio). Ele fica aberto num canto mostrando isso aqui:

Uma linha de veredito (“all systems healthy”) e o estado de tudo que este post descreveu: o backup do restic rodou há 19 horas e o próximo é às 03:03; o Timeshift mantém 23 snapshots; a limpeza de caches de desenvolvimento rodou há 32 horas; o scrub do BTRFS está em dia em cada filesystem, com trim recente, alocação saudável e zero erros de I/O; mais zumbis, load, memória e ocupação de cada disco. O widget (tclock-system-health) vem junto no repositório e no pacote do AUR, e detecta a maior parte disso sozinho.

Por trás dele estão as manutenções automatizadas, todas em timers do systemd: o restic diário às 3h; o dev-cache-clean (dia 1 e dia 15) varrendo target/ órfãos de Rust e cache do yay, que juntos devolvem dezenas de gigas; o btrfs-scrub mensal por filesystem validando checksums; o fstrim semanal. Nada disso exige que eu lembre de nada. Quando algum atrasar ou falhar, o widget muda de cor na minha cara.

Esse é o nível caseiro, proporcional a um PC pessoal. Numa empresa você vai de full-blown: Prometheus coletando métricas, Grafana desenhando os dashboards, Alertmanager acordando o plantonista às 3 da manhã. A escala muda, o princípio é o mesmo: o estado do sistema visível o tempo todo, e alguém (ou alguma coisa) sendo avisado quando sai do trilho.

Conclusão: disciplina

Volta nos dois tweets do começo. Em ambos os casos, um único comando errado causou perda real, e a discussão pública virou “em quem eu confio mais”. A pergunta certa é outra: por que um único comando errado, de qualquer origem, tem o poder de causar perda irrecuperável na sua máquina?

Ser profissional é ser disciplinado, e a disciplina começa em casa. Meu PC pessoal opera com o mesmo rigor que eu cobraria de um ambiente corporativo: filesystem com snapshots leves e agendados, boot recuperável via GRUB, backup externo diário com política de retenção, sandbox pra sessões suspeitas, ambientes isolados e reconstruíveis por receitas versionadas, manutenção automatizada e um monitor que me avisa quando qualquer peça atrasa. Custo de manutenção mensal disso tudo: perto de zero. Foi montado uma vez (em boa parte pelos próprios agentes) e funciona sozinho.

Com essas camadas, a pergunta do título quase perde o sentido. O agente apagou um diretório? Snapshot de uma hora atrás, dois minutos de recuperação. Destruiu o sistema? Boot num snapshot pelo GRUB, restore, dez minutos. Fritou o disco junto? Restic no NAS, backup de ontem. Em cinco meses de YOLO mode eu nunca precisei de nenhuma dessas redes pra acidente de IA. Mas eu durmo tranquilo justamente porque elas estão lá.

LLM rodando solto no seu sistema é só o teste de estresse mais recente da sua disciplina. Se um agente descontrolado consegue causar perda permanente nos seus dados, a vulnerabilidade sempre esteve aí, esperando um erro seu, um disco ruim ou um ransomware. O agente foi só o mensageiro que chegou primeiro.

E-mail sempre foi a parte mais chata desse exercício. Meu workflow antigo era abrir o Thunderbird, deixar ele puxar tudo de Gmail via IMAP, e fazer backup do diretório ~/.thunderbird. Funciona, mas é manual, chato (lembrar de abrir o Thunderbird de vez em quando), e preso ao próprio Thunderbird: se quero ler aqueles e-mails em outro cliente, eles estão num formato interno proprietário.

Depois de um tempo caiu a ficha: Linux tem suporte nativo a e-mail desde sempre. Os protocolos modernos (IMAP, SMTP) são padrão aberto. E o formato de armazenamento local, Maildir, existe e funciona muito bem desde os anos 90. Não precisa de Thunderbird pra nada.

O que é Maildir

Maildir foi criado pelo Daniel J. Bernstein (djb) como parte do qmail em 1995. A ideia era resolver os problemas de file locking do formato mbox, onde a caixa de e-mail inteira é um arquivo único e dois processos escrevendo ao mesmo tempo podiam corromper tudo. No Maildir, cada mensagem vira um arquivo separado numa estrutura de três subdiretórios:

• tmp/ — onde o e-mail é escrito enquanto chega
• new/ — mensagens novas, ainda não lidas
• cur/ — mensagens já vistas pelo cliente, com flags no nome do arquivo (:2,S = seen, :2,F = flagged, etc.)

A entrega é atômica: o MTA escreve a mensagem em tmp/, depois faz um rename() pra new/. rename() em filesystem POSIX é atômico, então não tem janela de corrupção. Sem locking, sem corrupção, e cada e-mail é só um arquivo de texto puro que você pode ler com cat, indexar com grep, versionar com git se quiser.

Trinta anos depois, ainda é o formato local padrão da maioria dos clientes de e-mail Linux. E é o formato que vou usar pra fazer o mirror do Gmail.

A ferramenta: mbsync (isync)

O que faz a ponte entre o IMAP do Gmail e o Maildir local é o mbsync, o binário do pacote isync. Ele lê uma config simples (~/.config/isyncrc), conecta no IMAP do Gmail, e copia as mensagens pro disco. A diferença pro offlineimap (alternativa mais conhecida) é que mbsync é escrito em C, é bem mais rápido em mailboxes grandes, e tem menos casos esquisitos com Gmail.

A config é direta. Resumo do que tem no meu ~/.config/isyncrc (sem senha, claro):

IMAPAccount minha-conta
Host imap.gmail.com
User you@example.com
PassCmd "/home/akitaonrails/.config/mbsync/bin/mbsync-password you@example.com"
TLSType IMAPS
CertificateFile /etc/ssl/certs/ca-certificates.crt
AuthMechs LOGIN

IMAPStore minha-remote
Account minha-conta

MaildirStore minha-local
SubFolders Verbatim
Path ~/.local/share/mail/mbsync/you.example.com/
Inbox ~/.local/share/mail/mbsync/you.example.com/INBOX

Channel minha-backup
Far :minha-remote:
Near :minha-local:
Patterns * !"[Gmail]/Trash" !"[Gmail]/Spam" !"[Gmail]/Drafts"
Create Near
Sync Pull New Flags
Expunge None
Remove None

Três pontos importantes nessa config:

1. Sync Pull: só puxa do servidor pro local. Nada que eu faça no Maildir vai propagar pro Gmail. Isso é proteção contra acidentes (se eu apagar um arquivo localmente, não some do Gmail).
2. Expunge None + Remove None: se uma mensagem some do Gmail (alguém apagou ou o Google decidiu mover pra lugar nenhum), ela continua no meu Maildir. O backup acumula histórico, não espelha o estado atual.
3. PassCmd em vez de senha em texto: a senha vai num script que faz secret-tool lookup no keyring do desktop. Nada de senha em arquivo de config no disco.

O bloco da senha

O mbsync-password é um wrapper minúsculo que isola o segredo:

#!/usr/bin/env bash
set -euo pipefail
account="${1:?usage: mbsync-password ACCOUNT}"
password="$(secret-tool lookup service mbsync account "$account" 2>/dev/null || true)"
[ -z "$password" ] && { echo "missing keyring secret for $account" >&2; exit 1; }
printf '%s' "$password"

Senha é armazenada uma vez com secret-tool store --label="mbsync gmail" service mbsync account you@example.com. O Gmail moderno exige uma app password específica (16 caracteres, gerada em myaccount.google.com/apppasswords) porque não aceita mais autenticação básica direta — você não cola sua senha do Google ali, cola uma chave gerada exclusivamente pro app, que dá pra revogar a qualquer momento sem mexer no resto da conta.

Automação com systemd user timer

Pra não ter que rodar o mbsync na mão, montei dois user units no systemd. Primeiro o serviço, que é só uma chamada do script wrapper:

# ~/.config/systemd/user/mbsync-backup.service
[Unit]
Description=Mirror Gmail accounts locally with mbsync
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=%h/.config/mbsync/bin/mbsync-run

E o timer que dispara o serviço periodicamente:

# ~/.config/systemd/user/mbsync-backup.timer
[Unit]
Description=Run mbsync periodically

[Timer]
OnBootSec=10m
OnUnitActiveSec=30m
Persistent=true
Unit=mbsync-backup.service

[Install]
WantedBy=timers.target

OnBootSec=10m espera 10 minutos depois do boot pra primeira execução (evita brigar com o network-online no início da sessão). OnUnitActiveSec=30m re-dispara 30 minutos depois de cada execução terminar. Persistent=true faz com que, se a máquina estava desligada na hora que seria pra disparar, ele compense rodando logo no próximo boot. O wrapper já pega flock pra não rodar dois mbsync em paralelo, então se uma sincronização demorar mais que 30min, a próxima só espera. Tudo loga em ~/.local/state/mbsync/mbsync.log.

Pra gerenciar o timer, os comandos básicos:

# Re-ler os arquivos depois de criar/editar
systemctl --user daemon-reload

# Ativar agora + habilitar pra subir no próximo boot
systemctl --user enable --now mbsync-backup.timer

# Conferir se o timer tá ativo e quando dispara da próxima vez
systemctl --user status mbsync-backup.timer
systemctl --user list-timers mbsync-backup.timer

# Disparar uma sincronização imediata sem esperar o intervalo
systemctl --user start mbsync-backup.service

# Acompanhar logs em tempo real
journalctl --user -u mbsync-backup.service -f

# Conferir status da última execução do serviço
systemctl --user status mbsync-backup.service

# Pra desligar tudo
systemctl --user disable --now mbsync-backup.timer

Pra que o timer continue rodando quando você não está logado (útil em desktop que fica ligado 24/7), habilite linger uma única vez: sudo loginctl enable-linger $USER. Sem isso, os user units só rodam enquanto você tem sessão ativa.

Ativa, confere o status uma vez pra ter certeza que tá verde, e esquece que existe.

Backup do Maildir com restic

Agora que o Gmail está espelhado em ~/.local/share/mail/, ele entra no mesmo pipeline de backup do resto do meu home. Eu uso o restic pra mandar snapshots criptografados pro NAS. O restic é incremental por content-addressable storage, então adicionar 100MB de e-mail no snapshot diário custa basicamente o delta — não os 100MB inteiros toda vez. Pra cópia off-site, meu NAS Synology já tem o pacote Glacier Backup nativo, que cuida de mandar snapshots criptografados pro AWS Glacier sem eu precisar configurar nada além do bucket e da chave. O Maildir entra junto no mesmo plano, então o backup off-site sai de graça em termos de configuração extra.

O Maildir é amigável a backup incremental por construção: cada e-mail é um arquivo imutável (nem o nome muda depois de baixado, exceto pela flag de seen/flagged). O restic deduplica perfeitamente. Snapshot de mailbox de 5GB tem custo marginal próximo de zero depois do primeiro.

A vantagem do formato aberto: muitos clientes

Aqui mora a parte que me convenceu de vez. Maildir é um padrão aberto, então qualquer cliente que entenda Maildir lê o mesmo backup. Eu posso:

• Abrir no mutt ou neomutt quando quero algo rápido no terminal.
• Abrir no aerc quando quero TUI mais moderna.
• Apontar o Thunderbird ou Claws Mail pra ~/.local/share/mail/... quando quero GUI.
• Migrar pra outro cliente no futuro sem ter que exportar/importar nada.

Os e-mails são meus. Vivem no meu disco. Em formato texto, legível por qualquer ferramenta.

Bônus: scripts e bots leem direto

A consequência menos óbvia disso é que, se eu quiser construir um filtro, um bot, um classificador, ou qualquer coisa que mexe nos e-mails, eu não preciso passar por OAuth do Gmail, criar projeto no Google Cloud, gerenciar refresh tokens, lidar com quota — nada. Eu leio direto do Maildir.

O Python tem suporte nativo a Maildir na biblioteca mailbox. Um exemplo bobo pra listar assuntos da inbox:

import mailbox
from email.header import decode_header

inbox = mailbox.Maildir("/home/akitaonrails/.local/share/mail/mbsync/you.example.com/INBOX")

for key, msg in inbox.iteritems():
    subject = msg.get("Subject", "")
    sender = msg.get("From", "")
    # decode_header lida com Subject em UTF-8 / latin-1 / etc
    decoded = "".join(
        part.decode(enc or "utf-8") if isinstance(part, bytes) else part
        for part, enc in decode_header(subject)
    )
    print(f"{sender[:40]:<40}  {decoded[:60]}")

Roda em milissegundos, não consome quota de API nenhuma, não tem rate limit, não precisa renovar credencial. É só leitura de arquivos. Se você quer fazer um pipeline mais sério (parser de anexos, classificação por LLM, regras automáticas), o mesmo princípio se aplica.

Resumo

A combinação que finalmente me deixou tranquilo:

• mbsync (isync) puxa do IMAP do Gmail pra Maildir local, automaticamente via systemd timer.
• Maildir preserva o formato aberto, cada e-mail é um arquivo, pull-only protege contra exclusão acidental.
• restic snapshota o Maildir pro NAS com deduplicação ridícula, e o Glacier Backup do Synology leva isso pra off-site cifrado.
• Cliente de e-mail livre — mutt, neomutt, aerc, Thunderbird, Claws, qualquer um lê.
• Automação leve — bot ou script lê direto do disco, sem OAuth, sem API.

O Gmail vira só uma interface web confortável pra ler e responder. A propriedade real dos e-mails está no meu disco, replicada no NAS, replicada em backup off-site cifrado. Se o Google fechar minha conta amanhã (já aconteceu com gente), perco a interface, mas mantenho a história inteira. Pra mim é o jeito definitivo de fazer isso. Recomendo.

No meu caso, eu passei 10 anos usando Manjaro GNOME como meu daily driver. Manjaro que é um derivado de Arch. A razão era a instalação mais simples e configurações pré-prontas. Mas hoje em dia, com archinstall, acho que não vale mais a pena. Sei que existem outros derivados, mas é melhor ficar no original mesmo.

Pra quem é de Ubuntu ou derivados de Debian, Fedora, etc, vai ter uma pequena curva de aprendizado no gerenciador de pacotes, Pacman e Yay em vez de Apt ou Dnf, mas quando entenderem o AUR, nunca mais vão querer outra coisa. Tem literalmente tudo que você precisa, sem ter que lidar com repositórios de terceiros.

Demorei pra testar o Omarchy porque eu já usava Hyprland antes do Omarchy ter sido criado. O DHH já tinha o Omakub antes, que era um conjunto de scripts pra customizar um Ubuntu pra ser um bom ambiente de desenvolvimento. Eu gostava dele mas como preferia Manjaro, fiz um fork chamado Omakub-MJ. Depois disso resolvi desinstalar o GNOME e GDM e instalar um outro conjunto de scripts chamado ML4W, que deixa o Hyprland bem bonito também. Então o Omarchy não tinha tanta novidade, pra mim.

Só que eu uso o mesmo Manjaro já faz anos. Tinha um monte de configs e scripts velhos misturados. Meu Manjaro GNOME já não tinha mais GNOME. Meu Hyprland era Frankenstein. A única barreira era minha configuração de QEMU/Libvirt pra rodar Windows com GPU passthrough, que era o que eu usava pra editar videos quando ainda postava no meu canal do YouTube.

Mas como parei de editar videos, esse Windows também não é mais tão importante. Eu tinha outra máquina virtual Windows com GPU passthrough pra games. Mas atualmente tenho um mini-PC separado com Windows que uso só pra games. Também tinha outra VM com outro Linux só pros meus experimentos de I.A., mas desde então migrei pra rodar nativo isolando tudo com Docker. Ou seja, minhas VMs já não são mais importantes. Veja meus blog posts anteriores pra saber sobre I.A. em Docker.

Com o lançamento do Omarchy 2.0, parece uma boa hora pra reinstalar Arch do zero com Omarchy por cima e recomeçar com tudo limpo e bonito.

1 - Meu Setup

Cada caso vai ser diferente. Este post tem como principal função servir como minha referência pessoal pro futuro, se eu precisar reinstalar tudo de novo.

Não, não vou usar NixOS. Eu realmente não acho que compensa. Só vale a pena se você é administrador de sala de computador ou infraestrutura de servidores e seu dia a dia é ter que reconstruir setups idênticos de maneira confiável. Pra um usuário normal, que só vai reinstalar a cada 2 ou 3 anos, não vale nem um pouco a curva de aprendizado nem o trabalho de manutenção. É perda de tempo. Eu vou gastar dias aprendendo agora, terminar o setup, passar 2 anos e já vou ter esquecido tudo. Arch Linux sozinho já é estável o suficiente pra eu não precisar disso.

Meu setup ainda é o mesmo da época que estava editando videos pro canal. É um Ryzen 9 7850X3D com 16 cores, 32 threads, pico de 5Ghz. Ainda é um excelente CPU que tem poder de sobra pros meus usos, por isso não me vejo querendo atualizar tão cedo. São raras as vezes que eu consigo saturar tudo isso de core ao mesmo tempo nessas velocidades. Melhor ainda: ele tem GPU integrada AMD que torna instalar Linux mil vezes mais fácil do que se eu tivesse NVIDIA.

Mas, eu também tenho uma GPU discreta, separada, a NVIDIA RTX 4090 (não, não preciso de uma 5090, tem o mesmo tanto de VRAM). Ela vai ficar pra tarefas secundárias e não pra carregar meu ambiente gráfico. Coisas como render de Cycles no Blender, ou rodar LLMs com ollama da vida. Antes eu usava GPU passthrough pra uma VM em QEMU/Libvirt pra rodar Windows em parelelo ao Linux. Tanto pra editar video quanto pra games.

Como não edito mais videos, não preciso desse setup complicado então nem vou me preocupar mais em instalar Libvirt de volta. Se eu precisar de Windows, vou deixar em dual boot. Se precisar editar video, hoje em dia temos DaVinci Resolve Studio que roda nativo em Linux (mil vezes melhor que Adobe Premiere). Pra games eu tenho um mini PC separado com uma RTX 4060 ligado na minha TV. Melhor coisa é ter um PC totalmente separado pra games.

Então este setup é pra ser um Linux puro, com acesso ao meu NAS Synology DS 1821+ de 100TB. Única coisa extra que vou precisar é configurar mounts de NFS, como já detalhei neste outro post.

Um detalhe é que eu tenho 4 NVMEs neste PC. 2TB pro meu Linux antigo. 2 TB pro dual boot/VM de Windows. 2 TB só como drive de Steam e 1 TB pra coisas aleatórias. Como vou limar a VM de Steam, também não preciso mais dedicar um NVME inteiro só pra isso. Em vez disso vou fazer o diretório “/home” do novo Linux ser esses 2 TB inteiro.

Isso vai me permitir não me preocupar mais com Docker enchendo meu drive e travando meu sistema inteiro com falta de espaço. Da última vez eu tinha “resolvido” isso fazendo um drive remoto com iSCSI no meu NAS (que tem espaço infinito). Faz tirando minha VM de Steam vou ganhar 2TB então resolvo o problema localmente e com menos configurações.

RAM eu tenho de sobra, 96GB de DDR5. Com isso também não preciso me preocupar com partição de swap. Swap só é importante caso você tenha menos de 32GB de RAM, se estiver rodando muito Docker e ficar batendo no máximo de consumo de RAM muito rápido. Ou, se estiver usando notebook e quer ter a opção de hibernação (poder gravar a RAM em disco, dar power off completo na máquina e conseguir voltar depois exatamente de onde parou - que é diferente de suspender, que ainda usa energia).

Se quiser hibernar precisa ter um pouco mais do que o tamanho da sua RAM. Então se tem 32GB é bom deixar uma margem, uns 34GB ou mais de Swap. Como meu PC é desktop em casa, não preciso de hibernação, só ativar ZRAM pros raros casos onde tiver um pico acima de 96GB (que é ultra raro). Fora que é mais fácil eu simplesmente subir pra 128GB de RAM se precisar muito. Swap pra compensar RAM só vale a pena em notebooks que já não tem espaço pra mais RAM de verdade.

2 - Por que Omarchy?

Como falei, já sou usuário de Arch faz uma década e não vejo nenhum repositório de pacotes maior e mais completo do que o AUR. O único outro repositório que compete, de fato, é do NixOS. Mas como Nix está descartado pro meu caso de uso, o AUR continua imbatível.

Arch tem Pacman como gerenciador de pacotes. Pra acessar o AUR precisa de um segundo gerenciador. Existem vários como os antigos Pacaur, Paru e vários outros. Mas o melhor, na minha opinião, é o Yay. Ele tem exatamente a mesma sintaxe que o Pacman e substitui o Pacman. Na prática só usamos Yay pra tudo.

Pra procurar pacotes por nome é só fazer yay -Ss spotify.

Pra remover pacotes é só fazer yay -Rns spotify.

Pra atualizar todos os pacotes do sistema é só fazer yay -Syu

Pra remover pacotes órfãos que sobram ao longo do tempo é só fazer sudo pacman -Rns $(pacman -Qdtq)

E esses são os comandos que eu mais uso 99% do tempo.

Eu já usei tudo que é tipo de desktop manager, seja GNOME (que tem mais comportamento de Mac), KDE (que tem mais comportamento de Windows pra power users), XFCE (que baseado em GTK e é mais leve), Cinnamon (também baseado em GTK), i3 (que é sistema de tiling windows), Sway (como i3, também tiling mas se não me engano já foi feito pensado em Wayland).

Na prática, todo mundo usa aplicativos de dois jeitos: janela em tela cheia ou 2 janelas verticais dividindo o monitor no meio (editor de um lado, navegador do outro), ou 3 janelas (um editor vertical ocupando metade do monitor, um navegador ocupando 1/4 e um terminal ocupando outro 1/4). Daí organizamos mais apps abertos em desktops virtuais/workspaces. Esse é o jeito mais fácil de trabalhar.

Significa que poder arrastar janelas flutuantes é perda de tempo. Eu prefiro que as janelas já abram dimensionadas num desses layouts que falei acima. Dá pra configurar GNOME ou KDE pra fazer isso. Mas tem cheiro de gambiarra. Em vez disso realmente é melhor usar i3 ou Sway.

Deixando as controvérsias de lado (sim, tenho um pouco de pé atrás com Wayland e gosto da existência de XLibre). Mas é um fato que X11 ficou pra trás e é uma arquitetura muito velha e complicada. Wayland de fato tem um “appeal” melhor, apesar de ter demorado bastante pra arredondar coisas básicas como compartilhamento de tela (OBS, Zoom). Mas já faz alguns anos que uso Wayland sem ter dores de cabeça. Hoje em dia eu diria que está bem estável. Eu já usava GNOME sobre Wayland faz muito tempo. Eu não deixo de usar coisas por ter pé atrás: com tecnologia vou ser sempre absolutamente promíscuo e usar tudo.

Sabendo que vou usar Wayland e sabendo que quero layouts automáticos de janelas, e não preciso de janelas flutuantes, o melhor é um desktop manager com sistema de tiling windows (tiles são “azulejos” e estamos falando de azulejos ficarem lado a lado e nunca um em cima do outro), que organize as janelas lado a lado de forma inteligente e automática.

Nesse caso só temos 2 opções: Sway ou Hyprland (qualquer uma das duas é boa). O Hyprland, instalado do zero, é totalmente pelado, não tem absolutamente nada. Precisamos configurar tudo através de arquivos em .config/hypr. É até simples, mas dá trabalho.

A única opção boa que se tinha pra ter um Hyprland pré-configurado e bem feito era o ML4W, que eu já usava. Mas agora temos o Omarchy que justamente instala e pré-configura tudo pra funcionar redondo no Hyprland. Essa é a melhor opção que temos hoje em dia.

Além de já configurar Hyprland pra funcionar com Waybar, Rofi e outros componentes, ele tem um sistema próprio pra trocar temas e estilos e deixar o sistema com o “look and feel” que quiser (e todos que já vem nele são super bonitos), mas também já instala coisas que eu uso faz tempo como Neovim com o pacote LazyVim (na minha opinião, o jeito mais fácil de fazer o Neovim não deixar nada a desejar comparado a um VS Code), Mise (a melhor forma de organizar ambientes de desenvolvimento pra conseguir ter múltiplas versões da sua linguagem de programação favorita).

Se estiver instalando uma distro do zero, as únicas duas coisas que precisa ter são Mise e LazyVim. Além de Docker e LazyDocker. É o suficiente pra começar um ambiente de desenvolvimento produtivo. E o Omarchy já trás tudo isso pré-configurado. Ninguém “precisa” do Omarchy, mas ele já trás tudo integrado e bonito. Então, pra que me dar ao trabalho de fazer tudo do zero pra ficar quase igual?

Além disso, isso é Linux. Não gostou de 1 dos componentes? Só trocar.

3 - Faça Backup

A grande maioria de tudo que tenho já fica no servidor remoto, meu NAS Synology de 100TB. Isso já facilita muito. Mesmo assim ainda tem bastante coisa localmente no meu PC, então a primeira coisa a fazer é copiar tudo pro NAS. Se não tiver um NAS, então um HD externo. Qualquer coisa server, o importante é garantir que não vai perder nada antes de instalar um novo OS do zero.

Não esquecer diretórios como .config ou .local. Melhor fazer um rsync -avz --progress .config /mnt/nas/backup/, por exemplo, e copiar tudo. Mesmo o que achar que não vai precisar. Melhor copiar a mais do que faltar coisa. Via de regra, o ideal é copiar tudo que estiver na sua $HOME pra um drive externo ou NAS.

Só pra garantir que não vou esquecer nada importante, também vou gravar uma lista de todos os pacotes que tenho instalado no meu sistema antigo:

yay -Q > pacotes.txt
flatpak list > flatpak.txt

Também garantir que não vou perder configs velhas de serviços que eu fiz no systemd então também copiar tudo de /etc/systemd/system. Vale também gravar coisas como /etc/fstab. Também não esquecer de fazer backup de suas chaves de SSH com tar cvfz ssh.tgz ~/.ssh!!

Se como eu, usava QEMU/Libvirt pra VMs, é bom salvar as configs das máquinas virtuais que usava. Normalmente a ferramenta pra gerenciar VMs é o virsh então eu só fiz:

sudo virsh list --all
sudo virsh dumpxml <vmname> > <vmname>.xml

Se eu quiser recriar as máquinas no futuro, já vai estar tudo no backup. No meu caso mantenho todos os drives virtuais no meu NAS, mas caso os seus estejam locais, também precisa salvar esses arquivos que ficam em /var/lib/libvirt/images/

rsync -avh --progress /var/lib/libvirt/images/ /backup/libvirt-images/

4 - É difícil instalar Arch?

Arch, menos que um Gentoo, sempre teve reputação de ser a distro Linux mais brutal pra um iniciante instalar. Isso não é mentira, mas a verdade é que Arch é simultaneamente a distro mais difícil e também a mais fácil.

Baixe a ISO oficial e grave num pen drive (em Windows, usando Rufus ou Balena Etcher). Agora aperte F12 (depende da sua BIOS) ou configure na BIOS direto pra bootar do pen drive. Fazendo isso ele carrega o live environment do Arch que é literalmente cair numa linha de comando. Sem mais nenhuma ajuda.

A partir deste ponto tem que seguir o Wiki de Instalação do excelente ArchWiki e aprender a instalar um Linux do absoluto zero usando somente linha de comando, passo a passo, na tentativa e erro (mais errando do que acertando) e, ao final, você vai ter um “feeling” muito melhor de como uma distro Linux funciona de verdade.

Eu não fiz video de Arch mas fiz videos de Slackware pra explicar como um gerenciador de pacotes funciona. Também fiz um video de Gentoo pra mostrar como uma distro que compila tudo do zero funciona. E fiz um video de como o Boot do Linux Funciona pra entender onde fica a kernel e como ela é estruturada. Mas não fiz video de Arch porque sempre deixei como exercício pra iniciantes.

O jeito manual é viável, mas se está acostumado a um instalador gráfico, como o Calamaris, que tem na maioria das distros mais populares como Ubuntu ou Fedora, você vai ficar totalmente perdido. Mas aqui vem o bônus: não precisa passar por tudo isso pra ter um Arch Linux na sua máquina.

Pra isso existe o archinstall.

Quando bootar o pen drive do Arch e cair na linha de comando, basta digitar archinstall e pronto, só seguir o passo a passo que ele dá - que eu considero ainda mais simples do que Calamaris - e ele vai instalar e configurar tudo de forma automática pra você, do mesmo jeito que é instalar Fedora ou qualquer outra distro. Sério, não é pra demorar mais que 15 minutos.

O archinstall tem esta cara:

Basta entrar em cada um dos ítens da esquerda e preencher suas escolhas. Configure coisas como layout de teclado (normalmente eu escolho ‘us-acentos’). Edite o hostname da sua máquina. Escolha “NetworkManager” em configuração de rede (ele vai configurar tanto ethernet quanto wifi pra você), adicionar suporte a Bluetooth e Audio (escolha “Pipewire”). Escolha o tipo “desktop” em vez de “minimal” pra já ter os principais pacotes necessários pra um desktop. Escolha a timezone (“America/Sao_Paulo” no meu caso).

Recomendo também escolher a opção de Hyprland acho que em Applications ou Adicional Packages. Ele já vai instalar o SDDM pra ter um login gráfico.

Só tem duas opções que precisa de mais atenção: pra bootloader, muitos vão ficar tentados a usar um Limine, que é mais moderno e leve. Mas eu recomendo ainda usar GRUB, já explico porque.

A segunda opção importante é “Disk Configuration”. Não se preocupe, diferente de fdisk, ele é super intuitivo. Basta escolher o drive correto onde quer instalar (se tiver dual boot, cuidado pra não apagar seu Windows). Daí deixe ele fazer o layout automático das partições (só edite manualmente se tiver alguma necessidade muito especial). O mais importante, escolha BTRFS em vez do tradicional ext4.

Todo Linux sempre formata suas partições Linux com ext4, que é o mais antigo, mais estável e mais bem documentado file system. Hoje em dia eu recomendo BTRFS, é muito mais moderno, mais seguro (tem sistemas de proteção contra corrupção melhores), usa menos espaço (aprenda sobre CoW - Copy on Write), e o principal: tem suporte a snapshots baratos (pense o Apple Time Machine, só que melhor). Tem a maioria das funcionalidades de um sistema de arquivos dedicado pra servidor de arquivos mas muito mais simples e intuitivo de usar do que o monstro que é o ZFS (não recomendo pra usuários normais).

Ele tem algumas necessidades de manutenção que é bom ler no Wiki pra aprender. Mas no geral é plug and play, instala e esquece. Nas próximas seções vou mostrar algumas coisas que precisa saber, mas vai por mim: escolha BTRFS.

Eu sei que o Omarchy 2.0 tem opção de uma ISO pré-configurada que imagino que seja o Arch normal com archinstall e já o Omarchy por cima tudo de uma só vez. Mas eu não sei se eles permitem essa escolha por isso preferi ir direto no Arch puro antes. No final o efeito é o mesmo. Depois comentem abaixo se a ISO do Omarchy também tem as mesmas opções. Só garanta que no final tenha BTRFS. O futuro você vai te agradecer.

5 - HOME separada

Como expliquei antes, eu usava um dos meus 4 NVMEs pra ser o drive de Linux. Mas agora liberei outro NVME e quero mover minha $HOME pra lá e ter 2 TB dedicado só pra user space.

Não vou explicar como particionar e formatar esse outro drive. É simples: basta usar fdisk ou depois instalar Gparted que é a versão gráfica da ferramenta parted que dá pra usar pela linha de comando. São várias opções. O importante é só zerar minha partição antiga Windows e formatar também com BTRFS.

Cada um vai ter nomes de dispositivos e partições diferentes do meu. Pra saber quais são os seus use o comando lsblk. Veja o meu exemplo:

No meu exemplo nvme1n1 é o drive de 1TB pra coisas aleatórias. nvme2n1 é meu novo Arch Linux. nvme0n1 é o drive de dual boot de Windows antigo. nvme3n1 é o drive de Steam que formatei com BTRFS pra virar meu novo drive de HOME.

Se não entendeu, HOME é o diretório /home/akitaonrails. Ele vai ficar num drive separado. Depois que o archinstall terminar e eu bootar no novo Linux, é só fazer o seguinte:

sudo mount -t btrfs /dev/nvme3n1p1 /mnt
sudo btrfs subvolume create /mnt/@home
rsync -aAXHv /home/ /mnt/@home/
sudo umount /mnt

Isso vai montar a nova partição, daí usamos o comando “btrfs” pra criar um novo sub-volume chamado “@home” (de novo, leia o Wiki de BTRFS pra entender conceitos como sub-volumes).

Os comandos acima criam o sub-volume e copiam tudo que estava na HOME antiga pra nova. Agora precisamos que, no boot, o /home seja montado nessa nova partição. Pra isso precisamos saber o UUID dessa partição:

~ ❯ sudo blkid /dev/nvme3n1p1
/dev/nvme3n1p1: LABEL="HOME" UUID="84e9a1b7-a30e-...

O comando blkid devolve o UUID único de cada partição e, com isso, podemos editar o arquivo /etc/fstab usando sudo nvim ou sudo nano ou o editor que preferir:

# /etc/fstab
...
# /dev/nvme2n1p2
# UUID=da3aea43-...-aeaf8c7224d7 /home      btrfs      rw,relatime,ssd,discard=async,space_cache=v2,subvol=/@home 0 0

# /dev/nvme3n1p1
UUID=84e9a1b7-...-7a6a17fd0395 /home      btrfs      rw,relatime,ssd,discard=async,space_cache=v2,subvol=/@home 0 0
...

Veja como comentei a linha antiga que montava o /home e adicionei a nova linha com o novo UUID. O resto é tudo igual. E é só isso, basta bootar e a partir de agora meu /home vai montar no novo drive. Agora eu tenho 2 TB dedicados só pros meus downloads lixo kkkkkk 🤣

Mas não só isso, também tenho espaço pra coisas grandes como imagens de Docker ou modelos de LLM, sem correr o risco de encher o drive do sistema operacional e correr o risco dele não bootar mais por falta de espaço - como já me aconteceu várias vezes no passado. Sempre lembre de dar manutenção em Docker e LLMs e apagar coisas velhas.

Falando nisso, BTRFS tem suporte a snapshots. E um dos erros básicos é esquecer que diretórios de Docker ou LLM podem acabar nos snapshots e ficar ocupando espaço sem você saber. Pra evitar isso é melhor marcar esses diretórios pra não entrarem nos snapshots. Pra isso temos que dizer ao BTRFS pra ignorar esses diretórios.

A forma correta é criando subvolumes separados pra eles. Pra isso vou montar aquela minha mesma partição no drive separado onde montei minha $HOME:

~ ❯ sudo mkdir /mnt/temp
~ ❯ sudo mount -o subvolid=5 -t btrfs /dev/nvme3n1p1 /mnt/temp

~ ❯ ls /mnt/temp
 @home   timeshift-btrfs

~ ❯ sudo btrfs subvolume create /mnt/temp/@docker
Create subvolume '/mnt/temp/@docker'

~ ❯ sudo btrfs subvolume create /mnt/temp/@ollama
Create subvolume '/mnt/temp/@ollama'

~ ❯ sudo umount /mnt/temp

Agora é só editar o /etc/fstab pra montar corretamente igual fizemos com a HOME:

# /etc/fstab
...
# /dev/nvme3n1p1
UUID=84e9a1b7-...-7a6a17fd0395 /home      btrfs      rw,relatime,ssd,discard=async,space_cache=v2,subvol=/@home 0 0
UUID=84e9a1b7-...-7a6a17fd0395 /var/lib/docker      btrfs      rw,relatime,ssd,discard=async,space_cache=v2,subvol=/@docker 0 0
UUID=84e9a1b7-...-7a6a17fd0395 /var/lib/ollama      btrfs      rw,relatime,ssd,discard=async,space_cache=v2,subvol=/@ollama 0 0
...

Pronto, subvolumes limpos. Mais importante no meu caso: movi diretórios que tem tendência a crescer sem controle pra fora da partição do sistema operacional, tornando mais difícil acabar com um sistema inacessível por causa de falta de espaço. Faça a mesma coisa com outros diretórios parecidos com coisas como Kubernetes por exemplo. Qualquer coisa que fique baixando arquivos grandes, como imagens de sistemas.

Agora é só montar e trazer as coisas de volta:

# toda vez que edita o fstab, rode isso:
sudo systemctl daemon-reload

# crie os mount points
sudo mkdir /var/lib/docker
sudo mkdir /var/lib/ollama

# monte
sudo mount /var/lib/docker
sudo mount /var/lib/ollama

# copiar o conteúdo do diretório antigo de volta
sudo rsync -aHAX --inplace /var/lib/docker.old/ /var/lib/docker/
sudo systemctl start docker

Além de gerenciamento de espaço, qual a outra vantagem de fazer subvolumes separados? Porque a próxima seção vai ser pra tornar o sistema ainda mais robusto adicionando capacidade de snapshots e rollback pra snapshots do passado. E o ideal é tirar arquivos gigantes de snapshots que vão ficar no passado. Imagens de Docker são fáceis de recuperar: só dar docker pull de novo, não precisa fazer backup.

6 - Instalar Omarchy

Essa é a parte mais fácil. Quando terminar de instalar com archinstall, se escolheu a opção de Hyprland, vai aparecer o SDDM pra fazer login. E quando entrar você vai ficar chocado com quão cru é o Hyprland. Não dá pra fazer basicamente nada.

Pra isso não virar um dia inteiro de configuração na mão, usaremos o Omarchy. Clique “Super Enter” pra abrir o terminal e não ligue pra quão feio as coisas estão agora. Vai melhorar.

No terminal só faça isso:

curl -fsSL https://omarchy.org/install | bash

Só seguir as instruções na tela e deixar ele fazer o resto. E pronto, acabou, não tem próximo passo.

Recomendo MUITO que leia o MANUAL ONLINE DO OMARCHY que o DHH fez. É muito limpo, simples e direto. Todas as combinações de tecla, por exemplo, estão na seção HOTKEYS. Gaste uma hora lendo o básico pra conseguir operar. Mas a essa altura você já tem praticamente tudo que precisa: Alacritty como terminal, Chromium como navegador (pode instalar Brave se preferir, como é meu caso).

“Super Alt Space” abre o menu principal do Omarchy. “Super Space” abre o Rofi pra digitar o nome do app que quer abrir. “Super Enter” abre o terminal. “Super B” abre o navegador e assim por diante.

7 - Customizando Omarchy

O Omarchy é um Hyprland customizado. Podemos editar o que quisermos diretamente em ~/.config/hypr. E como eu estava acostumado com ML4W, resolvi mexer um pouco pra ficar bom pro meu setup. Seu setup vai variar dependendo das suas necessidades.

Logo que terminei de instalar Omarchy e tentei usar Gparted pra particionar aquele meu segundo NVME pra HOME, ele deu problema de autenticação. Não lembro se esta foi a solução mas é bom garantir que tenha Polkit instalado:

# make sure polkit + agent exist
sudo pacman -S --needed polkit polkit-gnome xorg-xhost

# Hyprland: export full env to systemd user bus once
dbus-update-activation-environment --systemd --all

Voltando, a primeira coisa que eu preciso resolver é que eu tenho 2 monitores. Um Asus 32" 1440p 144fps como principal e outro Samsung 24" 4K 60fps na vertical do lado esquerdo. A forma de configurar isso no Hyprland é editando um arquivo como ~/.config/hypr/monitors.conf que normalmente é carregado pelo ~/.config/hypr/hyprland.conf.

Em vez de fazer isso manualmente, prefiro instalar:

yay -S nwg-displays

Aqui eu configuro coisas como transform 90 graus pra girar o monitor vertical, scaling de resolução, suporte a 10-bits de cor, etc.

Ele vai salvar dois arquivos: ~/.config/monitors.conf e ~/.config/workspaces.conf. O Omarchy não carrega esse segundo arquivo então temos que editar em ~/.config/hypr/hyprland.conf pra ficar assim:

...
# Change your own setup in these files (and overwrite any settings from defaults!)
source = ~/.config/hypr/monitors.conf
source = ~/.config/hypr/workspaces.conf`
...

Já aproveitei pra adicionar algumas configurações extras nesse arquivo:

...
# animation
animations {
  enabled = yes
  bezier = easeOutQuint, 0.23, 1, 0.32, 1
  animation = workspaces, 1, 4, easeOutQuint, slide
  # optional extras:
  animation = specialWorkspace, 1, 4, easeOutQuint, slide
  animation = windows, 1, 4, easeOutQuint, popin 80%
  animation = fade, 1, 4, easeOutQuint
}

xwayland {
    force_zero_scaling = false # careful with mixing scaling wayland and x11
}

input {
  numlock_by_default = true
}

# dialogs/splash/utility ONLY
windowrulev2 = float,  xwayland:1, windowtype:^(dialog|splash|utility)$
windowrulev2 = center, xwayland:1, windowtype:^(dialog|splash|utility)$

# never center menus/tooltips
windowrulev2 = tile,   xwayland:1, windowtype:^(popup_menu|dropdown_menu|tooltip)$

Tem gente que não gosta mas eu gosto de ter uma animação rápida quando mudo de um workspace pra outro, por isso adicionei o bloco animations.

Quando se usa aplicativos feitos pra X11, eles vão rodar em cima do XWayland. Uma coisa chata é que alguns deles abrem “dialog boxes”, que são janelas flutuantes. E eles podem acabar em lugares difíceis de clicar, especialmente num setup com múltiplos monitores. Por isso adicionei blocos como xwayland e regras windowrulev2 pra forçar esses dialog boxes a sempre aparecerem centralizados na tela.

FInalmente, eu tenho um teclado numpad da 8bitdo conectado via Bluetooth, mas ele não liga com numlock carregado. Pra corrigir isso tem esse bloco input.

Voltando ao layout de monitor. Depois que o nwg-displays gerou os arquivos, ainda precisei modificar um pouco por meu caso, assim:

# ~/.config/monitors.conf
# Generated by nwg-displays on 2025-08-28 at 14:30:17. Do not edit manually.

#monitor=HDMI-A-3,2560x1440@143.97,1080x407,1.25,bitdepth,10
#monitor=DP-5,3840x2160@60.0,0x0,1.875,bitdepth,10
#monitor=DP-5,transform,1
#monitor=DP-1,0x0@60.0,-1x-1,1.0
#monitor=DP-1,disable

monitor=HDMI-A-3,2560x1440@143.97,2813x948,1.0,bitdepth,10
monitor=DP-5,3840x2160@60.0,1373x350,1.5,bitdepth,10
monitor=DP-5,transform,1
monitor = DP-1,disable

O arquivo de monitor não precisei mexer nada, na real, só lembrar de desabilitar esse DP-1 que aparece no meu monitor principal (acho que é a DisplayPort dele, mas eu uso HDMI, então tem que desabilitar a DP-1).

# ~/.config/workspaces.conf
# Generated by nwg-displays on 2025-08-28 at 13:07:02. Do not edit manually.

workspace=5,monitor:DP-5,persistent:true
workspace=1,monitor:HDMI-A-3,persistent:true
workspace=2,monitor:HDMI-A-3,persistent:true
workspace=3,monitor:HDMI-A-3,persistent:true
workspace=4,monitor:HDMI-A-3,persistent:true

Esta também não precisei mudar muito, no próprio nwg-displays eu disse quais workspaces eu quero em cada monitor. Na minha preferência pessoal prefiro deixar o monitor vertical somente com a workspace 5 e os outros no monitor principal. A diferença aqui foi que adicionei essas opções persistent:true em todas, pra garantir que vai tudo funcionar direito com as workspaces “pinadas” nos lugares corretos. Workspaces em Hyprland são bem dinâmicos, vale ler a documentação depois, caso queira casos mais complicados.

Isso resolve meu setup de dois monitors do jeito que eu prefiro. Experimente mexer em coisas como scaling até ficar tudo ok pro seu setup.

Na sequência eu precisava resolver as hotkeys (key bindings). Eu estou acostumado com algumas combinações que vinha no ML4W então resolvi copiar de lá direto em ~/.config/hypr/bindings.conf. Primeiro, trocar o chromium pelo Brave:

# Application bindings
$terminal = uwsm app -- alacritty
$browser = brave # omarchy-launch-browser
...

Daí adicionei um tanto de binds no final do mesmo arquivo:

unbind = SUPER, V
bind = SUPER, V, swapsplit
bind = SUPER, M, fullscreen, 1                                                           # Maximize Window
bind = SUPER, T, togglefloating                                                          # Toggle active windows into floating mode
bind = SUPER SHIFT, right, resizeactive, 100 0                                           # Increase window width with keyboard
bind = SUPER SHIFT, left, resizeactive, -100 0                                           # Reduce window width with keyboard
bind = SUPER SHIFT, down, resizeactive, 0 100                                            # Increase window height with keyboard
bind = SUPER SHIFT, up, resizeactive, 0 -100                                             # Reduce window height with keyboard

# Display
bind = SUPER SHIFT, mouse_down, exec, hyprctl keyword cursor:zoom_factor $(awk "BEGIN {print $(hyprctl getoption cursor:zoom_factor | grep 'float:' | awk '{print $2}') + 0.5}") # Increase display zoom
bind = SUPER SHIFT, mouse_up, exec, hyprctl keyword cursor:zoom_factor $(awk "BEGIN {print $(hyprctl getoption cursor:zoom_factor | grep 'float:' | awk '{print $2}') - 0.5}") # Decrease display zoom
bind = SUPER SHIFT, Z, exec, hyprctl keyword cursor:zoom_factor 1 # Reset display zoom

# Workspaces
bind = SUPER, 1, workspace, 1 on HDMI-A-3 # Open workspace 1
bind = SUPER, 2, workspace, 2 on HDMI-A-3  # Open workspace 2
bind = SUPER, 3, workspace, 3 on HDMI-A-3 # Open workspace 3
bind = SUPER, 4, workspace, 4 on HDMI-A-3 # Open workspace 4
bind = SUPER, 5, workspace, 5 on DP-5 # Open workspace 5

bind = SUPER SHIFT, 1, movetoworkspace, 1  # Move active window to workspace 1
bind = SUPER SHIFT, 2, movetoworkspace, 2  # Move active window to workspace 2
bind = SUPER SHIFT, 3, movetoworkspace, 3  # Move active window to workspace 3
bind = SUPER SHIFT, 4, movetoworkspace, 4  # Move active window to workspace 4
bind = SUPER SHIFT, 5, movetoworkspace, 5  # Move active window to workspace 5

bind = SUPER, Tab, workspace, m+1       # Open next workspace
bind = SUPER SHIFT, Tab, workspace, m-1 # Open previous workspace

bind = SUPER CTRL, 1, exec, $HOME/.config/hypr/moveTo.sh 1  # Move all windows to workspace 1
bind = SUPER CTRL, 2, exec, $HOME/.config/hypr/moveTo.sh 2  # Move all windows to workspace 2
bind = SUPER CTRL, 3, exec, $HOME/.config/hypr/moveTo.sh 3  # Move all windows to workspace 3
bind = SUPER CTRL, 4, exec, $HOME/.config/hypr/moveTo.sh 4  # Move all windows to workspace 4
bind = SUPER CTRL, 5, exec, $HOME/.config/hypr/moveTo.sh 5  # Move all windows to workspace 5

Note que o último bloco de scripts precisa de um script pra mover todas as janelas de uma só vez pra outro workspace. Eu copiei este moveTo.sh do GitHub do ML4W e coloquei em ~/.config/hypr direto. Não esquecer de dar permissão de execução com chmod +x moveTo.sh depois. Os vários de workspace abaixo é como eu prefiro mover workspaces e mover apps pra diferentes workspaces.

Omarchy já vem com “SUPER J” pra mudar a orientação das janelas, por exemplo, se está duas janelas na horizontal um em cima do outro, com SUPER J eles ficam verticais, mas faltava o “SUPER V” que adicionei pra “swapsplit” que é trocar as janelas de lugar.

Eu também gosto de “SUPER M” pra temporariamente fazer uma das janelas ficar em tela cheia, e “SUPER T” pra temporariamente fazer uma janela ficar flutuante (como uma calculadora, por exemplo). Tive que dar unbind no SUPER M anterior que abria o Spotify, mas eu quase não uso Spotify no desktop então não preciso dela. Quando quero abrir esse app, vou no SUPER SPACE pra abrir o Rofi e escrevo lá.

Se tiver dúvidas sobre as combinações padrão, o Omarchy tem “SUPER K” pra abrir uma janela com uma ajuda pra todas.

Ainda não modifiquei combinações pra aplicativos específicos. Os que vem no Omarchy já são muito úteis como SUPER A pra abrir o ChatGPT como se fosse um app separado ou SUPER CTRL A pra abrir o Grok numa janela separada. SUPER O pra abrir o Obsidian também é muito útil pra mim. Recomendo brincar com esses binds pra fazer bindings específicos e, de novo, ler o manual pra aprender tudo mais que já vem nele. Mas até aqui é o suficiente pra deixar o Hyprland do jeito que eu gosto de usar.

8 - Timeshift, Snapshots e GRUB

Lembram que eu falei pra escolher GRUB no archinstall? É pra agora. O objetivo: deixar o sistema fazer snapshots periódicos do sistema e, caso instale algum pacote corrompido ou faça coisas no seu sistema que impeçam ele de bootar, em vez de ter que recorrer a um pendrive pra tentar bootar e diagnosticar o erro, é mais fácil só bootar, escolher um snapshot logo antes da operação destrutiva e voltar intacto.

Antes de prosseguir, um ajuste que acho importante: meu monitor 4K faz o GRUB ficar com letras pequenas demais pra eu conseguir ler. Prefiro letras maiores. Felizmente o GRUB usa fontes bitmap então posso usar qualquer uma. Eu fiz o seguinte:

sudo grub-mkfont -s 48 -o /boot/grub/fonts/caskaydia48.pf2 /usr/share/fonts/TTF/CaskaydiaMonoNerdFont-Regular.ttf

Isso vai gerar uma fonte no formato que o GRUB consegue carregar. Escolha qualquer uma que gostar, o Omarchy já pré-instala várias muito boas como as da JetBrains. Se tamanho 48 for muito grande, diminua pra 32, experimente até ficar do jeito que gosta.

Daí é só editar /etc/default/grub pra, no final ter esta linha:

GRUB_FONT=/boot/grub/fonts/caskaydia48.pf2

E agora é só regerar o bootloader:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Toda vez que o yay -Syu trouxer atualização de kernel ou drivers, o GRUB vai ser regerado com a mesma fonte. Olha como ficou pra mim, acho que está bem melhor (isso é um monitor 4K):

Agora a razão toda pra ter escolhido GRUB: permitir escolher snapshots de BTRFS pra poder bootar no passado, antes de alguma operação destrutiva, como mostra na foto acima. Pra isso precisamos do seguinte:

pacman -S timeshift grub-btrfs
yay -S timeshift-autosnap
systemctl enable --now grub-btrfs.service

Pronto. A partir de agora, toda vez que o GRUB for reconstruído, vai ter uma nova opção pra escolher snapshots. Só precisamos criar esses snapshots automaticamente e, pra isso, temos o app Timeshift. Abra e siga o passo a passo dele. O importante é escolher a opção de BTRFS (sim, dá pra usar RSYNC se estiver em ext4, mas isso ocupa muito espaço, porque ele vai literalmente ficar fazendo cópias dos arquivos do seu sistema inteiro. A beleza de BTRFS é que snapshots dele não duplicam arquivos).

Eu deixo ele fazendo snapshots e acumulando versões das últimas horas, últimos dias, últimas semanas e meses. Se lá na frente eu lembrar “puuuuts, tinha aquele arquivo que eu apaguei mês passado mas agora eu preciso” Basta abrir o Timeshift e explorar um snapshot do mês passado. Igual povo de Mac faz com Time Machine, mas ocupando quase nada de espaço extra.

Além disso, todo upgrade de pacotes vai gerar um snapshot antes. Assim, se por acaso vier um pacote corrompido ou que quebre alguma configuração sua importante, dá pra voltar exatamente como era antes da atualização. E se quebrar de forma catastrófica, onde seu Linux não boota mais, basta ir no menu extra do GRUB e bootar do snapshot anterior, que funcionava. E tudo volta igualzinho como estava antes.

Não existe nada mais importante pro seu sistema do ter snapshots automáticos e que não ocupam quase nada de espaço extra. Só isso já torna o BTRFS superior a qualquer outra alternativa.

Isso não substitui Backup externo!!

Esse rollback e capacidade de recuperar coisas de forma fácil é bom pra acidentes do dia a dia. Mas digamos que seu NVME quebre de alguma forma, ou seu PC quebre de alguma forma. Pra isso servem backups externos (seja HD externo, seja NAS, seja Cloud). Você quer ter certeza que, numa situação catastrófica, ainda seja possível recuperar seus arquivos.

Eu tenho todas as camadas de proteção: snapshots locais via BTRFS e Timeshift, backups feitos remotamente pro meu NAS, e backup de partes mais importantes do meu NAS na Amazon Glacier que, diferente de Amazon S3 é pra guardar backup, onde o custo de armazenamento é ultra baixo mas o custo de transferência é mais alto (S3 o armazenamento é mais caro mas a transferência é barata, por isso serve pra servir assets de websites).

Eu gosto de estar preparado pra, caso minha casa pegue fogo, eu não perca nada importante.

9 - NFS no NAS

Falando em NAS, uma coisa que configurei diferente - já que uso primariamente Linux em vez de Windows - foi habilitar servidor de NFS.

Mas cuidado que alguns NAS tem uma característica que pode incomodar: o seu usuário no NAS vai ter UID e GID diferente de 1000!

Quando se cria um usuário em qualquer Linux, o padrão é atribuir o UID 1000 pro primeiro usuário, 1001 pro segundo e assim por diante. Mas como no NAS Synology o primeiro usuário recebe UID 1026, se eu montar com NFS (que transparece as permissões de UNIX), vou ter problemas de autorização.

Existem duas soluções: tentar mudar o UID no NAS de 1026 pra ser 1000. Eu tentei isso e já adianto que é perda de tempo, você pode acabar quebrando as configurações do NAS de forma catastrófica.

É muito mais fácil mudar o usuário do seu novo Linux local pra ser 1026 e pronto. É bem fácil.

Primeiro, precisamos deslogar e sair do Hyprland e voltar pra tela de login do SDDM. Daí precisamos mudar pra outro TTY com CTRL + ALT + F3 (pra ir pra tty3, por exemplo). De lá temos que fazer login como root.

Agora rodamos: systemctl isolate multi-user.target pra rodar em modo de recuperação isolado, onde nenhum outro usuário tem processos rodando. Já que vamos mexer no usuário, ele não pode estar ativo.

usermod -u 1026 akitaonrails
groupmod -g 1026 akitaonrails
chown -R 1026:1026 /home/akitaonrails

Com os comandos acima mudamos de 1000 pra 1026 e acertamos as permissões nos arquivos locais pra refletir essa mudança. Agora sim, podemos editar o /etc/fstab pra montar os diretórios compartilhados no NAS com NFS:

# NFS
192.168.0.x:/volume1/GIGACHAD /mnt/gigachad nfs4 _netdev,noauto,nofail,bg,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.after=network-online.target,x-systemd.idle-timeout=60s,noatime,nodiratime,async,rsize=65536,wsize=65536,actimeo=1  0 0
192.168.0.x:/volume1/TERACHAD /mnt/terachad nfs4 _netdev,noauto,nofail,bg,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.after=network-online.target,x-systemd.idle-timeout=60s,noatime,nodiratime,async,rsize=65536,wsize=65536,actimeo=1  0 0

Não esquecer de criar os mount points:

mkdir /mnt/gigachad
mkdir /mnt/terachad

Pronto, só rebootar e tudo vai funcionar corretamente. As permissões dos arquivos no NAS - que estão pro UID 1026 e GID 1026 - vão ser acessíveis pro usuário local sem problemas.

10 - Utilitários

Aqui são as últimas dicas pequenas pra ficar tudo num lugar só. A primeira é substituir o comando ls pelo eza que oferece uma cara mais bonita, com ícones e tudo mais, assim:

Só fazer yay -S eza e adicionar isto no seu .zshrc ou .bashrc:

alias ls='eza --icons --color=auto --group-directories-first'
alias ll='eza -l --icons --color=auto --group-directories-first'
alias la='eza -la --icons --color=auto --group-directories-first'

Segunda dica é instalar Atuin. Pra quem mexe com infra, isso é extremamente importante: backup de toda o histórico de comandos que você usou no seu terminal até hoje.

Instale com yay -S atuin e faça:

atuin login
atuin sync

Leia o site oficial, mas primeiro precisa criar uma conta e uma chave de encriptação secreta - sim, você pode rodar localmente num servidor na sua casa, mas a opção cloud deles é bem cômoda e segura porque fica toda encriptada, então não tem problema se subir senhas do seu histórico.

Só precisa colocar isso no seu .zshrc:

export ATUIN_NOBIND=true
eval "$(atuin init zsh)"
bindkey "^R" atuin-search

# incremental history search with arrow keys
bindkey "^[[A" history-beginning-search-backward
bindkey "^[[B" history-beginning-search-forward]]

Se estiver usando ZSH, o auto-complete dele vai funcionar normalmente mas, se digitar CTRL+R, vai abrir o histórico do Atuin. Ele vai guardar todos os seus comandos num SQLite e sincronizar. Assim você pode sincronizar diversas máquinas e servidores que usa no dia-a-dia ou, como no meu caso, recuperar o histórico todo numa nova instalação.

E pra ficar melhor, podemos configurar ele pra auto-sincronizar:

mkdir -p ~/.config/atuin
sed -i 's/^#\?auto_sync.*/auto_sync = true/; s/^#\?sync_frequency.*/sync_frequency = "30m"/' ~/.config/atuin/config.toml 2>/dev/null || \
printf 'auto_sync = true\nsync_frequency = "30m"\n' >> ~/.config/atuin/config.toml

Terceira dica: como temos Docker já instalado e configurado, eu gosto de usar o SGPT na linha de comando pra quando quero lembrar a sintaxe de algum comando que uso pouco, em vez de abrir um app ou navegador. Basta adicionar isto no meu .zshrc:

export OPENROUTER_API_KEY="sk-or-v1-8b8...17"
export OPENAI_API_KEY="sk-or-v1-db...f3"
export OPENAI_API_BASE="https://openrouter.ai/api/v1"

alias sgpt='docker run --rm -e OPENAI_API_BASE=${OPENAI_API_BASE} -e OPENAI_API_KEY=${OPENROUTER_API_KEY} ghcr.io/tbckr/sgpt:latest txt '

Eu uso OpenRouter pra ter acesso a diferentes LLMs comerciais numa única API, mas você pode só usar sua chave da OpenAI. Feito isso eu usaria no terminal parecido com isto:

~ ❯ sgpt "what is the pacman command in Arch to find out if a particular file came from an installed package?"
To find out if a particular file came from an installed package in Arch Linux, you can use the following pacman command:

``bash
pacman -Qo /path/to/file
``

Replace "/path/to/file" with the actual path to the file you want to check. This command will show the package which owns the file, or report that the file does not belong to any package if that is the case.

Se quiser, ele suporta sessões, então vai lembrar da conversa a cada nova chamada. Leia o Github do projeto.

Como fiz backup do meu ~/.config antigo, coisas como abas abertas do meu navegador Brave abriram normalmente nessa nova instalação de Omarchy e posso continuar fazendo minhas coisas exatamente do ponto onde parei. Não perdi nada. Mesma coisa vale pra todos os outros apps como emails que faço backup local via Thunderbird. Não preciso mandar baixar tudo de novo.

Se como eu, você tem vários dispositivos de saída de áudio, é possível que logo que terminar de instalar note que parece que não tem som. Mas não é um problema porque pode ser só que a saída está apontando pro dispositivo errado ou no perfil errado. Use SUPER ALT SPACE pra abrir o menu do Omarchy, escolha SETUP e AUDIO pra abrir esse programa que é em modo texto (eu gosto de programas em modo texto).

No meu caso, uso um DAC Topping D70 pra processar meu áudio e o perfil “Default” não funciona mas mudando pra “Pro Audio” funcionou. Também cuidado que tem configuração de volume global e controle individual de volume por programa. No geral, graças ao Pipewire, tudo deve funcionar normalmente.

Eu testei apps como Discord, Blender, Bambu Studio, VLC e tudo funcionando perfeitamente bem. Só VLC que precisei instalar os codecs de um pacote separado:

yay -S extra/vlc-plugin-ffmpeg

Blender também, o melhor é instalar deste pacote:

yay -S blender-bin

Se usar o pacote “blender” normal, alguns add-ons dele não instalam direito. Eu tive esse problema com MACHIN3Tools e MESHMachine, por exemplo.

Falando em Blender, ele é um app X11. Wayland roda aplicativos X11 usando uma camada adaptadora chamada XWayland. Eu tive vários problemas com posicionamento de menus e dialog boxes, mesmo adicionando windowrule. Uma coisa que sei lá porque funcionou foi instalar Blender e Bambu Studio via Flatpak:

yay -S flatpak
flatpak install org.blender.Blender
flatpak install com.bambulab.BambuStudio

Finalmente, se você é novo em LazyVim, não esqueça de rodar o comando :LazyExtras pra instalar os plugins extras pras suas linguagens favoritas, como LSP, Linter, syntax highlight, snippets e mais. O LazyVim puro já é completo mas sem suporte a muitas linguagens pra não ficar pesado desnecessariamente, você precisa instalar separado depois.

Também aprenda a usar Mise-en-place. No menu do Omarchy tem uma opção pra instalar suporte a várias linguagens e ele vai usar Mise, que é a forma correta de gerenciar suas linguagens.

Mise é muito fácil, no geral, de dentro do diretório do seu projeto, é só fazer algo como:

mise use ruby@3.4.3

Com isso, só dentro do seu projeto vai estar disponível Ruby 3.4.3, mas fora pode estar outra versão global. Não esquecer de ativar no seu .zshrc:

eval "$(mise activate zsh)"

Impressões e Conclusão

Comparado ao meu Manjaro antigo, muita coisa que não precisei configurar mais. Por exemplo, por causa do tanto de espaço que Docker e LLMs precisavam, eu tinha configurado um drive iSCSI no meu NAS só pra isso. Mas como eu liberei 2 TB de NVME local, não preciso mais lidar com isso, basta usar os novos sub-volumes de BTRFS que criei acima.

Também não preciso mais configurar QEMU/Libvirt porque não preciso mais usar Windows junto com Linux lado a lado. Mantive o NVME com as partições Windows e posso fazer dual boot pra ela se precisar muito de alguma coisa. No geral nunca preciso, então é menos uma configuração complicada.

Eu passei meses usando apps via Flatpak, com o intuito de ser mais seguro e isolado do sistema. É como rodar apps via Docker. Mas é chato demais. Por ser isolado significa que ele não obedece os temas do sistema, no final sou obrigado a ficar abrindo permissões pros apps. E se for pra ficar abrindo, é mais fácil instalar nativamente via yay e tudo funciona perfeitamente.

Acho que isso completa minhas anotações de tudo que precisei fazer pra deixar o Omarchy exatamente do jeito que eu gosto. Como falei repetidas vezes, o que funciona pra mim não quer dizer que vai funcionar pra você. Pra isso existe documentações como o ArchWiki que é “O” melhor lugar pra aprender tudo que sobre Linux. Use e abuse dessa documentação.

Como podem ver, não teve tanta coisa assim que eu customizei no Omarchy, por isso eu gosto dele: 95% do caminho ele já fez pra mim, só precisei mexer em poucos ajustes pra deixar do jeito que eu preciso. E agora sem o tanto de lixo que foi acumulando no meu Manjaro velho. Recomendo que todo mundo instale Omarchy como primeiro Linux e aprenda a usar de verdade.

Em Linux, isso é um enorme pé no saco, porque o protocolo SMB (feito pra Windows), não trás direito conceitos como ownership (chown) ou permissões (chmod). Ele não entende coisas como permissão de execução (tudo é executável). Pra coisas simples como diretório de Downloads, Videos, Fotos, meio que não importa.

Mas digamos que queira editar código fonte em projetos com Git. Vai ser um pesadelo, porque o SMB sobrescreve as permissões, independente do que está por baixo, e toda vez vai conflitar com o Git, que vai achar que arquivos foram modificados (mudar permissões é uma mudança que ele guarda), e vai ficar mandando você fazer commit disso, e isso vai sujar todo seu repositório (nunca use projetos Git em SMB na rede).

Em vez disso, eu estou em Linux, meu NAS é Linux. O certo é usar um protocolo de Linux. Esse protocolo é NFS e eu mostrei como configurei isso no outro post da semana passada.

Enfim, estou usando NFS e com muito menos dor de cabeça de permissões em arquivos. Mas aí tive outro problema: se viu meus últimos posts, viu que fiquei experimentando MUITO com Docker. Gerando imagens novas como se não houvesse amanhã. Rapidamente, meu NVME local de 2 TB encheu e começou a reclamar de falta de espaço. Então pensei, “Ah, é só mover o diretório de armazenamento do Docker, o /var/lib/docker, pra um diretório montado com NFS no meu NAS”

Pra fazer isso é muito fácil:

sudo mkdir -p /mnt/nfs/docker
sudo chown root:docker /mnt/nfs/docker
sudo chmod 771       /mnt/nfs/docker

Isso é pra criar um novo diretório dentro do meu NAS e aplicar as permissões corretas.

sudo systemctl stop docker
sudo mv /var/lib/docker /mnt/nfs/docker
# sudo rm -Rf /var/lib/docker (isso vai liberar tudo pra mim)
sudo ln -s /mnt/nfs/docker /var/lib/docker

Isso vai liberar todo o espaço ocupado. Não preciso me preocupar com as imagens porque eu posso recriar tudo dos meus Dockerfiles. E não preciso me preocupar com volumes porque não tinha nada importante que não seja montado por fora, em diretórios de verdade. Regra: nunca guarde coisas importantes em volumes de Docker. É uma má prática!

# editar /etc/docker/daemon.json
{
  "data-root": "/mnt/nfs/docker"
}

sudo systemctl start docker

Pronto, isso muda a configuração de /var/lib/docker pro novo /mnt/nfs/docker e depois de reiniciar o serviço, ele vai passar a gravar tudo lá. Então acabou o post né?

É até aqui que a maioria vai. Mas se você trabalhar 2 minutos nessa configuração, vai sentir algo MUITO errado.

Eu tentei fazer build de uma nova imagem. E estava demorando ABSURDO. Acontece que NFS é sim, mais rápido que SMB, mas ambos foram feitos pra servidores de arquivos, e não pra sistemas operacionais. Faz muita diferença.

Esses protocolos são FILE-BASED, toda operação é baseada em arquivos. E isso é extremamente ineficiente.

Se assistiu meus videos sobre sistemas de arquivos, já deveria saber que eles são BLOCK-LEVEL. No nível do sistema de arquivos, se trabalha com blocos de bytes, de tamanho fixo, organizadas em alguma variação de árvores B-TREE (depende do sistema de arquivos). As operações são em nível de bloco. Arquivos são abstrações pra coleções de blocos.

Quando se faz um chmod -R que é mudança de permissão recursiva, dentro do build do Dockerfile, por exemplo, mesmo uma árvore vazia vai causar recursão em cada entrada lá dentro, seja arquivos escondidos, ACLs, etc. E ele precisa pesquisar todas as permissões de tudo lá dentro. Isso custa tempo de rede (porque NFS/SMB são protocolos de rede).

Isso causa latência. Cada permissão de cada arquivo é uma chamada remota individual, uma RPC call. Mesmo na rede mais rápida, como a minha de 10Gbps, mesmo que cada RPC seja de menos de 0.1 ms, rapidamente vai dar gargalo. E é isso mesmo que começou a acontecer.

Eu usei sudo nfsiostat 1 10 pra checar. Tava dando isso:

write: ops/s=2417  kB/s≈295 MiB/s  avg exe=106 ms  avg queue=102 ms

Média de 106 ms pra cada RPC. Isso é uma eternidade. Tempo médio na fila de espera de 102 ms. Mesmo que que eu faça só 100 chamadas RPC, vai custar mais de 10 segundos só de latência. E num build de sistema operacional, instalando pacotes com milhares de arquivos, isso vai custar literamente uma eternidade. Não é viável usar Docker build em NFS/SMB.

iSCSI

Obviamente eu não sou o primeiro a esbarrar nesse problema e fazer a besteira de usar um protocolo file-based pra serviços de alto volume de alterações de arquivos como cache de Docker.

O certo é criar um drive virtual iSCSI no meu NAS. Se nunca ouviu falar, SCSI é um protocolo avançado pra drives. Em PCs baratos dos anos 90 e 2000 se usava IDE/ATA, que é um protocolo mais simples e mais barato. Mas os primeiros Mac e workstations UNIX dos anos 80 e 90 sempre usaram SCSI, que era muito superior.

Ele era assíncrono, com controle de fila. Dava pra mandar dezenas de comandos de uma só vez e o protocolo era inteligente de reordenar esses comandos pra ter mais eficiência (por exemplo, ignorar leitura de um arquivo se antes veio um comando de deletar). IDE era bloqueante, só um comando por vez. Um único BUS de SCSI conseguia ter até 16 dispositivos. Parallel ATA era 2 por cabo. Ridículo. SCSI tinha sistemas avançados de recuperação de erros e relatórios. Tinha recursos “enterprise” pra hot-swap, gerenciamento de energia, comportamentos de timeout, recuperação, clustering, etc. E além de tudo era agnóstico ao meio de transporte, podia ser fibra ótica, SAS ou até mesmo iSCSI que é SCSI sobre Ethernet, que é o que vamos usar.

IDE/ATA não tinha nada disso. Era o protocolo de discos de PC pobre. Workstation de verdade, SUN, IRIX, Silicon Graphics, Macs, usavam SCSI.

Mais importante iSCSI é um protocolo de blocos, e não de arquivos. Enfim, isso varia de gerenciador de NAS, mas no caso do Synology DSM, que é o que eu uso, ele tem um aplicativo chamado SAN Manager, que permite criar um drive iSCSI:

Só seguir o wizard, dar nome, escolher o tamanho, habilitar CHAP se precisar de segurança extra (eu não preciso, estou numa rede local controlada). Isso vai criar o drive iSCSI (pense como se fosse um drive USB remoto) e um LUN (Logical Unit Number). Um LUN é simplesmente um de muitos potenciais “discos virtuais” que um target pode apresentar. LUN é como um slot numerado no array de storage de um target. Target é um servidor de discos. Num SAN você pode ter vários discos virtuais e a forma de organizar isso é com LUNs. No nosso caso não interessa muito saber detalhes de LUN.

Demora um pouco, mas ao terminar é só voltar pro meu Manjaro Linux e fazer:

yay -S open-iscsi
sudo systemctl enable --now iscsi 

Isso sobe o serviço pra iniciar automaticamente em todo boot. Agora pra descobrir meu drive na rede:

❯ sudo iscsiadm -m discovery -t sendtargets -p 192.168.0.xx
192.168.0.xx:3260,1 iqn.2000-01.com.synology:TERACHAD.docker.7af6e...
[2804:1b3:....:fe18:3f7d]:3260,1 iqn.2000-01.com.synology:TERACHAD.docker.7af6e...
[fe80::9209:....:3f7d]:3260,1 iqn.2000-01.com.synology:TERACHAD.docker.7af6e...

Todo drive virtual tem um IQN que é tipo uma “URL” pro drive. Agora fazemos login:

❯ sudo iscsiadm -m node --login
Login to [iface: default, target: iqn.2000-01.com.synology:TERACHAD.docker.7af6e9116c1, portal: 192.168.0.21,3260] successful.

Como não habilitei CHAP nem pede senha nem nada (em empresa o certo é estar habilitado, lógico). E pronto. Ao fazer isso eu ouço no GNOME o barulhinho igual de quando você conecta um pen-drive no PC e ele já automaticamente aparece como um disco. Se fizer lsblk, vai aparecer como um drive normal /dev/sdX da vida. No aplicativo Disks do GNOME (ou no Disk Management do Windows) vai realmente aparecer como se fosse qualquer outro hard-drive ou SSD da vida. Ele não se comporta como uma pasta compartilhada e sim como um drive de verdade. Incluve precisa formatar, igual um pen drive novo.

A formatação em si, demora bastante, porque no processo ele precisa checar e mapear bloco a bloco. Como é pela rede, é mais lento do que num drive de verdade, claro. Mas é só uma vez. Mesmo na minha rede de 10Gbps ele vai formatar numa velocidade de uns 120 MB/s, num drive de 2TB, isso vai dar na faixa de 2 horas pra um fast format. Eu esqueci que dava pra formatar com “lazy”:

mkfs.ext4 -v -E lazy_itable_init=1,lazy_journal_init=1 /dev/sdX

Fica pra próxima, agora é esperar 2 horas. Pra garantir que monte automaticamente no boot, precisa checar o node.startup dele:

❯ sudo iscsiadm -m node -o show | grep -E 'Target:|node.startup'

node.startup = manual
node.startup = manual
node.startup = manual

Está como “manual”, pra trocar pra “automatic” precisa fazer:

❯ sudo iscsiadm -m node \
  -T iqn.2000-01.com.synology:TERACHAD.docker.7af6... \
  -o update -n node.startup -v automatic

Com o daemon iSCSI de pé e depois do login, além de /dev/sda se fizer ls /dev/disk/by-path vamos encontrar algo assim:

ip-192.168.0.xx:3260-iscsi-iqn.2000-01.com.synology:TERACHAD.docker.7af6exxxxx-lun-1 -> ../../sdX

Como estou usando o serviço AUTOFS e ele “rouba” meu diretório /mnt, vou montar o drive iSCSI via fstab mesmo em /media/docker adicionando esta linha no final de /etc/fstab:

...
/dev/disk/by-path/ip-192.168.0.xx:3260-iscsi-iqn.2000-01.com.synology:TERACHAD.docker.7af6e9xxxx-lun-1  /media/docker  ext4      _netdev,nofail,x-systemd.automount,x-systemd.requires=iscsid.service,noatime,nodiratime,commit=60  0 2

Depois é só recarregar e montar:

sudo systemctl daemon-reload
sudo mount -a

E é isso. A partir de agora eu tenho um “drive virtual” no meu NAS remoto. Agora, vamos mudar o Docker pra começar a usar ele. Posso reconfigurar meu Docker pra fazer cache de imagens e volumes e tudo mais direto nesse drive. Só editar o arquivo /etc/docker/daemon.json com o mount point:

{
  "data-root": "/media/docker/docker"
}

Não esquecer de criar o diretório no novo drive com as permissões certas (e ele aceita permissões, porque é um drive formatado com ext4 como qualquer outro):

sudo mkdir -p /media/docker/docker
sudo chown root:docker /media/docker/docker
sudo chmod 771 /media/docker/docker

Por fim, é só reiniciar o serviço do Docker, apagar o /usr/lib/docker pra liberar espaço no meu NVME principal e pronto. Deve ser MUITO mais rápido que NFS, não tão rápido quanto um disco local, claro. Mesmo com 10Gbps, rede introduz latência, não tem jeito. Mas o mais pesado é mesmo o processo de build, que tem muita escrita. Pra carregar uma imagem pronta, é pra ser super rápido. Mas pelo menos usando um protocolo de bloco em vez de protocolo de arquivos, é pra diminuir a latência numa ordem de pelo menos 10x ou mais.

E é mais rápido mesmo? SIM. Nesta foto de tela do docker build rodando, com NFS os tempos à direita estavam sendo de CENTENAS DE SEGUNDOS pra vários comandos. Agora está de novo abaixo de 1 segundo como deveria. Pra todos os efeitos e propósitos, não estou sentindo diferença se fosse um HD externo USB 3.2 Gen 2.

A diferença MASSIVA que um drive virtual BLOCK-LEVEL faz, comparado com um protocolo NFS/SMB FILE-LEVEL é brutal, o protocolo é um overhead gigante. Aliás, é mais ou menos assim que funciona quando você vai na AWS e contrata storage EBS (Elastic BLOCK Store), por isso se chama “BLOCK”, porque é um protocolo de BLOCO como iSCSI e não NFS. Espero que tenha aprendido como faz diferença entender como protocolos e sistemas de arquivos funcionam. Se não assistiu meus vídeos, tem esta playlist que explica BLOCOS em detalhes.

Mas sim, iSCSI tem desvantagens: sendo um drive, não pode, ou não deveria, ser compartilhado (pense dois PCs compartilhando o mesmo pen drive, ia dar muita m&rda). Block devices foram feitos pra serem usados por um único dispositivo. Justamente, pra compartilhar, é que existem protocolos como SMB ou NFS: pra gerenciar acessos concorrentes ao mesmo arquivo na rede.

Outra desvantagem: o drive virtual é um grande BLOB de bits. Sem “montar” não tem como ver os arquivos. No servidor NAS, ele não mostra os arquivos. É como um arquivo .vhd de Virtual Box. Precisa “ligar” e “montar” no “PC”. Por isso que ainda vou usar NFS pras coisas de sempre, como Videos ou Downloads. E o drive virtual é exclusivamente pro cache de Docker, neste caso. Aí funciona bem. Nenhum outro PC acessa. Se eu tivesse um segundo Linux que precisasse de cache de Docker, precisaria criar uma segunda LUN só pra ele. Lembre-se, é um drive. Virtual ou não, ele se comporta como um drive de verdade pro seu sistema.

Fazia tempo que queria fazer um último episódio à playlist de armazenamento trazendo um pouco mais de BTRFS. Aproveito pra adicionar mais sobre Git, Docker tudo voltado ao tema de como não perder dados nunca mais e até como recuperar dados numa emergência.

Tudo que você nem sabia que queria saber sobre armazenamento e gerenciamento de dados no seu HD.

Conteúdo

• 00:00:00 - Intro
• 00:00:51 - CAP 1 - Recapitulando Sistemas de Arquivos - Journaling
• 00:02:42 - CAP 2 - Caminho pro Desastre! Git e GitHub
• 00:07:21 - CAP 3 - Git SEM GitHub - Git Raíz
• 00:12:25 - CAP 4 - Partição Perdida - Sem Superbloco
• 00:16:09 - CAP 5 - Não Caia em Golpes - Aliexpress
• 00:19:46 - CAP 6 - Tentando Consertar - Backup do Superbloco
• 00:24:51 - CAP 7 - Tentando Consertar - Última Instância
• 00:29:36 - CAP 8 - Checksums - Sistemas de Arquivos Modernos
• 00:34:18 - CAP 9 - Deduplicação - Sistemas de Arquivos Modernos
• 00:36:28 - CAP 10 - Copy On Write - Sistemas de Arquivos Modernos
• 00:40:21 - CAP 11 - BTRFS no Ubuntu - Por que Manjaro?
• 00:45:51 - CAP 12 - Snapshots e Timeshift - BTRFS
• 00:53:56 - CAP 13 - Snapshots e Docker - Não Perca Espaço
• 01:02:59 - CAP 14 - Meu NAS Anti Ransomware - Synology
• 01:07:37 - CAP 15 - Pacotes, Docker, Flatpak, QEMU - Sistema Estável
• 01:10:03 - Bloopers

Links

• A Quick and Hacky Way to Serve a Git Repo over HTTP (https://theartofmachinery.com/2016/07/02/git_over_http.html)
• NGrok (https://ngrok.com/docs/getting-started/)
• TestDisk LiveCD (https://www.cgsecurity.org/wiki/TestDisk_Livecd)
• TestDisk Docs (https://www.cgsecurity.org/testdisk_doc/presentation.html#testdisk-partition-recovery)
• ArchWiki: BTRFS (https://wiki.archlinux.org/title/Btrfs)
• Timeshift and grub-btrfs in Ubuntu (https://www.lorenzobettini.it/2022/10/timeshift-and-grub-btrfs-in-ubuntu/)
• timeshift-autosnap-apt (https://github.com/wmutschl/timeshift-autosnap-apt)
• Scheduled snapshots not working (https://github.com/teejee2008/timeshift/issues/135)
• Why is Grub menu not shown when starting my computer? (https://askubuntu.com/a/1187104)
• Full-disk encryption with Btrfs on Ubuntu Xenial (https://albertodonato.net/blog/posts/full-disk-encryption-with-btrfs-on-ubuntu-xenial.html)
• How To Add Swap Space on Ubuntu 20.04 (https://www.digitalocean.com/community/tutorials/how-to-add-swap-space-on-ubuntu-20-04)
• Swapfile Swapon invalid argument (https://unix.stackexchange.com/a/713929)
• Thoughts on swap partition vs swap file in subvolume with Btrfs? (https://www.reddit.com/r/archlinux/comments/ymq7ve/thoughts_on_swap_partition_vs_swap_file_in/?onetap_auto=true)
• How do I use Timeshift/btrfs to permanently restore to a previous snapshot? (https://forum.manjaro.org/t/how-do-i-use-timeshift-btrfs-to-permanently-restore-to-a-previous-snapshot/124683)

SCRIPT

Olá pessoal, Fabio Akita

Estou bem atrasado com a segunda parte do video da Rinha, e vai demorar mais um pouco. Honestamente, o tema me deu burn out, então resolvi fazer um video antes que não deixa de ser um pré-requisito porque até o final vou explicar um pouco mais sobre Docker e Docker Compose. Mas antes, quero falar de um problema que vira e mexe vejo desenvolvedores tendo: perder dados.

Sim, acidentes acontecem, e tanto o hardware quanto sistemas operacionais de hoje em dia, ajudam muito a não perder dados. Mas sério, a maioria de vocês não ia conseguir sobreviver com a tecnologia rudimentar que a gente tinha nos anos 80 e 90. Eu mesmo não lembro mais a última vez que perdi dados. Acho um absurdo que programadores ainda percam tempo com esse tipo de problema, então quero discutir diversas soluções pra isso. Vamos lá.

(…)

Um bom programador é mestre da sua máquina, nunca o contrário. Quando seu hardware perde seus dados e te força a passar perrengue, ele se tornou seu mestre, e você não é mais que um mero peão de um objeto inanimado. Vocês tem que mostrar quem manda. Vamos a alguns fatos. Em termos de sistema operacional, tanto faz se usa Mac, ou Windows ou Linux. Nenhum deles é muito melhor que o outro em termos de garantia de dados. Não é porque escolheu usar Mac que está magicamente mais protegido do que Windows. Isso não é verdade faz anos.

Vejam minha série sobre armazenamento. O NTFS do Windows tá longe de ser perfeito, cheio de problemas ainda, mas pro dia a dia, você não vai ter mais problemas do que teria com um ext4 no Linux ou APFS no Mac. Todos tem journaling, por exemplo. Significa que, mesmo que acabe a luz no meio de uma operação de disco, seu sistema de arquivos não vai ficar corrompido a toa. Vira e mexe alguns blocos podem se perder mesmo, mas as rotinas de manutenção padrão, são suficientes pra resolver a maioria dos problemas.

Quando alguém perde dados só existem duas razões: porque comprou um HD muito do porcaria ou porque cometeu erro humano mesmo. Aliás, vira e mexe alguém faz aquele meme de digitar “rm -rf /” e diz que iniciante não sabe o que isso faz. Mas parece que quem faz o meme também não sabe. Já faz algum tempo que o comando “rm” não apaga a raíz assim do nada. Precisa ou digitar “/*” com asterisco no final ou usar a opção “–no-preserve-root” pra realmente apagar a raíz. The more you know.

Enfim, nenhum sistema operacional vai resolver qualquer um desses problemas. Hardware porcaria só tem uma solução: jogar fora e comprar um de verdade. Toda vez que estiver tendo problemas frequentes, a probabilidade maior é hardware porcaria. Já a parte do erro humano, vamos tentar mitigar um pouco disso hoje.

Alguns meses atrás, um conhecido foi tentar instalar Linux como dual boot com Windows no notebook dele. Não sei qual era a marca, nem nada. Mas ele se ferrou: a partição Linux não bootava mais. Agora vem o problema: as últimas coisas que ele fez no projeto dele, não tinha dado push pro GitHub ainda. E, como praticamente todo mundo aqui assistindo, não tinha backup.

Tudo que vou narrar a partir daqui poderia ter sido evitado. Hoje em dia, todo programador usa Git. Isso é obrigatório. Mesmo se trabalha numa empresa, o mais porcaria possível, que por alguma razão do além, ainda não está usando Git, não existe desculpa: o projeto não precisa adotar Git pra você usar Git. GitHub é opcional, Git não. Marrete esse conceito na sua cabeça. Não importa se é um projetinho pessoal só na sua máquina. Faça “git init” e comece a fazer “git commit”.

Git não precisa de um servidor externo. Digamos que essa empresa hipotética super tosca pra onde está trabalhando não queira usar Git pra não ter que pagar GitHub ou alguma bobagem desse tipo. Ou usa alguma alternativa obsoleta de 20 anos atrás como a enorme porcaria de um SourceSafe da vida. Aí são dois grandes erros imperdoáveis. E digamos que você também não queira investir numa conta paga de GitHub, portanto não tem como fazer repositórios privados. E agora? Como faz?

Vou repetir: não precisa existir projeto no GitHub pra usar Git. Muitos iniciantes confundem isso. Git é uma ferramenta, GitHub é um serviço. GitHub precisa de Git, mas Git não precisa de GitHub. Qualquer diretório do seu computador pode virar um repositório Git, basta digitar “git init” dentro e pronto, ele cria o subdiretório “.git” que é o repositório propriamente dito. Agora basta fazer “git add .” pra adicionar tudo nesse diretório e “git commit -m” com uma mensagem pra criar um commit e já era. Só isso.

Eu fiz dois videos onde conto tudo que você deveria saber sobre Git e recomendo que assistam. Inclusive eu conto como lá nos primórdios de Git, quando realmente ninguém nem sabia que existia, eu trabalhei em projetos de clientes que usavam coisas como Subversion, mas só eu trabalhava com Git e usava um plugin chamado git-svn pra integrar os dois. Se lá em 2007 eu conseguia usar, sem nenhum suporte, em 2023, não existe desculpa aceitável pra não usar.

Isso resolve o problema de acidentalmente apagar um arquivo que não deveria, ou mudar de ideia num código que acabou de fazer, e conseguir voltar pra como estava no último commit. Digamos que você apagou um arquivo. Puts, apagou o arquivo errado? E agora? Se você fez a coisa certa, que é ficar fazendo pequenos commits, o tempo todo, ainda deve ter a versão anterior no último commit. Faça “git status”, olha ele marcado pra deleção. Basta fazer “git checkout” e o nome do arquivo, e pronto, listamos e olha só o arquivo de volta aqui.

Qualquer programador que use de desculpa “puts, apaguei o arquivo sem querer e perdi tudo”, ainda é um iniciante que precisa aprender a usar git. Ah, mas eu gosto de primeiro terminar tudo, tudo e depois fazer commit. E eu digo que você é um idiota. Vou dar um exemplo. Digamos que fiz um código aqui num arquivo, mas não terminei. E acabou o dia. Como sou disciplinado, já vou fazer um “git commit -m ‘codigo no meio’”. Puts, mas que commit feio. Melhor um commit feio agora do que ter um acidente e perder o arquivo. Agora posso desligar o computador e ir dormir.

Acordo no dia seguinte, vou continuar editando esse arquivo e aí sim, finalmente termino. Agora posso fazer um “git commit -m ‘codigo final’ –amend”. Essa opção amend, vai desfazer o commit anterior e trocar por esse novo commit, com a nova mensagem mais bonita e descritiva. Rode “git log” olha só, aquela mensagem feia com código parcial sumiu e estou com o commit bonito. Agora posso fazer push pro servidor se quiser.

Dentro de um branch, faça quanto commits quiser, dê push de commits feios, e no final, faça um squash do branch antes de criar um pull request, se fizer muita questão. É uma das formas de lidar com isso. O histórico de commits nunca deve ser reescrito no branch master ou main, mas no seu branch, onde só você está trabalhando, foda-se, faça cinquenta commits. Daqui uma semana quando terminar, faça squash, se a quantidade de commits incomodar. Daí manda merge pra master.

Existem várias nuances no que falei, não é uma regra escrita em pedra, essas convenções vão variar de equipe pra equipe. Mas voltando ao meu ponto inicial: digamos que você não tenha um repositório remoto no GitHub. Estou trabalhando sozinho na minha máquina local. E não tenho pra onde dar push. Se der alguma pane catastrófica na minha máquina, eu perco tudo. Como evitar isso?

Se o projeto que estiver trabalhando for de cliente, e você for freelancer, por favor, pague uma conta no GitHub ou GitLab e faça push pra lá. Não desperdice o tempo de todo mundo. Isso tem nome: se chama economia porca. Porque na hora que alguma coisa der pane, não tem mais como recuperar. Isso dito, você é mão de vaca bagarai. Ok. Vou te dar a solução mais barata de todos os tempos. Espete um pendrive ou HD externo no seu PC.

Do diretório do seu projetinho faça “git clone –bare . /media/pendrive/projeto.git”. Isso vai criar um clone do seu projeto nesse pendrive. Lógico o caminho de onde o pendrive montou vai variar de distro pra distro. Adicione o pendrive como origin com “git remote add origin /media/pendrive/projeto.git”. Pronto. Vamos continuar trabalhando, criando um novo arquivo, adicionando, fazendo commit. Mas agora posso fazer o bom e velho “git push origin master” e ele vai mandar praquele clone no pendrive. O pendrive está fazendo o papel de GitHub pra você, sacou?

E podemos ir mais longe. Digamos que é aquela sexta feira no escritório, você está finalizando uma nova funcionalidade que precisa entregar hoje. O Tech lead tá lá esperando pra finalizar a parte dele. Mas aí dá uma daquelas panes no GitHub e ele fica fora do ar algumas horas. Bem no fim da sexta feira. Fodeu né? Fica pra segunda então? Não. Faça git push no pendrive, passa o pendrive pro tech lead, ele consegue adicionar como remote e dar pull no repo dele. E vai conseguir continuar o trabalho na máquina dele, mesmo sem ter GitHub.

GitHub é uma conveniência, mas não é mandatório. Qualquer coisa pode substituir. O que você perde enquanto ele tá fora do ar são as conveniências, a integração com o continuous integration, os pull requests que tavam em aberto e você não puxou, lista de issues e coisas assim, mas o código em si, dá pra manipular de vários jeitos diferentes.

Só pra concluir essa parte de Git, vou mais longe no exemplo do GitHub saindo fora do ar. Meu exemplo com pendrive assume todo mundo trabalhando presencialmente no mesmo escritório. Mas que cabeça a minha, todo mundo tá home office hoje né? Então fodeu mesmo, sem GitHub pra centralizar, se cair, todo mundo fica sem conseguir colaborar né? Só que não.

Eu terminei a minha parte na minha máquina, o tech lead tá lá na casa dele, precisando puxar o que acabei de fazer pra continuar. Não temos GitHub. Como faz? Simples. Sabe o clone “bare” que eu fiz no tal pendrive? Vamos modificar ele. Basta entrar no diretório “.git” e começar fazendo “git –bare update-server-info” e depois “mv hooks/post-update.sample hooks/post-update” e pronto, nosso repositório está pronto pra ser integrado a um servidor web qualquer. O mais simples que consigo imaginar é o http server que vem no Python. Com uma única linha de comando “python -m http.server 8000” e já era, temos um servidor web git.

Pra testar, basta ir no “/tmp” ou qualquer lugar e fazer “git clone http://localhost:8000 teste” e voilá, consigo fazer clone do meu repositório local. Quem trabalha com VPNs como TailScale ou ZeroTier já sabe o que fazer: só trocar localhost pelo IP da VPN que todo mundo da equipe enxerga e fazer o mesmo que descrevi antes: o tech lead adiciona um remote apontando pra esse servidor, consegue dar “git fetch” do seu branch e pode continuar a trabalhar tranquilamente enquanto povo do GitHub fica lá brincando de restartar servidor até voltar.

Outra solução rápida é instalar ngrok na sua máquina. Ngrok é o jeito mais simples de criar um túnel de fora pra dentro da sua máquina. Muita gente usa pra mostrar uma aplicação web rodando na sua máquina local que ainda não tem servidor de testes ou staging. Assim um cliente que não está presente consegue visualizar o andamento do trabalho olhando o que tá rodando no localhost da sua máquina. Entenderam?

Olha só, posso rodar “ngrok http 8000”. Isso vai abrir um tunel no serviço ngrok apontando pro nosso servidorzinho python local. Ele nos dá essa URL gigante de “Forwarding”. Podemos passar ela pro nosso querido tech lead. Na máquina dele, ele pode fazer “git clone " e essa URL-zona e … voilá, olha só. Da casa dele, tá conseguindo puxar os commits da minha máquina. Entenderam o que aconteceu aqui?

Num dia normal, o trabalho iria parar por horas até o GitHub voltar. Mas sabendo dessas coisas simples e triviais, conseguimos continuar trabalhando como se nada tivesse acontecido. Esse é o poder do Git e de saber como juntar componentes simples. Criar um clone “bare”, habilitar pra ser servido via http, subir um servidor http simples com python e abrir um túnel seguro usando ngrok.

Mas claro, tudo isso assume que você, no mínimo, usa Git minimamente direito. Fazendo commits frequentes. Fazendo backups frequentes. Só quem já perdeu dados sabe da importância disso. Todos que dizem que é desnecessário só provam que são virgens e ainda precisam perder alguma coisa importante pra aprender. Vocês assistindo podem aproveitar o que falei e evitar ter que passar por esse estresse.

Digamos que não fez nada disso. Deu na telha que quer experimentar montar um dual boot na sua máquina pela primeira vez, e gosta de viver perigosamente, nem deu push dos projetos pro GitHub, nem copiou num pendrive, nem sequer fez commits, tá tudo parcial na sua máquina. Mas tá seguro, você assistiu um tutorial no YouTube, seus parças tão te chamando pra jogar Genshin a noite. Não tem tempo a perder, bora redimensionar o disco, criar uma segunda partição de Windows e passar a noite jogando.

Só que aí dá tudo errado. Tudo na primeira vez, sempre vai dar errado. Aceitem essa máxima. Se for a primeira vez de qualquer coisa, já comecem sabendo que não vai funcionar de primeira. Não custa nada espetar um HD externo e copiar as coisas mais importantes lá. Mas alas, a pressa é inimiga da perfeição mesmo. Não lembro onde guardei o HD externo, não quero perder tempo procurando. Foda-se, vai dar certo, confia, cola no pai.

É muito difícil saber exatamente o que acontece em panes. Se foi algum procedimento errado ou se foi mesmo algum defeito de hardware. Pra tentar demonstrar algo parecido, fiz uma máquina virtual com um Ubuntu e um disco virtual. Esse disco aparece como dispositivo “/dev/vdb” de virtual device B, já que o virtual device A é disco primário. Está formatado como ext4, dentro coloquei meu projeto da rinha em rails, um ISO de Ubuntu. Faça de conta que é um HD normal do seu notebook.

Agora vou desmontar com “umount”. Um dos jeito de simular um erro de hardware é escrever por cima dos primeiros bytes no começo do dispositivo. Lembram dos meus videos sobre sistemas de arquivo? O que é uma partição? É uma estrutura de dados que guarda coisas como em qual endereço começa e onde termina uma partição, o tipo de sistema de arquivo, localização dos blocos. Esses primeiros bytes formam o que chamamos de Super Bloco.

Olha só, se eu tentar montar esse dispositivo de novo, vai dar erro. O Linux não sabe o que fazer, porque não tem mais o superbloco. Os dados em si ainda estão na partição, no linguição de bytes, mas sem o superbloco não dá pra saber onde começa e onde termina o que. Pense assim, seus arquivos são como casas montados com lego. Cada lego está enterrado num campo de futebol, o seu HD. Mas o superbloco tem a localização de cada bloco, e as instruções de como remontar sua casa de lego. Sem esse superbloco, mesmo achando as peças, não sabemos se ainda falta mais blocos ou como encaixar esses blocos.

Se acontecer um erro como esse, onde a partição se recusa a bootar ou montar e aparecem erros como esse, filesystem errado, ou opção errada, ou superbloco errado, é um péssimo sinal. A primeira coisa que recomendo fazer é evitar insistir. Se usar comandos errados que sobrescrevem em cima do disco, se fodeu, vai perder dados. Muito cuidado com comandos como fdisk ou mkfs, que é o equivalente de format de Linux.

A forma de diagnosticar algo assim é achar outro computador, outro notebook, baixar a ISO de algum Linux como o próprio Ubuntu, gravar num pendrive, daí passar a fazer boot pelo pendrive. A maioria das distros Linux tem um ambiente de Live CD que boota um ambiente operacional inteiro, que inclusive se conecta no seu Wifi e permite instalar qualquer pacote. Isso permite baixar quaisquer ferramentas de diagnóstico e recuperação.

A partir desse ambiente, ele vai achar seu dispositivo como um “/dev/sdb” ou “/dev/nvme2” ou qualquer coisa assim. Assistam meus videos sobre Linux, o de Gentoo principalmente, porque a instalação dele exige manualmente fazer exatamente esse tipo de operação. Por isso fiz aquele video: qualquer um que já instalou um Gentoo ou Arch do zero, já sabe como fazer isso.

Antes de continuar deixa eu comentar uma coisa: porque esse tipo de problema acontece? Digamos que não foi erro humano. SSDs quebram assim do nada mesmo? E sim, quebram. Se for no Aliexpress e pesquisar por SSDs e ordenar a partir do menor preço, sim, as primeiras dez páginas, no mínimo, é quase 100% de chance de vir um tijolo. Aliás, se vier um tijolo pelo menos vai ser mais seguro. Problema é quando vem um drive mesmo e você confia com seus dados.

Primeiro, tem os golpes mais óbvios. Quando desparafusa e abre, dentro não tem uma placa controladora e chips de memória Flash. Não, tem um adaptador USB barato pra micro SD Card. Chips de SD Card sempre usam componentes mais baratos que SSD. Eles foram feitos pra serem quase descartáveis, justamente pra uso em câmeras fotográficas ou celulares. Não foram pensados pra uso como um HD de notebook. Não tem banda pra isso, não tem controlador pra isso, não tem memória RAM de cache, a qualidade da memória NAND flash é muito inferior. Por isso são muito mais baratos.

Já disse isso antes e vou repetir: nunca deixe nada importante num SD Card. É comum eles corromperem. SD Card deve ser usado única e exclusivamente como armazenamento temporário, tempo suficiente pra chegar em casa da sua viagem, e descarregar os cartões no seu notebook. Mas os tais SSDs baratos de marcas chinesas genéricas contam com sua burrice. Ninguém nunca abre a carcaça de um SSD pra ver o que tem dentro, e eles contam com isso.

Mesmo quando vem com componentes de SSD de verdade, eles vendem chips de 500MB como se fosse 1TB. Por isso sai pela metade do preço, mas o controlador tá gambiarrado e mente pro seu computador dizendo que tem 1TB. Se você tentar mesmo gravar mais que 500MB, ele vai começar a sobrescrever os dados do começo. Como a maioria das pessoas vai só gravando mas não checa na hora se tudo gravou mesmo, só vai descobrir da pior maneira: quando precisar do arquivo, tentar acessar, e descobrir que os arquivos não estão mais lá ou estão incompletos e corrompidos.

Como evitar isso? Nunca, jamais compre marcas chinesas genéricas desconhecidas. Compre Samsung, Crucial, Sandisk, Western Digital, só marcas reconhecidas de longa data. E de lojas com alguma reputação e não um revendedor aleatório desconhecido. Muitos vão pegar a carcaça de um Samsung quebrado, colocar o tal adaptador USB com SD card e te revender como se fosse original Samsung. Só compre em loja de verdade e só compre item novo e lacrado. Pense em SSD como escova de dente: você não quer um usado.

Em quais situações você pode arriscar um SSD mais barato genérico? Se for pra ser sua biblioteca de Steam, por exemplo. HD pra games. Aí foda-se se perder dados. Se o HD for mesmo um golpe, pega outro HD barato, e baixa tudo da Steam de novo. Mas nunca, jamais, sob nenhuma circunstância use um HD desses pra trabalho, ou mesmo pra guardar coisas importantes pra você, como as fotos da sua família, dos seus filhos, das suas viagens. Você vai perder esses dados pra sempre.

Obviamente, todo mundo concordou com o que falei, mas tá fazendo exatamente o que eu disse pra não fazer. Não usou Git. Não fez uma cópia dos seus projetos num pendrive ou hd externo. Foi querer usar o mesmo HD de trabalho pra games com dual boot. E chegamos na situação que ele não boota mais e nem conseguimos mais montar a partição. O próximo passo é arranjar um outro HD, seja interno, seja externo, que tenha mais espaço livre do que o total do HD quebrado. Vamos fazer uma cópia bit a bit, pra garantir que não vamos perder mais nada.

Usando o comando “lsblk” podemos ver os dispositivos de armazenamento conectados. Aqui neste exemplo, tenho o “/dev/vba” que é a partição funcionando do meu Ubuntu, e o “/dev/vdb” que é a partição corrompida. Antes de tentar fazer qualquer coisa, o certo é usar o comando “dd” e fazer uma cópia, assim “sudo dd if=/dev/vdb of=~/Downloads/backup.hd bs=4M”. O nome de arquivo e extensão não importam, qualquer coisa serve. Dependendo do tamanho do seu HD quebrado e velocidade do seu PC, isso pode levar horas. Vai parecer que está travado. Deixa quieto lá, vai jantar e volta amanhã. O LOLzinho com os parça essa noite já miou, nem insiste.

Pronto, agora temos uma cópia bit a bit do HD nesse arquivo. Garanta que não vai perder ele, porque se fizer mais alguma coisa errada na tentativa de consertar, temos uma segunda chance com esse backup. Coloque num outro HD externo se quiser garantir. Mantenha longe de você por enquanto, você já causou problemas demais. Um profissional de recuperação de dados tem muito mais opções do que vou mostrar agora. Só vou falar o mais óbvio, porque eu também não sei tudo.

Felizmente muita gente já passou por situação similar, e a partição costuma ter backups desse superbloco. Mais de um na real. Faça o teste no seu próprio sistema. Num Arch linux, primeiro precisamos instalar o pacote “e2fsprogs”, que contém programas pra lidar com sistema de arquivos como ext2 ou ext4. Usando o comando “lsblk” podemos listar os dispositivos e com o comando “dumpe2fs /dev/vdb | grep -i superblock” podemos listar os tais superblocos e backups.

Como esperado, o superbloco primário está no endereço zero, mas veja quantos backups temos. Um no endereço 32 mil e tantos, outro no endereço 98 mil e tantos, oito backups. Um erro catastrófico é quando alguma coisa acontece que corrompe não só os primeiros bytes, mas todos os bytes até o último backup. É raro, mas pode acontecer, especialmente se você usar errado uma ferramenta como fdisk e sobrescrever uma nova partição em cima da antiga.

O comando “dumpe2fs” talvez não consiga listar esses superblocos caso a partição esteja corrompida. Tentando no dispositivo “/dev/vdb” olha só, ele dá erro e não lista nada. Podemos usar o comando “mke2fs” que normalmente serve pra formatar uma partição, mas passando a opção “-n” de “dry-run” vai só simular a execução do comando sem de fato executar nada. Lembra o que falei antes: não queremos que nada escreva nesse disco quebrado. O programa não está consultando a partição com problema, só dizendo que, se não fosse um dry-run, escreveria os superblocos nesses endereços que listou.

Pra facilitar recuperação é importante saber qual é o tipo de sistema de arquivos que escolhemos na instalação. No caso de Windows é fácil, acho que ninguém escolhe nada diferente de NTFS. Mac já complica porque antigamente tinha o HPFS+ que mudou pra APFS a partir do final de 2017 com o macOS 10.13, mas muita gente continuou usando o antigo até depois de 2018. Já Linux, maioria costuma escolher ext4. Tem gente que escolhe ReiserFS ou os novos ZFS ou BTRFS. Cada um deles tem ferramental diferente. O que estou mostrando até agora é assumindo que é ext4.

Agora podemos tentar recuperar o superbloco a partir dos backups. Temos que tentar um a um até conseguir. Talvez nenhum dos backups estejam bons, talvez já no primeiro resolva. Pra fazer essa recuperação usamos o comando “fsck” com opção “-b” e o número do backup. Agora é ir confirmando “yes” até o fim. E se continuar assim, yes, yes, olha só, terminou. Será que funcionou?

Pra saber, podemos tentar montar de novo. E sucesso, montou de primeira, sem nenhum erro. Se listarmos dentro, sim, aqui estão nossos arquivos. À primeira vista tudo intacto. Nem sempre as coisas acontecem assim bonitinho, lembrem-se que eu só simulei um problema num ambiente controlado. Sob condições ideais de temperatura e pressão, é assim que conseguimos recuperar.

O certo agora é não confiar que só porque parece tudo ok, parar aqui. O certo é plugar outro HD externo, e usar um programa como rsync pra fazer uma cópia dos arquivos pra outro lugar. Você quis economizar com HD barato, mas tá percebendo que pra recuperar agora vai precisar de vários outros HDs pra fazer o backup que não quis fazer antes? Depois de tudo copiado, o certo é formatar essa partição do zero e copiar os arquivos de volta. Mas o mais certo mesmo é, depois de copiar os arquivos pra um lugar seguro, se livrar desse HD.

Se foi problema de hardware e não erro humano, é provável que vai voltar a dar pau de novo. Nunca confie num hardware que já te deixou na mão uma vez. É lixo, joga fora. Se o cavalo te derruba, você sacrifica, é o que eu sempre digo. No mínimo troca por um SSD novo, de verdade, de uma Crucial ou Samsung da vida, e usa esse HD que deu pau num estojo externo pra ser HD USB só pra coisas não importantes como games da Steam.

Mas, digamos que o comando “fsck” não funcionou, nenhum dos backups estava bom e não deu pra recuperar o superbloco. A partir daqui depende da importância dos dados no seu HD. Faz de conta que é daqueles casos excepcionais onde sua carteira de Bitcoin com milhões de dólares está só nesse HD. Um puta erro de amador, mas já vimos isso acontecer antes. Nesse caso o melhor é procurar um profissional de recuperação de dados. Pra recuperações mais hardcore, ele vai desmontar o SSD, colocar num hardware especializado pra esse tipo de coisa e vai fazer magia negra. Dependendo da pane, talvez consiga recuperar.

Se não for esse caso, aí recomendo que instale a ferramenta TestDisk. Eu não tenho tanta experiência nisso, então recomendo que procure outros videos como este daqui. Vou deixar o link abaixo. O TestDisk propriamente dito tem algumas ferramentas de análise pra tentar recuperar as informações da partição, reconstruir o que conseguir, mas não tem nenhuma garantia que vai funcionar. Ele não é muito intuitivo de usar, por isso recomendo ler bem a documentação e assistir alguns videos de exemplo.

Seja por ter corrompido a partição ou seja porque você deletou arquivos acidentalmente, o caso é o mesmo: os bytes que compõe seu arquivo nunca são deletados de verdade. Eles ainda estão fisicamente no HD. Acontece o seguinte: o tal sistema de arquivos, como ext4, mantém um índice dizendo: arquivo chamado “hello.txt” tem 20 blocos, e os endereços desses blocos são X e Y. Quando pedimos esse arquivo, ele vai buscar esses blocos e nos devolve na ordem certa. Blocos são conjuntos de bytes, depende do sistema de arquivos dizer quantos bytes tem num bloco. Por isso falo que é tudo um linguição de bytes.

Quando mandamos apagar um arquivo, não vai bloco a bloco e escreve zeros em cima. Isso até existe, alguns sistemas chamam de “Deleção segura”. Só apaga o registro do arquivo “hello.txt” desse índice, daí perdemos a localização dos blocos. Mas os blocos em si continuam no HD. Lembram a metáfora dos legos enterrados no campo de futebol. Eles continuam lá enterrados, só jogamos fora o mapa da localização de cada peça.

Os blocos só vão se perder se algum novo arquivo escrever por cima deles. Por isso falamos que, se apagou algo por engano, a primeiríssima coisa a se fazer é desmontar esse HD e tirar da máquina, pra nenhum processo acabar gravando nada em cima por acidente. E por isso a segunda coisa é fazer um backup bit a bit com a ferramenta DD, porque isso vai preservar todos os blocos, exatamente como eles estavam até aquele momento. Daí podemos fuçar sem perigo de perder alguma coisa, porque tem o backup, a imagem exata.

No pacote do TestDisk existe a ferramenta Photorec. Também já expliquei em outro video a diferença de arquivos texto e arquivos binários, e expliquei como o sistema operacional sabe que um determinado binário é um executável. Todo arquivo binário, tem nos primeiros bytes, um cabeçalho que indica que tipo de arquivo é. Um JPEG, um PNG, um video MP4, um executável ELF de Linux, um documento de Word, todos tem cabeçalhos padrão.

Na metáfora dos Legos, é como ir desenterrando peça a peça, sabendo que um JPEG começa com um bloco vermelho, um Word começa com bloco azul, e aí tentar montar na tentativa e erro. Uma ferramenta como Photorec vai tentar, por tentativa e erro, localizar o começo dos arquivos e os blocos que fazem sentido vir depois.

Eu simulei isso nesse dispositivo “/dev/vdb”, fazendo de conta que o fsck não conseguiu recuperar. Rodando o photorec, ele vai pedir pra apontar um diretório em outra partição boa, pra onde queremos que vá gravando os arquivos que conseguir encontrar. Dependendo da quantidade de arquivos que tinha, vai demorar um bocado. No final vai surgir um diretório com um monte de arquivos com nomes esquisitos. É o máximo que podemos fazer se não tiver como recuperar o superbloco.

Olha só, tentando abrir alguns desses arquivos, de fato o conteúdo faz algum sentido. Mas claramente alguns estão incompletos. E vai vir muito lixo junto. Nesse ponto assuma que você se fodeu, perdeu a maior parte, e qualquer resquício que conseguir recuperar já é lucro. Entendeu? Se você perder o superbloco, perdeu os metadados, diretórios, nomes de arquivos, tudo. Nesse estágio estamos escovando bit mesmo.

Como não chegar nesse ponto? Só existe uma maneira: faça backup. É a recomendação mais velha da computação que ninguém segue, e eu nem tenho esperanças que vocês assistindo vão seguir, mas a gente tenta. E é a economia mais porca de todas não fazer backup. Um SSD Sandisk de 1TB, no MercadoLivre, custa uns 300 reais. Sandisk não é e melhor marca, mas é mil vezes melhor que um chinês genérico no fim do Aliexpress. Um case USB que transforma esse SSD num drive externo, não custa 30 reais. Uma balada paga isso.

Todo sistema operacional já vem com software de backup. Nem precisa instalar nada. Use o Time Machine do MacOS, use o app de Backup que já vem no Windows, use um app como Deja Vu que já vem nos Ubuntu. Não seja preguiçoso. E backup não é só pro caso de dar pane de hardware no seu SSD barato, tem caso pior. Já ouviu falar de ransomware? Vou contar como eu sou imune a isso.

Se num extremo está a pessoa que confia todos os seus dados importantes num SSD genérico chinês do fundo do Aliexpress, sem nenhum backup, do outro lado estou eu. Já mostrei minha solução em outros videos e no Insta, mas eu tenho um NAS de 60 terabytes. São 6 HDs IronWolf de nível industrial de 12 terabytes cada, em sistema de redundância, onde não perco nada mesmo se um HD morrer agora. Eu uso não só pra backup, mas faço coisas como edição dos meus videos direto dele.

Claro que não dá pra recomendar isso, é uma solução de mais de 30 mil reais de investimento, na época. Como preços pioraram, agora, é inviável. Minha recomendação é um HD externo USB, coisa de menos de 400 reais, e que vai evitar muita dor de cabeça. Qualquer coisa acima é luxo. O mínimo é suficiente, faça o que puder, só não faça nada.

Quero aproveitar pra falar de outra coisa que não falei na série de armazenamento: sistemas de arquivos modernos. Lembrando, sistemas de arquivos como os antigos FAT16 e seus derivados como FAT32, ou mesmo ext2 nos primeiros Linux, foram pensados numa época onde espaço em disco era caro. RAM era caro. CPU era caro. Não havia recursos pra desperdiçar. Era a época onde falo que a gente escovava bit, no sentido que cada bit extra fazia diferença.

Segurança e performance são trade offs. Quanto mais segurança quiser, menos conveniente as coisas vão ser e mais recursos vamos precisar. Quando gravamos um arquivo num HD, o sistema de arquivos divide os bytes em blocos e grava nos setores do disco. Esse arquivo fica lá, semanas, meses, às vezes anos, sem ser acessado. Um belo dia você resolve abrir esse arquivo. Digamos que é uma planilha. Como eu sei que um dos setores físicos do disco magnético não falhou, flipou um bit, e algum dos valores na planilha não estão errados?

Num sistema antigo como FAT16, não tem como saber. Se corromper, corrompeu e não vamos saber. Num sistema moderno existe checksums. Num APFS de Mac ou NTFS de Windows, existe checksum no nível do arquivo. Quando o arquivo é gravado, o sistema gera um checksum e grava junto. Quando pedimos pra ler, ele pega os blocos e recalcula o checksum pra comparar com o que estava guardado. Se os checksums forem diferentes, significa que o arquivo está corrompido. Não é isso, mas se não sabe o que é um checksum, pense num dígito verificador.

Essa informação é super importante, porque numa planilha com milhares de valores, podemos estar tomando decisões importantes de forma errada por causa de um único bit errado. Um único bit pode mudar um valor de 100 reais pra milhões, por exemplo. Mas se o sistema avisar que o checksum está errado, sabemos que não podemos confiar nesse arquivo. O que fazer? Se você seguiu a recomendação e fez a porcaria de um backup, podemos ir nesse backup recuperar esse arquivo.

Em sistemas de arquivos mais modernos, pensados pra situações mais parrudas como servidores de arquivos, pense um Dropbox ou Google Drive da vida, com dados de milhões de pessoas, existem opções como o lendário ZFS da antiga Sun e o novo BTRFS do Linux. Eles tem checksum por blocos. Então conseguimos saber qual bloco dentro do arquivo está corrompido. Mas eles vão mais longe.

Meu NAS Synology está em configuração de RAID, com múltiplos HDs. Significa que o mesmo bloco tem cópias redundantes em mais de um HD. E BTRFS tem uma rotina que recomenda rodar periodicamente, digamos de 3 em 3 meses ou de 6 em 6 meses, chamado “scrubbing”. É um processo pesado que vai rodar em background, sem interromper seu dia a dia, e rechecar checksum a checksum de todos os blocos. Se notar que uma falhou, e estivermos em RAID, ele vai procurar uma cópia redundante desse bloco. A chance dos dois estarem corrompidos ao mesmo tempo é baixa, então podemos usar o bloco intacto pra consertar o que corrompeu.

Todo HD falha. Não importa se é HD mecânico com discos ou chips de Flash NAND de SSDs ou NVMEs. Todo chip Flash tem uma vida útil de quantidade de operações de escrita. Depois que passar desse limite, estraga e é isso. As checagens que falei, em muitos casos, só vão indicar mais cedo que algo falhou, mas sem redundância, sem uma segunda cópia intacta, não tem como adivinhar o que era o dado original que corrompeu, só dá pra saber que corrompeu.

Checagens de checksum, recuperação de blocos corrompidos, gastam RAM, gastam CPU. Não sai de graça. Servidores de arquivo parrudos como ZFS precisam de gigabytes de RAM pra serem eficientes, e vão usar toda RAM possível. Claro que tem mais vantagens que só isso. NTFS acho que não tem, mas APFS de Mac, assim como ZFS e BTRFS de Linux tem deduplication.

Faz de conta que você é desenvolvedor web e tem diversos projetos de Node.js na sua máquina. Sabe o maldito “npm install” que gera aqueles diretórios node_modules em todo projeto? Concorda que na maioria dos projetos vai ter as mesmas bibliotecas e os mesmos arquivos? Então estamos desperdiçando espaço com tanta duplicata? A resposta é sim, está desperdiçando.

Pra combater isso existem processos de deduplicação. Num NTFS de Windows, se estiver em Windows Server, ele oferece ferramenta pra que, caso dois arquivos tenham exatamente o mesmo conteúdo binário, ele consiga fazer o metadado dos dois apontarem pros mesmos conjuntos de blocos. Se forem dois arquivos de 200MB, originalmente iriam ocupar 400MB, mas com deduplicação, vai ocupar só 200MB. Só volta a ocupar mais espaço se decidirmos modificar o segundo arquivo, por exemplo.

Isso é muito útil no cenário de servidor de arquivos da empresa. O chefe manda um email com um PDF de 100MB pra 10 pessoas. Cada uma grava no seu diretório pessoal no servidor. Iria ocupar 1 giga. Mas se rodar a ferramenta de deduplicação, ele faz as 10 cópias apontarem pros mesmos blocos de um arquivo só, economizando 10 vezes o espaço. É o mesmo caso de termos 10 projetos de Node, cada um com node_modules repetidos. Rodando algum processo de deduplicação, no caso uma ferramenta como Opendedup no Linux, dá pra fazer algo semelhante no ext4.

Mas nenhuma dessas soluções é ideal. Os sistemas de arquivos NTFS e ext4 não foram feitos pra suportar esse tipo de coisa. O sistema de arquivos em si não suporta nada disso, daí dependemos de uma ferramenta externa pra tentar adicionar essas funcionalidades. O ideal é que o próprio sistema de arquivos implemente Copy on Write, independente de uma ferramenta externa.

Copy on Write ou CoW é super importante. É literalmente os conceitos de um Git só que em nível do sistema de arquivos inteiro, funcionando de forma transparente pro usuário. Num sistema copy on write, quando editamos um arquivo que já existe, os novos blocos não são gravados por cima dos antigos, ele faz o equivalente a um branch de Git e os novos blocos são gravados nesse branch, parecido com commits. Isso mantém o arquivo original intacto.

De cara, isso também evita mais corrupção de dados. Antigamente, num FAT16 da vida, onde estávamos na situação onde não tínhamos espaço sobrando, não tinha outra opção: toda modificação de arquivos precisava gravar os blocos novos em cima dos velhos. Mas e se acabasse a luz no meio? Ia ficar um arquivo corrompido. E isso era comum. Pra mitigar esse problema criou-se o conceito de journaling, que NTFS no WIndows, ext4 no Linux. HPFS+ no Mac passaram a suportar no fim dos anos 90.

Super resumido é assim. Digamos que eu tenha um arquivo, aquele Powerpoint, e ele ocupa 10 blocos no disco. No sistema de arquivos temos o nome do arquivo e um mapa apontando pra esses 10 blocos. Isso faz parte dos tais metadados de um arquivo. Agora editamos por cima e essa mudança afetaria os dois últimos blocos. Esses dois blocos serão gravados no disco e a localização será gravada no journal. O arquivo original ainda tem os 10 blocos originais até este ponto.

Ao terminar de gravar os dois novos blocos, só aí o NTFS vai atualizar o mapa do arquivo e mudar a referência dos dois últimos blocos pra apontar pra localização dos dois novos. Mas digamos que ele começou a mudar a referência do penúltimo bloco e antes de mudar a referência do último, acaba a luz e o sistema reboota. Quando reiniciar, o NTFS checa o journal e vê que faltou mudar a localização do último bloco.

Como ele tem essa informação no journal, vai conseguir terminar a operação e o Powerpoint não fica corrompido, como ficaria antes. Se ele ficasse em dúvida, faria rollback, e manteria o arquivo intacto. Os novos blocos não sobrescreveram os antigos ainda. Esse processo gasta um pouco mais de espaço, mas evita que arquivos fiquem corrompidos. Espaço hoje é mais barato, então podemos fazer isso.

Copy on Write vai um passo além. Depois que os novos blocos são gravados e registrados no journal, é feito tipo um fork no nível dos metadados. Imagine o mundo antes de Git. Se você copiasse um arquivo em cima do outro, o que acontece com o original? Ele se perderia pra sempre, certo? É assim que todo sistema de arquivos funciona. Mas o que acontece quando habilita Git num diretório e copia um arquivo em cima do outro? Vamos testar.

Aqui temos um diretório com Git habilitado e os arquivos já comitados. Se listar o que tem neste hello.txt, veja, “hello world”. Vou criar um novo arquivo fora, lá no /tmp com conteúdo de “bla bla bla”. Copio o arquivo por cima do meu original. Normal, meu arquivo original com “hello world” foi pro saco como podem ver. E se eu mudar de idéia?

Agora entra o Git pra te salvar. Fazendo “git status” podemos ver que ele sabe que esse arquivo foi modificado mas ainda não comitamos, não nos comprometemos com ele. Então podemos fazer “git checkout” desse arquivo, olha o conteúdo, “hello world” de volta. Git nos permite mudar de idéia e não perder dados ao custo de manter uma cópia do original em algum lugar ocupando espaço extra.

É por isso que todo projeto deve usar Git. Podemos mudar de idéia sem preocupação. Quando estivermos satisfeitos fazemos commits, e mesmo assim podemos reverter e até recuperar commits apagados. Copy on Write em sistema de arquivos é a mesma coisa. E em Linux, que eu saiba, só existem dois sistemas de arquivos modernos que suportam isso: o ZFS e o BTRFS.

Quem usa Ubuntu tem na instalação a opção de usar ZFS. E aqui já aviso: evite. É muito fácil fazer besteira em ZFS e perder tudo sem querer. ZFS é excelente pra quem está montando um servidor de arquivos, usando distros com o TrueNAS, que é o melhor. Só quem estudou bastante a documentação de ZFS deve tentar usar. Não basta só instalar e acabou, precisa de constante manutenção e monitoramento pra saber se está realmente tudo funcionando como deveria. Pra usar no dia a dia, no seu notebook, acho que vai mais atrapalhar do que ajudar.

Isso não quer dizer que ZFS é ruim, pelo contrário, é provavelmente o sistema de arquivos mais avançado que existe. Porém, pros propósitos de máquina do dia a dia de programador é como matar uma mosca com uma bazuca e arriscar atirar a bazuca no seu pé. Outra coisa: todo mundo me pergunta qual distro eu mais gosto. Eu uso Manjaro GNOME no meu dia a dia. Primeiro porque é um Arch Linux mais estável. Ele segura um pouco os pacotes mais novos, pra testar e garantir que nada vai quebrar. Mesmo assim alguns updates ainda quebram de vez em quando, mas é um bom compromisso entre ter coisas novas mais rápido e não ficar parado a cada novo update.

Mais importante: Manjaro já vem pré-configurado pra BTRFS logo na instalação. É só instalar, escolher BTRFS e ele vai se virar e te dar um ambiente estável. Em vez de mostrar Manjaro, vou mostrar Ubuntu 23, que acabou de lançar. Todo o trabalho de configuração que vou mostrar agora não precisa fazer fazer no Manjaro. Começando na instalação, todo mundo escolhe aqui a primeira opção, que vai instalar EXT4 igual toda outra distro. Mas agora ela tem essa segunda opção com ZFS, que é experimental ainda. De novo: não teste numa máquina de trabalho. Teste numa máquina virtual pra aprender tudo primeiro caso queira mesmo adotar ZFS.

Em vez disso vamos nessa terceira opção e particionar o disco manualmente. Não vou explicar cada detalhe. Vamos assumir que você está num PC moderno, dos últimos 10 anos. Provavelmente vem com modo legado na BIOS desligado, já suportando boot com EFI. Falando nisso, não deixe de assistir meu video que explica como o Boot de Linux funciona.

Enfim, vamos primeiro criar uma partição EFI que a BIOS vai procurar primeiro. Uns 200 megabytes costuma ser suficiente, deixe 500 se quiser garantir. Depois precisamos de uma segunda partição com um sistema de arquivos legado fácil da BIOS ler. Em Windows costuma ser FAT32, mas aqui podemos escolher o antigo EXT2 mesmo. Eu deixo 500 mega, mas de novo, pra garantir pro futuro caso a kernel cresça de tamanho, deixa 1 gigabyte. Espaço é barato.

Agora usamos o resto do espaço pra partição primária com BTRFS e montando o root nela. Se for um notebook, sempre recomendo criar uma partição encriptada com LUKS, ou no mínimo ter o subvolume de HOME encriptado com LUKS. Não vou explicar nada disso aqui porque é um saco de configurar, então pesquisem no Wiki do Arch sobre isso. BTRFS funciona mais ou menos como um LVM, um gerenciador de volumes lógico. Ele começa como um pool de subvolumes e por default vai criar um subvolume chamado “arroba” onde vai montar o “/” root e outro “@home” onde vai montar o “/home”.

Novamente, pesquise sobre LVM e volumes lógicos. Antigamente uma boa prática era separar duas partições: uma pra root onde fica o sistema operacional e outra pra home, daí montamos essa partição como “/home”. O problema de usar partições é que eles tem tamanho fixo. Uma vez definido não tem como redimensionar fácil. É como no Windows quando você particiona C: e D:. Mas com volumes lógicos, podemos redimensionar on the fly, sem qualquer problema. E BTRFS vai um passo além, subvolumes servem propósito parecido de volumes lógicos mas nem precisamos nos preocupar em redimensionar, eles são dinâmicos.

Enfim, quando terminar de instalar podemos bootar. Vamos acelerar aqui, três, dois, um e pronto. Ubuntu instalado. É muito fácil instalar distros Linux hoje em dia. Só não instala quem tem muita preguiça ou tem um hardware muito, mas muito ruim. Quando Linux não identifica hardware só tem duas opções: ou ele é muito ruim, ou é muito novo ou recém lançado. Se você não comprou um note que saiu este ano, não tem desculpa, é o hardware que é ruim, porque drivers pra Linux são atualizados constantemente.

Se estiver em dúvida num notebook, e tiver a oportunidade de experimentar antes de comprar, leve um pendrive com um Manjaro ou Ubuntu da vida e faça boot pelo pendrive. Veja se ele consegue identificar tudo: wifi, bluetooth, áudio, placa de video. É o melhor teste que pode fazer. Se alguma coisa não for detectada, desista desse modelo. Vai te dar mais trabalho do que compensa.

Pronto, agora vamos listar o arquivo “/etc/fstab” que o Ubuntu criou. Super simples. Dispositivos de armazenamento são identificados por um UUID. Abrindo o terminal, basta digitar “lsblk -f” e vai ter uma coluna com UUID. O arquivo “/etc/fstab” define quais dispositivos vão montar onde durante o boot. Por exemplo, o dispositivo de UUID que começa com ed022 vai montar como root “/”. Olhem na listagem, é o dispositivo /dev/vda3. O /dev/vda2 de UUID que começa com 294c8 monta como /boot.

A graça começa quando vemos o ponto de montagem de “/home”. O Ubuntu, pelo menos, separou corretamente um subvolume de BTRFS chamado “@home”. É uma boa prática. Mas temos alguns problemas. Do jeito que está aqui, não podemos ativar snapshots, porque seu espaço em disco vai desaparecer rapidamente.

Snapshots são possíveis por causa da funcionalidade de copy on write do BTRFS que expliquei antes. Copy on write funciona mais ou menos como branches num Git. Lembra que mostrei que o Git consegue manter o arquivo original, sem perder o conteúdo, mesmo eu gravando outro por cima? Pra fazer isso, obviamente, precisa manter o conteúdo original gravado em algum lugar, certo? Está gastando espaço extra. Diretórios do Linux como /var/cache, /var/log, /var/tmp estão em operação o tempo todo. Mesma coisa /tmp ou arquivo de swap. Se ficar mantendo versão velha deles em snapshots, o espaço livre do seu sistema vai acabar muito rápido sem você entender porque.

Pra resolver é assim: abre o terminal e faça “sudo chattr +C /var/log”. Isso é change attribute, estamos mudando o atributo do diretório pra dizer pro BTRFS não considerar arquivos nesse diretório pra snapshot. Esse change attribute só vai afetar novos arquivos criados, não os antigos que já existem, sempre se lembrem disso, mas como acabamos de instalar, acho que só isso deve ser suficiente.

Agora vamos instalar o Timeshift. É um programa gráfico pra fazer snapshots periódicos do sistema. Pra iniciantes, vai ser mais fácil do que lembrar os comandos pro terminal. Basta fazer “apt install timeshift” ou “yay -S timeshift” no Arch ou Manjaro. Logo que abrir ele vai oferecer pra configurar pra você. Mesmo se não estiver usando BTRFS, a alternativa é usar Rsync, caso esteja usando ext4.

Rsync, é um programa pra sincronizar dois diretórios. Equivalente no Windows é o novo robocopy ou o antigo xcopy. O jeito força bruta, sem a ajuda do sistema de arquivos, pra ter um backup local, é fazendo sincronização de diretórios. O problema é óbvio: vai ocupar espaço pra cacete no seu sistema, porque periodicamente vai duplicar tudo. Sim, se algo der errado e apagar algum arquivo que não devia, vai ter uma cópia. Com a funcionalidade de copy on write e snapshots do Btrfs temos a mesma coisa, mas sem duplicar nenhum arquivo e sem gastar mais espaço do que realmente precisa no mesmo HD.

Tá complicado de entender? Olha só, vou baixar um arquivo qualquer aqui, escolhi a ISO do Ubuntu. Acelerando e … pronto, baixado. Agora vou no Timeshift e crio um snapshot manualmente. Com o timeshift configurado posso escolher pra fazer snapshots de hora em hora, e guardar X snapshots por hora, Y snapshots por dia, Z por semana e assim por diante. Depois dêem uma fuçada, mas criei um pra mostrar agora. Snapshots são baratos, pode fazer toda hora. Não importa se você tem mil arquivos ou um milhão de arquivos, diferente de rsync, o tempo de criação de snapshots é quase instantâneo, porque ele não está duplicando nenhum byte, só metadados.

Simulando um acidente, oops, apaguei essa ISO que acabei de baixar. Que droga, vou ter que esperar um tempão pra baixar de novo. Ou não. Vamos no Timeshift e posso navegar pelos arquivos do snapshot. Olha só, se formos na pasta de downloads, a ISO está lá. Pronto, só copiar de volta pra pasta de downloads corrente e tá na mão: arquivo recuperado.

Não ficou claro? Vou dar outro exemplo. Mas pra isso precisamos terminar de configurar o Timeshift. De novo, siga o artigo que deixei linkado abaixo. Diferente do Manjaro que já me dá isso automaticamente, no Ubuntu precisamos manualmente instalar o grub-btrfs a partir do código fonte. Primeiro precisa instalar os pacotes build-essential pra termos compilador, e o git. Daí fazemos clone do repositório e “make install”.

Também precisamos instalar o pacote inotify-tools e editar a configuração do grub-btrfs com “systemctl edit –full grub-btrfsd” e trocar a opção “/.snapshots” por “–timeshift-auto”. Pronto, agora só iniciar o serviço e habilitar pra iniciar automaticamente depois do boot. E finalmente, mais um programa que precisamos instalar a partir do código fonte, o timeshift autosnap. Mesma coisa, só fazer clone do repositório e rodar “make install” dentro.

O que tudo isso faz? Se ainda não passou por isso, é só uma questão de tempo. Sabe quando estamos no meio do dia e pensamos, ah, vou fazer uma atualização no sistema. “apt update” daí “apt upgrade”, reboota o computador e pau, não boota mais. E vai ser justo naquele dia que você tá sem nenhum pendrive por perto, daí não consegue bootar no LiveCD. Você tá de home office e decidiu ir trabalhar do Starbucks, não tem nenhum amigo com computador por perto pra baixar a ISO pra você. Acabou sua tarde. Vai ter que voltar pra casa, achar um pendrive, baixar a ISO e gastar um tempo no stackoverflow tentando voltar um kernel antigo pra bootar de volta na sua máquina. Quem nunca?

E se eu disser que nunca mais vai precisar fazer isso? Vamos simular de novo. O Timeshift já está configurado pra fazer snapshots periódicos. Com isso, caso um dia lembre, puts, eu queria aquele arquivo que apaguei mês passado e achei que não fosse precisar. Meu HD de backup tá em casa, e agora? Sem problemas, só pegar o snapshot do mês passado, que está local na sua máquina. Mas, e na situação quando fizer um “apt upgrade” e isso quebrar seu sistema? Sem problemas também, aquele pacote timeshift autosnap vai criar um snapshot automático antes de todo “apt upgrade”.

Daí aquele pacote grub-btrfs vai listar esses snapshots no menu de boot do grub. Oops, Ubuntu por padrão não mostra o menu do Grub. Mas isso é fácil, só editar o arquivo “/etc/default/grub” e mudar a opção GRUB_TIMEOUT_STYLE de “hidden” pra “menu” e a opção GRUB_TIMEOUT de zero pra uns cinco ou dez segundos. Pra atualizar, só rodar “update-grub”. Vamos ver como funciona.

Pra simular, vamos criar mais um snapshot temporário chamado “teste” no Timeshift. Como é um snapshot manual, vou rodar “update-grub” manualmente, mas num “apt upgrade” não precisaria. Agora vou abrir a loja do Ubuntu e instalar alguns programas. Vamos instalar aqui o Gimp, vai demorar um bocado. Acelerando … Agora instalamos o Discord, de novo, vamos acelerar. Pronto. Podemos checar no menu, e estão aqui, Gimp, e Discord. Faz de conta que instalei um monte de coisas mas no final mudei de idéia, queria desinstalar tudo e voltar como estava antes. Como faz?

Fácil, só rebootar. Agora aparece o menu do Grub aqui no boot e tem esta nova opção e olha só os snapshots que estávamos vendo no timeshift. Estão vendo a descrição “teste”? Basta escolher esse ou um snapshot anterior. Entenderam? Posso bootar direto em um snapshot. Esperamos iniciar, e olha só. Cadê o Gimp? Cadê o Discord? Como o nome diz, timeshift, ele fez um shift no tempo, voltamos ao passado, exatamente como estava antes de instalar aqueles aplicativos. Imagine que em vez de Gimp ou Discord fosse um “apt upgrade” e veio uma kernel quebrada que fode o boot? Basta rebootar, escolher o snapshot anterior e pronto, vai ser como se nada tivesse acontecido.

Abrindo o Timeshift, pra tornar isso permanente, posso fazer um Restore do snapshot antigo pra passar a ser meu sistema corrente. Só isso. Entenderam? Com o Timeshift temos um backup local que ocupa muito pouco espaço e com isso qualquer acidente pode ser facilmente recuperado sem precisar de HD externo, sem precisar esperar copiar tudo de backup nem nada, muito menos reinstalar tudo do zero. É instantâneo.

Claro, isso é uma conveniência, pense como sendo sua última barreira de defesa. Isso não substitui um backup externo. O Timeshift e BTRFS, pra funcionar, depende que seu SSD esteja funcionando perfeitamente. Se o SSD em si der pau, como mostrei no começo do video, isso não vai te salvar. Aí só um backup externo. O que estou recomendando é ter as três coisas que mostrei até agora: se disciplinar a usar Git em todo projeto, pessoal ou de trabalho. Daí ter BTRFS e Timeshift pra consertar acidentes rápidos. E um backup externo pra evitar catástrofes mais sérias. São três níveis de segurança de dados pra ter dar paz de espírito.

E pra finalizar, tem um detalhe importante no caso de BTRFS. Aqui tem a ver um pouco com a Rinha de Backend de novo. Durante toda minha exploração dos projetos dos participantes, fiquei rodando Docker Compose de cada projeto. Eu já fiz um video explicando containers e Docker em particular, não deixem de assistir. Mas vamos entender o problema.

De dentro do projeto de qualquer um dos participantes, vamos rodar “docker compose up”. Lendo o arquivo docker-compose.yml, vai estar configurado várias aplicações, por exemplo, nginx, postgres. De onde vem esses aplicativos? O Docker vai baixar a imagem do docker.io. É isso que significa esses “pulls”. Uma imagem não é um único arquivo, é um conjunto de arquivos binários, que chamamos de overlays. Pense como se fossem commits de Git, mas commits binários. Esses overlays são unificados num único sistema de arquivos usando o Union File System ou UFS.

Se rodar o comando “mount” olha só aqui no fim, vários pontos de montagem usando overlays. Rode o comando “docker image ls” e temos a listagem das imagens baixadas e geradas localmente. A imagem do projeto em Node.js tá custando 220MB, o nginx tá ocupando quase 200MB, o postgres mais de 400MB. Só esse projeto, pra rodar, precisou gastar quase 1 Giga aqui no meu HD.

Onde ficam esses arquivos de overlays? Dentro do diretório “/var/lib/docker/overlay2”. Podemos listar como sudo e temos vários diretórios com o SHA256 de cada camada da imagem. Agora experimente testar docker compose de uns 50 projetos. Coisas como postgres e nginx, se forem da mesma versão, vão ser reusados, mas cada imagem de aplicação custa na faixa de 200 MB pra cima. Então 50 vezes 200 vai dar quase 10 Giga.

De tempos em tempos é recomendado rodar um “docker system prune” pra apagar imagens que não estão sendo usadas. Mas cuidado, se tiver containers, mesmo desligados, associados a uma imagem, ela não vai ser apagada e vai ficar sobrando ocupando espaço a toa. Use o comando “docker container ls -a” pra listar e apague os que não precisa. No caso de docker compose, quando acabar de testar o projeto, faça “docker compose down rmi –all” pra limpar containers, imagens, volumes e network que não for usar mais.

Mas beleza, 10Gb pra 50 projetos parece pouca coisa. O problema é que eu não excluí o diretório do docker da solução de snapshot. E o timeshift vai ficar criando snapshots periodicamente. Pense assim, eu fui baixando docker compose up, um monte de imagens, ao longo de mais de uma semana. Todo dia o timeshift foi fazendo snapshots. Num dia eu fazia docker compose up. No dia seguinte fazia docker compose down, achando que tava apagando tudo, mas na verdade eles estavam sendo guardados nos snapshots.

Depois eu resolvo testar o projeto de novo, faço um novo docker compose up. Vai baixar 1 giga de imagens outra vez. Só que agora tem 1 giga das imagens antigas no snapshot de ontem, e mais 1 giga duplicado no snapshot de hoje. BTRFS tem opção de deduplicação, mas ele não roda automaticamente, por padrão vai duplicar tudo. Repita isso em diversos projetos ao longo de duas semanas.

Quando terminei de testar tudo, escrevi o script do último video, gravei, editei, e meu sistema começou a ficar estranho. Tudo foi ficando mais lento. No começo achei que era pau do Microsoft Edge, porque ele começou a crashear do nada. Tentei reinstalar e nada. Ué, que diabos tá acontecendo com meu sistema. Eis que comandos de instalar pacotes como yay começaram a dar problema e aí caiu a ficha. Fui checar quanto de espaço eu tinha com “df -h” e tava dizendo que tava com 100% ocupado na partição primária.

Puts, as malditas imagens de docker! Tentei dar um docker system prune. Mas nada. Continua ocupando 100% do disco. Puts, os snapshots! As malditas imagens ficaram presas em snapshots do passado. Abri o timeshift e apaguei todos os snapshots do passado. Voltei pra verificar o espaço livre, e nada, continuava ocupando. Ué, que diabos.

BTRFS é conservador, ele não vai apagar nada a menos que você realmente diga pra apagar. Apagar snapshots não libera o espaço, pra isso precisa reclamar esse espaço de volta. Deixa eu demonstrar. Podemos rodar o comando “btrfs filesystem df /”. Uma das pequenas desvantagens de usar btrfs é que ferramentas normais de Linux como o comando “df” propriamente dito, podem informar valores incorretos.

No nosso Ubuntu de exemplo, estamos usando um total de 25GB. Isso é somando coisas como metadados do sistema de arquivos e tudo mais. Os bytes dos arquivos em si é esse “used”, pouco mais de 23GB. Ou seja, pelo menos 2GB são só metadados. Você precisa entender essa diferença. Tamanho de um arquivo não são só os bytes dentro desse arquivo. O nome do arquivo ocupa espaço, a informação de data de criação também, atributos como read only, localização no diretório também. Tudo ocupa espaço. E quanto mais avançado é o sistema de arquivos, mais espaço vai ocupar de metadados.

Enfim, se você não tem noção de quanto um sistema recém instalado ocupa, pode pensar “ah, 25 giga, ok, faz sentido”. Mas lembra que eu fiz alguns testes de snapshots pra vocês verem na prática? E aquele Gimp, e aquele Discord? Eles desapareceram, mas os bytes deles continuam no snapshot antigo. Vamos abrir o Timeshift e apagar todos os snapshots.

Rodando de novo o comando “df” do btrfs, não mudou nada. Continua indicando 25GB. Foi o que aconteceu na minha máquina quando acabou espaço. Mesmo apagando os snapshots, continuava indicando falta de espaço. Precisa manualmente reclamar o espaço de volta, pra isso usamos o comando “btrfs filesystem balance start /”. Esse comando é bem demorado. Pode levar mais de hora numa máquina como a minha, mas pelo menos podemos continuar usando o sistema em paralelo.

Enfim, esperamos acabar e pronto. Vamos ver de novo o comando “df” e olha só, caiu de 25GB pra 10GB! Tinha 15 GB sendo reservado pelo btrfs seja pros snapshots antigos e outras coisas dele. E isso numa instalação nova, praticamente vazia, onde só instalamos 2 programas. Agora imagina no meu caso, com dezenas de imagens de docker em snapshots. Ocupou meu HD inteiro de 1 terabyte. Pois é, foi muito fácil encher 1 tera em poucos dias só de não ter tomado cuidado.

E como faz pra isso não acontecer? Tem que fazer “sudo chattr +C /var/lib/docker” ou também “sudo chattr +C /var/lib/libvirt” no caso de estar usando Libvirt pra máquinas virtuais. E de novo, isso só vai se aplicar a arquivos novos. O correto é primeiro limpar esses diretórios, daí mudar esse atributo. Acho que o certo não é aplicar esse atributo no diretório todo, algumas coisas talvez você queira manter snapshots, como volumes de Docker. Fique só atento com isso.

Essa dica é muito importante, porque se você não entender o funcionamento de snapshots no btrfs e começar a usar como máquina de desenvolvimento, com certeza vai ter imagens de docker, e isso com certeza vai destruir o espaço livre em poucas semanas. Você não vai saber que é, nenhum tutorial de como liberar espaço vai funcionar, você não saberia que precisa rebalancear o sistema, e no final iria desistir e reinstalar tudo do zero de novo.

No momento em que estou escrevendo este script, no meu Manjaro, se rodar “df” ele me diz que está usando 775 giga do meu NVME de 1TB de novo. De arquivos mesmo são só 164 GB. Bora rodar “balance start” e ir tomar café. Deixei 1 hora rodando e olha só, agora diz que está usando um total de só 166 giga, que faz mais sentido. Ainda tinha uns snapshots velhos, provavelmente com imagens de docker velhas.

Logo que instalei o Timeshift, mostrei que tem como configurar pra guardar snapshots só de hoje, ou da semana, ou até de meses. Se você tem um bom backup externo, isso não é necessário, só o do dia ou até o da semana deve ser suficiente. Quando ver que está acabando o espaço, sabendo que tem tudo no backup externo, pode apagar todos os snapshots do timeshift, menos o último. Daí rodar o rebalanceamento e pronto.

Segurança é um trade off com performance e espaço. Gastamos mais processamento e gastamos mais espaço, pra garantir paz de espírito, essa é a filosofia. E felizmente chegamos num ponto onde o sistema operacional realmente nos ajuda a não perder nada. A única coisa que nenhum software consegue fazer, é consertar um hardware barato porcaria. Contanto que o hardware seja bom, é quase impossível perder dados hoje em dia. Tão importante quanto não perder dados importante é não perder horas ou dias tentando recuperar seu sistema por causa de uma atualização bugada. Basta não ter preguiça, porque as ferramentas estão à nossa disposição e, como demonstrei, são super fáceis de usar.

O meu NAS Synology usa BTRFS também, mas em configuração de RAID. Ele roda scrubbing a cada 6 meses e faz checagens de checksum pra garantir que nenhum erro físico nos HDs me faça perder dados. Isso é só pra quem escolher ter um NAS: lembre-se de configurar pra rodar scrubbing, é essencial, mas isso vem desligado por padrão. Não basta só instalar e achar que vai tudo funcionar por mágica.

Numa distro Linux como Ubuntu ou Manjaro, tenho o Timeshift. Mas no sistema operacional da Synology, ele tem o Snapshot Replication, que também me permite navegar por snapshots antigos e recuperar coisas rapidamente. Olha só, se der qualquer problema, consigo ver como eram meus arquivos de 4 meses atrás. E não sei se perceberam, mas esse sistema de snapshots me dá outra coisa de graça: proteção contra ransomware.

O que é um ransomware? É um malware que você instala ao abrir um powerpoint ou PDF qualquer que veio de um email desconhecido e na verdade era um programa malicioso. É assim que YouTuber perde o canal deles: clicando em PDF falso que não era um PDF. Parem com essa mania de dar duplo clique em tudo. O malware se instala silenciosamente na sua máquina e começa a encriptar seus arquivos. Pode levar dias e você não vai perceber até precisar abrir um desses arquivos e notar que não abre mais.

No final vai aparecer uma janela parecida com essa dizendo algo como “Você se fodeu, encriptamos todos os seus arquivos, podemos te dar a chave pra desencriptar mas você vai nos pagar X bitcoins pra isso. Mande pra este endereço e daí te damos a chave”. Isso realmente acontece, e não existe garantia nenhuma de receber essa tal chave, mesmo pagando. Se isso acontecer com você, nunca pague, só aceite que você se fodeu. Reze pra ter seguido minhas recomendações.

Ah, mas eu tenho backup externo, então tô seguro, não? Não. Eu disse que leva dias pra esse processo conseguir encriptar todos os seus arquivos. Durante esse período o que você fez? Plugou o HD externo e deixou fazendo backup dos arquivos encriptados por cima dos arquivos bons do backup. Agora seu backup também foi contaminado, parte dele tá encriptado. Perdeu playboy.

É menos ruim se estiver usando Google Drive ou Dropbox ou OneDrive da vida, porque eles tem suporte de snapshot. Mas eu não confiaria muito. Nunca precisei usar o deles então não fucei o suficiente, mas veja esta minha pasta do Obsidian no Dropbox, que é onde edito meus scripts. Tem essa função de Rewind, que é voltar pra trás. Escolho o dia que quero voltar, e ele me mostra as últimas atividades. Daqui posso escolher voltar pra algum ponto do passado, mais ou menos como commits também. É meio um saco porque eu não vi uma interface que permite voltar meu Dropbox inteiro, acho que tem que ir diretório a diretório, não tenho certeza. Enfim, não achei muito intuitivo de usar, mas em última instância, se não tiver mais pra onde recorrer, talvez isso ajude.

Se um ransomware encriptar todos os seus arquivos, mesmo no Dropbox vai estar tudo encriptado, mas se tiver o Rewind de alguns dias pra trás, pode tentar recuperar. Isso é ok, mas eu não gosto de depender de um serviço que não tenho controle. Por isso essa mesma pasta de Dropbox está em BTRFS no meu NAS, sendo sincronizado com o aplicativo Cloud Sync da Synology. Eu uso os três, Google Drive, Microsoft OneDrive e Dropbox como backups secundários offsite de alguns dados. E o meu NAS tem snapshots de BTRFS ativado pra até 4 meses pra trás.

Ou seja, isso nunca vai acontecer, mas se por ventura algum malware conseguir passar por mim e encriptar meus arquivos, eu só dou risada, volto alguns snapshots pra trás e mando esse hackerzinho de merda tomar no cú. Não pego malware faz pelo menos uns 20 anos, e sempre tenho múltiplos backups de tudo, tanto local quanto offsite, fora daqui. E os arquivos mais antigos que realmente não quero perder já queimei tudo em Blurays Millenium Disk, feitos de material inorgânico que nunca oxidam. Todos guardados no meu cofre. Vem tentar encriptar meus dados seus hackerzinhos de merda.

Segurança é uma questão de oportunidades. Quanto mais você pensar que nunca vai acontecer com você, maiores as chances de realmente acontecer. Eu penso o contrário, sempre penso que estou 100% inseguro 100% do tempo e faço toda a estratégia em cima disso. Segurança funciona em camadas. Se o plano A falhar, tem o plano B. Se o plano B falhar tem o plano C. Isso se chama contingência. Quem não prepara contingências, sempre vai viver dando desculpas. E eu odeio desculpas. Se desculpas funcionassem, não precisávamos de polícia.

Por fim, um comentário que não coube antes no video é sobre como mantenho meu Manjaro. Uma recomendação que dou é usar muito Docker pros seus projetos. Não precisa instalar coisas como MySQL, Postgres, Redis nem nada local. Use tudo com Docker Compose. Primeiro porque isso garante que estamos rodando a versão certa de cada coisa pra cada projeto. Segundo, porque é menos pacotes instalados na sua máquina que o Manjaro vai precisar ficar atualizando. Quanto mais pacotes instalar, maiores as chances de algum upgrade quebrar alguma coisa.

Pelo mesmo motivo, tudo que é aplicativo como Discord, Zoom, o próprio browser Edge que eu uso, Firefox, e muito mais, eu prefiro instalar via Flatpak. Flatpaks são containers, tipo um Docker light. E dá pra usar coisas como FlatSeal pra garantir que nenhum aplicativo tem mais permissões e acessos do que deveria. Podemos fechar um Discord pra não conseguir enxer nada dos seus arquivos, só deixar ele ver a pasta de Downloads, por exemplo. Depois veja este video explicando sobre Flat Seal.

Eu sei que vai aparecer o povo do NixOS nos comentários, mas eu não pretendo usar e nem preciso. Meu sistema é super estável. Raramente tenho problemas, porque eu instalo o mínimo possível. Pra projetos tá tudo em Docker. Aplicativos tudo em Flatpak ou Snap. E coisas mais arriscadas, como games, ou meus experimentos com LLMs e IAs, estão tudo em máquinas virtuais com QEMU/KVM como mostrei neste outro video. Fazendo tudo que mostrei neste video, não precisei reinstalar meu sistema nenhuma vez e nunca perdi nem dados e nem tempo. Qualquer besteira que eu faço, o Timeshift me salva, qualquer besteira maior e os backups no meu NAS me salvam.

Recapitulando: sempre, sempre, inicie um repositório git local no seu projeto, independente de ter no GitHub ou não. Sempre, sempre, tenha no mínimo um HD externo USB da vida, um pouco maior do que o HD do seu PC, e configure o app de Backup que já vem no seu sistema operacional. Não precisa de nada super fancy nem nada. Só habilita. Qualquer backup é melhor que nenhum backup. Finalmente, se quiser aprender mais de Linux e usar o que há de mais novo, instale Manjaro com suporte a BTRFS e configure o Timeshift como eu expliquei. Isso vai tornar você quase invencível, é praticamente um super poder. Se ficaram com dúvidas, mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal e compartilhem o video com seus amigos. A gente se vê, até mais!

Hoje vamos fechar a minissérie de Introdução a Redes. Meu objetivo todo foi poder falar sobre minha nova solução de armazenamento e edição de videos com NAS e na sequência, como criei uma rede segura pra conseguir acessar coisas como meu Media Server, mesmo estando do meu celular numa rede insegura fora de casa, que é a mesma solução que empresas tem usado pra conseguir dar infraestrutura pra funcionários remotos. Hoje vamos entender como VPNs funcionam.

Conteúdo

• 00:00 - Intro
• 00:44 - Cap 1. Meu Primeiro NAS de backup
• 04:38 - Cap 2. Meu Setup Novo de Gravação
• 07:24 - Cap 3. O Novo NAS
• 14:17 - Cap 4. DNS Privado com Pi-Hole
• 18:31 - Cap 5. Meu “Netflix” Particular
• 21:56 - Cap 6. Recapitulando Redes e dispositivos virtuais
• 27:49 - Cap 7. Redes Seguras com Zero Tier
• 36:57 - Cap 8. Como funciona uma VPN?
• 43:51 - Conclusão
• 45:59 - Bloopers

Links

• WHAT HAPPENED TO GEEKBRIEF TV? (https://www.thegeekpub.com/4173/what-happened-to-geekbrief-tv/)
• Pi-Hole cloudflared (DoH) (https://docs.pi-hole.net/guides/dns/cloudflared/)
• Media Server Setup Pt. 3b: Prowlarr/Sonarr/Radarr (https://morrismotel.com/servarr-pt3b-prowlarr-sonarr-radarr/)
• Jellyfin (https://jellyfin.org/)
• Plex Media Server (https://www.plex.tv/media-server-downloads/)
• Getting Started with Software-Defined Networking and Creating a VPN with ZeroTier One (https://www.digitalocean.com/community/tutorials/getting-started-software-defined-networking-creating-vpn-zerotier-one)
• Docker Networking Overview (https://docs.docker.com/network/)
• Hamachi VPN (https://www.vpn.net/)

SCRIPT

Olá pessoal, Fabio Akita

Finalmente, hoje vou voltar a falar do meu novo NAS e na segunda metade dar mais um tópico sobre redes que me interessa, como acessar meu NAS fora de casa, sem comprometer a segurança da minha rede de casa. Na verdade, eu acho que o objetivo todo dessa mini-série de redes que ando fazendo foi justamente pra chegar no episódio de hoje pra falar do meu NAS novo. De volta aos meus videos sobre armazenamento, lá explico tudo sobre como HDs funcionam e como eu posso configurar vários HDs num único volume pra ter redundância e mais segurança. Se não assistiram, recomendo ver depois. Entender arquivos e entender redes é o mínimo do mínimo que um programador precisa saber.

(…)

Foi lá por 2009 que eu comprei meu primeiro NAS caseiro. Naquela época eu usava Mac e nos primórdios de podcast e webcast eu assistia uma reviewer de tech chamada Cali Lewis, que fez propaganda de uma nova marca muito da hora chamada Drobo. Desde aquela época eles faziam um lance mais inteligente do que RAID normal. Um RAID clássico precisa de HDs de mesma capacidade pra montar o array. Significa que se eu colocar um HD diferente maior, o espaço que sobra ele desperdiça. Mas o Drobo usava um sistema proprietário que conseguia usar o máximo de discos de tamanho diferente. Foi o que me chamou a atenção.

Por quase 10 anos eu usei esse Drobo, primeiro acho que foram uns 4 HDs de 512 GB ou 1 TB cada. Com o tempo eu ia trocando pra HDs maiores um de cada vez. Mas acho que nunca usei nada maior que uns 4 TB por HD. E durante essa quase uma década eu já tive problema de HD realmente falhar e graças ao Drobo eu conseguia só trocar esse HD falhando e ele conseguia se reconstruir sem perder nada. Porém a interface dele acho que era USB 2, com seus meros 480 megabits, o que não dá muito mais que 60 megabytes por segundo.

Mas como era mais pra backup, e não pra acessar o tempo todo, eu deixava fazendo backup a noite, aí não importava tanto se era muito lento. Eu tive uma pane no Drobo inteiro uma vez que ele não ligava mais. Comprei outro Drobo, a versão 5N, que já era USB 3. Só tirei os HDs do primeiro que quebrou, coloquei no novo na mesma ordem, e tudo voltou a funcionar. E com a vantagem que com USB 3 já era até 10 vezes mais rápido que o USB 2. Chegava perto dos 100 megabytes por segundo. Que continua sendo 2 a 3 vezes mais lento que um bom HD mecânico, e pelo menos 4 ou 5 vezes mais lento que um SSD SATA.

Durante a pandemia resolvi experimentar com um novo NAS e peguei um Synology DS420j, de tamanho similar ao Drobo. Depois de mais de 10 anos, o Drobo meio que parou no tempo. O software dele é super limitado e não oferece nada além do básico. Diversas outras marcas como QNap, Synology e mesmo opções open source como TrueNAS pra você montar seu próprio NAS num gabinete de PC evoluíram e deixaram o Drobo no chinelo. Resolvi ver o que os concorrentes estavam fazendo. E o Synology eu achei bacana porque é basicamente um Linux, com Linux Raid rodando mdadm por baixo e suportando filesystems open source como ext4 ou btrfs.

Ele não é tão sofisticado quanto um TrueNAS, que tem ZFS e consegue facilmente suportar armazenamento em nível de data center, com arrays de dezenas de HDs e petabytes de dados. Mas TrueNAS não é pra amadores. Não basta só seguir um tutorial na internet e fazer funcionar da primeira vez. Se você nunca precisou recuperar um TrueNAS com problemas, seus dados vão estar inseguros quando você mais precisar. Não adianta nada um software sofisticado que você vai cometer erros de amador e potencialmente corromper seus dados no meio do caminho. E não adianta só fazer funcionar da primeira vez. O teste de fogo é quando alguma coisa der pane e você realmente precisa recuperar dados. Se nunca passou por isso, considere que vai fazer errado da primeira vez.

Como eu não quero virar administrador de sistemas nem trabalhar em data center, eu queria uma solução que usasse componentes open source que eu confio como Linux Raid, mas com suporte comercial decente e softwares maduros que me ajude a não cometer erros de amador. E a Synology oferece tudo isso. Sim, é mais caro que montar um do zero com TrueNAS, mas é mais confiável, e pra isso eu pago mais caro. Valor é relativo. Não adianta nada ser barato pra montar mas na hora de recuperar dados, você cometer um erro e perder tudo. Aí saiu super caro. Todo amador comete esse erro de só considerar o valor inicial das coisas.

O DS420j foi bacana, mas ele tinha o mesmo problema do Drobo, interfaces lentas. Ele tinha ou USB 3 ou conexão de ethernet 1 gigabit. Como eu disse no primeiro episódio desta série de redes, 1 gigabit é ok. Pra maioria dos casos é velocidade suficiente. Mas por causa do canal, mais e mais eu estava lidando com arquivos de centenas de gigabytes. Eu gravo meus videos em 4K com codec de edição DNxHR, isso dá uma média de quase 100 gigabytes por hora de gravacão. Alguns episódios eu preciso ficar umas 2 horas ou mais gravando, então toda vez da 200 gigas ou mais. E não, se deu vontade de comentar “ah, porque você não grava de jeito X ou jeito Y”, obrigado pelo palpite, mas se eu gravo nesta configuração é porque eu já sei que é a melhor. E isso nem é considerado muito. Estúdios profissionais que gravam em 8K estão acostumados a lidar com terabytes por projeto.

Agora pensa, transferir 200 gigas a uma velocidade de uns 120 megabytes por segundo significa quase meia hora pra transferir tudo pro Synology. 120 megabytes por segundo é quase saturar a conexão ethernet de 1 gigabit. É o máximo que meu Synology conseguia ir. E no Drobo era mais lento ainda. E isso só pra fazer backup. Eu precisava ter terabytes de SSD no meu PC pra editar isso. Pra editar video 4K desse tamanho, HD mecânico é muito lento. E assistindo videos de outros youtubers como Linus Tech Tips, MKBHD e outros eu sabia que todos editam videos direto dos NAS deles, usando redes acima de 2.5 gigabits.

Em 2021 eu atualizei meu equipamento de gravação. Antes minha câmera Sony A7III gravava em SD cards. Mas ele tem aquela maldita limitação de parar de gravar automaticamente depois de 30 minutos. Toda câmera fotográfica faz isso por causa de mais uma maldita lei da Europa. Europeu é campeão de criar leis imbecis. De qualquer forma SD cards não são confiáveis e um dia tive problema de corromper meus arquivos e perdi um episódio. Cansado dessas limitações eu comprei um Atomos Ninja V. Agora ligo a saída HDMI da minha câmera nesse Atomos, que por sua vez tem um SSD SATA e ele grava direto do HDMI em arquivo no SSD, sem limitações. Isso resolveu o problema de video. De novo, se tava indo comentar “porque não grava direto no PC”, novamente, pra mim não era uma boa solução. Obrigado pelo palpite.

Daí um belo dia meu gravador de áudio, que era uma Tascan velha, comecou a dar pau e mastigar os arquivos de áudio. Cansei dele e comprei um gravador novo, um Zoom H5. Agora ele grava tanto em SD card, mas eu ligo a saída de áudio na entrada do Atomos, então o Atomos grava tanto o video da câmera quanto o áudio do gravador tudo junto e eu ainda tenho uma segunda cópia no gravador, via SD Card. Daí resolvi o audio também.

Agora eu queria resolver a edição e backup dos videos originais. E sim, eu guardo e sempre vou guardar os originais. Novamente, não precisa ir nos comentários dizer pra apagar os originais pra economizar espaço. Um profissional nunca joga fora originais. E pra isso eu queria transferir os arquivos do SSD do Atomos direto pro meu NAS em rede 10 gigabit. 10 gigabit seria um pico de mais de 1 gigabyte por segundo. E esse meu Synology DS420j que é um modelo caseiro, não oferece upgrade de hardware, tipo colocar placa de 10 gigabits. Então resolvi que era hora de investir num NAS profissional, o modelo DS1821+. A série que termina com “j” acho que é de entrada, é bom pra quem tá começando. A série 21 plus é profissional. Tem modelos ainda maiores, mas pra mim esse seria suficiente.

Pra começar, esse modelo tem 8 baias de HDs. Então decidi ir all in e comprar nada menos que 6 HDs Seagate IronWolf de 12 Terabytes. IronWolf são HDs feitos pra NAS, eles tem mais durabilidade, aguentam mais vibrações, tem cache maior. É como um HD caseiro, tipo modelo Barracuda, mas muito mais resistente, e obviamente mais caros. Liguei os 6 no novo Synology, e montei um volume com 5 deles em modo SHR que é Synology Hybrid RAID. Em vez de um RAID normal que exige HDs de tamanho igual, ele consegue aproveitar o espaço de HDs diferentes melhor de um jeito proprietário dele. Lembra o que eu falei que o Drobo fazia? Hoje em dia outros fabricantes já superaram. No meu caso, isso virou um volume de 42 terabytes, e o 6o HD fica desligado como hot spare. Se um dos 5 HDs falhar, o NAS automaticamente desliga o que falhou, liga o hot spare no lugar e começa a reconstruir o volume sem perder nada.

E como é pra ir all in, resolvi fazer todos os upgrades que esse modelo permite. Coloquei 2 NVMEs de 1 terabyte cada dedicados só pra ser cache. Assim arquivos mais acessados ficam no NVME, em vez de ter que ir nos HDs mecânicos. E nem é muito que precisava porque apesar de serem HDs mecânicos e muita gente ficar me perguntando se um RAID feito com SSDs não seria mais rápido. A resposta deveria ser óbvia: não, o custo simplesmente não compensa. Mas na cabeça de vocês, se imagina que porque estou lidando com HDs mecânicos, vai ser mais lento que um SSD. E é aí que estão errados. Em IOPS talvez, mas em velocidade não. Cada HD desses é capaz sozinho de mais de 200 megabytes por segundo.

Lembra da explicação de dispositivos de bloco e como arquivos são divididos em blocos e como esses blocos são dividos nos vários HDs de um RAID? Cada HD no RAID contribui com mais ou menos metade da velocidade pra leitura e escrita. Então cada um contribui com pelo menos 100 megabytes por segundo pra velocidade total, indo pra mais de 500 megabytes por segundo. Pra dar perspectiva isso é mais de 4000 gigabits. E eu estou arredondando por baixo, em benchmarks eu estou conseguindo ir até 6000 ou 7000 gigabits. Sua rede cabeada de casa é só 1 gigabit, mas na minha que é 10 gigabits, consigo suportar isso.

Pra conseguir essas velocidades na rede eu comprei a placa de rede 10 gigabits e comprei cabos de rede cat 6a com conectores blindados. Não adianta nada placa de rede boa com cabos que não aguentam a velocidade. Se eu falei que consigo ir na faixa acima de 7000 gigabits por segundo, às vezes 8000, significa que estou usando a maior parte do que minha rede consegue. E pra tudo falar nessa velocidade, também comprei uma placa de 10 gigabits pro meu PC e um pequeno switch TP-Link que suporta 10 gigabits em todas as portas.

Aliás, cuidado com switches com marketing duvidoso. Eu vi caixas de switches baratos dizendo que suportam 5 gigabits, e tem 5 portas, aí você pensa que cada porta suporta 5 gigabits, mas não, em letras miúdas eles falam que o aparelho suporta até o máximo de 5 gigabits ou seja, cada porta é só 1 gigabit. No meu caso são 5 portas de 10 gigabits cada, então o aparelho todo suporta 50 gigabits. E isso é importante, porque lembra todo o processamento de checagem de erros, roteamento e tudo mais que um switch precisa fazer? Tudo isso exige CPU que consiga processar o tráfego de 50 gigabits por segundo. Ele fica bem quente quando tá ligado trabalhando.

Finalmente, o último upgrade desse all in foi trocar os 4 gigabytes de RAM que o DS1821 vem e colocar 16 giga de RAM ECC, que tem correção de erros, pra evitar single event upset de raios cósmicos, por exemplo, como expliquei no segundo video da série, de correção de erros. Minha memória ECC provavelmente tá rodando Hamming Code, pra recuperar qualquer bit flip acidental. Tudo isso pra garantir que nenhum dado nessa caixa seja corrompida de jeito nenhum.

E agora sim, eu consigo gravar os videos crus depois da gravação direto pro NAS em velocidade máxima e consigo usar o DaVinci Resolve pra editar videos direto do NAS, sem precisar ter nada em SSD local. Vou te falar que a qualidade de vida é incrível, meu fluxo de trabalho fica bem mais fácil. Isso tudo já é equipamento que um pequeno estúdio de gravação teria, pra ter 2 ou 3 editores de video trabalhando direto do NAS. Pra estúdio maior, eles teriam racks de HDs, cada uma com mais de uma porta de 10 gigabits, talvez numa rede de 100 gigabits por segundo. Nos videos do Linus ele tem o projeto petabyte, onde montam rack com TrueNAS e dezenas de HDs ou SSDs com ZFS que suportaria uma dúzia de editores de video tudo trabalhando por rede 2.5 gigabit, lidando com videos 8K de terabytes de tamanho. O que eu montei é a versão junior disso.

Dá pra ir muito longe. Mas isso foi só pra solucionar meu fluxo de trabalho de video que, honestamente nem é tão pesado assim. Eu sou o único editor e faço tudo sozinho. Portanto sim, esse investimento foi bem mais do que eu precisaria. Só pra ter uma idéia, o NAS, os HDs, os upgrades de SSD, rede e RAM, deram um total de bem mais que 30 mil reais. Se fosse lá fora teria custo fácil mais de 3 mil dólares. Em dólar nem parece tão caro. Um computador moderno como um Mac Studio custa mais que isso. Mas falando em reais, sim, é um terço de um carro popular. Qualidade é proporcional ao preço.

Mas, eu não ia usar só pra videos. A vantagem desse NAS é que ele vem com um bom processador, um AMD Ryzen quad-core de 2.2 Ghz cada. Não chega nem aos pés dos 16 core que meu Ryzen 9 5850 do meu PC tem, mas pra um NAS tá sobrando. Um NAS é nada mais, nada menos, que um PC com Linux. Na teoria você não deveria, mas pode rodar qualquer outro software dentro dele.

Não deveria porque a função de um NAS é ser dedicado a lidar com arquivos. Num ambiente onde outras pessoas estivessem trabalhando e puxando arquivos o tempo todo pra editar, a CPU ia ficar trabalhando só pra entregar os blocos o mais rápido possível. Fora que você não quer que, por acidente, um aplicativo com bug acabe corrompendo seus dados. Então nunca rode nada diferente num NAS de trabalho. Mas como é meu NAS caseiro onde eu sou a única pessoa com acesso, quis aproveitar o processamento sobrando pra mais coisas.

O software da Synology já suporta Docker nativamente, com interface gráfica facinha de usar e acesso a terminal via ssh se eu quiser rodar manualmente. Então comecei a fuçar coisas pra rodar nele. Em outro episódio vou finalmente explicar mais detalhes sobre Docker e containers, mas por hoje entenda Docker como uma forma fácil, controlada e isolada de instalar software no meu NAS sem grandes riscos.

Vamos recapitular o básico de redes. Toda vez que eu navego em sites, normalmente não me preocupo porque todos oferecem HTTPS, então tudo que trafega entre meu navegador e o site é criptografado. Mas isso é depois que já sei o endereço IP do site. Pra saber o endereço IP baseado no domínio como google.com ou apple.com, alguém precisa me dizer que apple.com é o IP x.y.z. E quem sabe disso é um DNS, lembram?

No terceiro episódio da série eu disse que meu PC ganha endereço IP privado atrás de um NAT graças ao serviço de DHCP do meu roteador, que funciona como um síndico do prédio. Eu ligo meu PC e ele pergunta pro síndico, “ow, que endereço ip tem sobrando pra mim”, e o DHCP responde “tem esse 192.168.1.200, beleza?” e aí o PC assume esse endereço. Junto com o endereço vem outras configurações, como o endereço de DNS, que eu disse pra mudar pra ser 1.1.1.1 da CloudFlare ou 8.8.8.8 do Google e evitar usar o DNS que o provedor já pré-configurou pra você caso se preocupe com privacidade, porque DNS de provedor não oferece DoH, que é DNS over HTTPS.

O navegador abre conexão encriptada via TLS com o site depois que sabe o endereço ip do site, mas a requisição pro DNS, perguntando “qual ip que é apple.com” vai em texto puro, aberto, sem criptografar. E se você deixou o DNS do provedor, ele sabe que sites você navegou, que horas, a partir de qual lugar. Não chega a ser nenhuma informação tão crucial assim, mas pra quem se importa com privacidade, é mais uma informação sobre você que está vazando. Tem gente que diz “foda-se” e tudo bem, não precisa comentar isso, seu palpite é irrelevante. Estou falando com quem se importa.

Não só isso. A gente usa plugins de adblock pra bloquear propagandas em sites, mas eles não conseguem pegar tudo sempre. Toda ajuda a mais é bem vinda. Por tudo isso resolvi que o primeiro container que queria instalar no NAS seria do aplicativo Pi-Hole. Ele se chama assim porque foi originalmente feito pra instalar num raspberry-pi, que é como eu usava antes. Mas ele é levinho e mover pro NAS significa um equipamento a menos que preciso dar manutenção.

O Pi-Hole é um servidor de DNS e que oferece uma aplicação web pra dar um monitoramento gráfico pra gente. O que eu faço é configurar pra usar o DNS da CloudFlare 1.1.1.1 e ele faz cache de tudo. E ele também se sincroniza com alguns bancos de dados mantidos pela comunidade de domínios reconhecidos como sites de propaganda ou mesmo de malwares. Daí se algum site onde navego pede alguma coisa desses domínios, o Pi-Hole rejeita e não me deixa navegar pra lá.

Daí o que eu faço é colocar o endereço IP do NAS como DNS no DHCP do meu roteador. Daí todos os equipamentos de casa, meu PC, minhas TVs, meus consoles de video game, meu celular, até minhas lâmpadas inteligentes, recebem a mesma configuração e passam a usar o Pi-Hole como servidor de DNS. A outra vantagem é que ele consegue fazer requisições de DoH ou DNS over HTTPS. Lembram que eu falei que toda requisição de pergunta pra DNS vai em texto aberto? Com DNS over HTTPS ele primeiro abre uma conexão segura via HTTPS e manda a pergunta criptografada. Agora tudo é criptografado, dificultando alguém saber meu padrão de navegação na web.

Pra isso precisei de um segundo container de Docker, oferecido pela própria Cloudflare, que é o serviço cloudflared. Lembrando que “d” no final é de daemon. Não vou entrar em detalhes porque a documentação diz tudo que precisa saber mas o container em si já vem pré-configurado apontando pros servidores de DNS que suportam HTTPS da Cloudflare. Daí eu aponto meu Pi-Hole pra esse daemon e pronto, meu navegador pergunta pro Pi-Hole, que abre uma conexão segura com a Cloudflare e resolve o domínio via HTTPS e nesse percurso, ninguém no meio do caminho, incluindo meu provedor, conseguem saber em quais sites estou navegando. Se gostaram da solução, vou deixar links pro que falei na descrição do video abaixo.

O próximo container eu falei um bocado nas stories do meu Instagram então quem acompanhou sabe. Faz décadas que venho baixando animes, série e filmes. Tem coisas que eu assistia nos anos 80 e 90 e que não existem mais em nenhuma plataforma de streaming de hoje, em particular animes antigos. Tem outros que existem no Japão, mas nunca vieram pro Ocidente. Enfim, tem milhares de conteúdos que se você só assiste Netflix, nunca ficou sabendo que existe. Aliás, a seleção do Netflix é bem ruim e incompleta. Sinto pena de quem só conhece o que tem lá.

Sim, tecnicamente é pirataria. Não estou incentivando mas eu também acho que quem quer piratear vai piratear independente. Avisar que não pode nunca fez nenhum efeito. É que nem foto de câncer em pulmão em caixa de cigarro. Isso nunca funcionou, como ex-fumante eu sempre ignorei completamente aquilo. Cada um é adulto e lide com as consequências. Quer fumar, fume. Só não incomode os outros. Quer piratear, pelo menos pirateia direito.

Que atire a primeira pedra quem nunca baixou nada via bittorrent. Em outro episódio falo sobre ele, mas por hoje, todo mundo pelo menos sabe que é o melhor jeito de piratear. Eu sou da época do LimeWire, eDonkey, Kazaa, Napster e outros, mas bittorrent é animal. E existem softwares open source como Jellyfin, Radarr, Sonarr e Prowlarr que fazem o seguinte.

Jellyfin é um projeto em cima de outro conhecido, o Emby, é basicamente um software que organiza sua mídia, videos, música e tudo mais numa interface parecida com da Netflix, com tocador e tudo mais. Vale a pena pesquisar. Ele vasculha suas pastas de mídia e faz índice, baixa capas dos filmes, notas do Rottentomato, informações de elenco num IMDB e organiza bonitinho pra você.

Mas você ainda tem que ficar baixando as coisas manualmente, renomeando, colocando nas pastas certas. E se desse pra ser tudo automático? É pra isso que servem o Radarr, Sonarr e Prowlarr. Você pode assinar o RSS de bittorrent de séries que ainda estão saindo e o povo de fansub ainda tá legendando, e quando ficam disponíveis, baixa sozinho pra você, renomeia, baixa capa e tudo mais e quando você liga a TV, já está organizado no seu Jellyfin. Dependendo da série que tá acompanhando, se for muito famosa, no mesmo dia que saiu na Amazon Prime, algumas horas depois já aparece no seu Jellyfin. É literalmente como se você tivesse seu próprio Netflix particular, só que melhor.

Hoje não vou mostrar como configura tudo isso mesmo porque eu sou das antigas e uso mais pra baixar coisas que não se encontra fácil. Séries novas eu prefiro assistir direto dum Crunchyroll da vida. Eu assino todos os serviços de qualquer forma. Mesmo filmes que gosto muito compro em Blu-Ray, então quando baixo, normalmente já tinha comprado, só baixo porque é mais fácil pra assistir. E em vez de Jellyfin, prefiro usar o Plex. Ele é meio chatinho com planos pagos e tudo mais, mas é o que tem a interface mais bem feita, melhores apps pra celular e TV, e realmente funciona igual uma Netflix. Dêem uma olhada. Eu tenho séries de anime, ele organiza as temporadas, episódios que já assisti, posso começar a assistir no PC e continuar na TV, perfeito.

O único problema é que ele só funciona dentro de casa, na minha rede local. O Plex é o concorrente do Jellyfin, Emby, Kodi e outros, tem planos pagos se eu quiser acessar de fora, mas digamos que prefira continuar usando só os recursos gratuitos, como faço pra poder assistir meus animes quando estiver viajando, na casa dos meus pais ou em qualquer lugar fora de casa?

E agora vem a última coisa que queria explicar de redes pra vocês. Por causa da pandemia, muita gente ganhou a opção de trabalhar remotamente de casa e aqui o problema é oposto. Como você faz pra poder ter acesso a servidores da empresa por exemplo? É aqui que entra a solução de uma VPN, Virtual Private Network ou redes virtuais privadas.

VPN existem diversos tipos e de novo,não sou especialista em redes então quero compartilhar com vocês só o básico. Até aqui a gente sempre assume que redes funcionam com dispositivos de hardware como placas de rede, que fisicamente tem um buraco pra espetar um cabo ethernet com conector RJ-45. Ou uma placa Wifi que você conecta num ponto de acesso. Mas em ambos os casos se trata de dispositivos físicos de hardware.

Pro sistema operacional falar com esses e outros dispositivos eles precisam de um pedaço de software chamado driver. Esses drivers normalmente são carregados juntos com a kernel do seu sistema operacional, seja Linux, Windows, Mac, Android, iOS, não importa. Se tem um hardware, a kernel precisa de um driver. Num Windows você enxerga os dispositivos no gerenciador de dispositivos e pode ver detalhes, tentar atualizar os drivers por lá e tudo mais. Em Linux pode usar comandos como lspci pra listar os dispositivos ligados no bus ou barramento de PCI. Enfim, o importante é a kernel conseguir enxergar todos eles.

Mas tecnicamente pro sistema operacional, meio que não importa se o hardware existe de verdade, contanto que exista um driver que diz que existe. Presta atenção. Um driver pode mentir pro sistema. É o que acontece quando se instala uma máquina virtual com um VirtualBox da vida. Dentro dela manda instalar o Windows e ela vai instalar drivers que dizem pra esse Windows que tem uma placa gráfica, embora não tenha hardware disso. O driver está emulando um hardware e desenhando na janela do VirtualBox. O Windows virtualizado acha que é uma placa de verdade. Ele não tem como saber a diferença, ele tá dentro da Matrix. E isso acontece com todos os dispositivos. Dentro da máquina virtual os drivers dizem que tudo existe, mas na prática os drivers conversam com o VirtualBox do lado de fora e assim possibilita compartilhar meu teclado de verdade, mouse, som e tudo mais.

E se fosse possível eu ter placas de redes virtuais? E aqui entra os conceitos de TUN e TAP. Lembra a idéia que pacotes de rede são divididos em camadas? No modelo OSI temos camada 1 que é física, camada 2 que é data link, que é o que ethernet se preocupa, tem a camada 3 que é network que é onde a parte IP de TCP/IP se preocupa. Na prática TUN é um dispositivo de rede virtual que atua na camada 3 de rede e TAP cria um dispositivo de rede virtual que atua na camada 2. Isso é uma tecnicalidade que pra gente não importa muito, mas só pra saber. Nos diversos componentes de uma infraestrutura de rede, cada um lida com pacotes em camadas diferentes. A gente que é programador acaba só lidando com camada de aplicação, mas coisas como placas de rede ou switches atual da camada 3 pra baixo, não se importando com as camadas superiores.

Numa máquina virtual, se instala um driver de rede, pra simular que existe rede, e o Windows virtualizado fala com uma placa que não existe, um TAP, que por baixo cria um bridge, ou ponte, entre essa placa virtual e a placa real do PC que é host. Graças a essa placa virtual, dentro da máquina virtual ele ganha um IP tipo 172 ponto alguma coisa. E tudo que é roteado por essa placa, chega na placa real e é roteado pra internet. Na prática é como se existisse uma nova sub-rede privada dentro da rede interna.

Eu uso VMWare na minha máquina, e se abrir as configurações avançadas de rede, olha só o que eu acho, várias placas de rede. Quase todas virtuais. Essa Ethernet aqui é a minha placa de 10 gigabits de verdade que falei antes. Essa outra é a de 2.5 gigabit que vem embutida na placa mãe. Só essas são as de verdade. Mas essas outras aqui são placas virtuais pra coisas como minhas máquinas virtuais. Mesmo num Docker você pode subir container em dois modos de rede, host ou bridge. Se for host, vai subir como se fosse qualquer outro programa no seu PC, usando as mesmas configurações de rede local. Mas se escolher bridge, o container vai falar com uma placa de rede virtual TAP, que vai criar uma sub-rede separada, e rotear os pacotes por essa ponte até meu PC host.

A vantagem de usar bridge é o seguinte. Digamos que eu suba dois containers de web, que internamente vai carregar um programa servidor web que quer se conectar na porta 80. Ambos estão em modo host. O primeiro vai carregar e se pendurar na porta 80 do meu PC. Mas o segundo container vai falhar, porque vai tentar se conectar na porta 80, mas já tá ocupado, então o sistema operacional recusa e rejeita o pedido do container. Agora, se rodar ambos em modo bridge, eles ganham uma rede vazia com outro range de endereços IP estilo 172 alguma coisa que do lado de fora ninguém enxerga. É como sua rede 192.168 local que do lado de fora ninguém enxerga por causa do NAT.

Cada container, nessa rede 172 privada, consegue se ligar na porta 80 interna do container, porque é como se estivessem numa máquina vazia com uma placa de rede só pra eles. Mas do lado de fora podemos mapear a porta 80 de dentro do container com a porta 8080 de fora do meu PC, e o segundo container sube na porta 80 interna e podemos mapear pra porta 8081 do mesmo PC. Ambos os programas acreditam que estão sozinhos, conseguem ligar em portas 80 virtuais, mas do lado de fora estamos remapeando as portas virtuais pra outras portas livres de verdade. Máquinas virtuais e containers são formas de eu mentir pros programas acharem que estão rodando numa máquina sozinhos. E do lado de fora eu controlo o que quero expor pra elas. De novo, containers de Docker estão na Matrix e não sabem disso.

Não são só tecnologias de virtualização e containers que usufruem de placas de rede virtuais. E agora entra os TUN que significa tunel. A parte que eu falei em outros episódios que não queria explicar é roteamento e agora vou mostrar só o mínimo pra vocês entenderem onde quero chegar. Eu mostrei já no episódio 3 desse mini-série como pacotes conseguem sair da minha rede pelo roteador do provedor e ir pra internet. E mostrei rapidamente uma tabela de rotas. Todo sistema operacional com TCP/IP mantém uma tabela de rotas.

Ela que diz pra mandar todo tráfego pro roteador, que costuma ter o endereço IP mais baixo da sub-rede interna como 192.168.1.1 ou 10.0.0.1 ou algo assim. No meu caso é esse TP-Link que deixo do lado do modem. Ele recebe os pacotes e também tem uma tabela de rotas como essa só que no caso dele a saída padrão é mandar pro modem, e o modem por sua vez passa pra frente pra outros servidores na internet. Essa é a tarefa de um default gateway, a porta padrão de saída.

Lembra no episódio anterior onde mostrei o exemplo onde estou numa rede de empresa rígida que restringe uso da internet e fecha quase todas as portas e nem deixa eu navegar em todos os sites? E como usando um servidor da Digital Ocean eu furei um buraco no firewall e abri um túnel seguro encriptado usando SSH? Uma VPN é um programa diferente de SSH mas em conceito funciona parecido, furando buraco em firewall ou no meu caso no CGNAT da Vivo, se conectando num servidor de fora e abrindo um túnel.

Mas em vez de eu abrir o túnel manualmente com o comando SSH uma VPN costuma instalar uma placa de rede virtual TUN. No caso de Linux cria um dispositivo como /dev/tun. Esse dispositivo ganha um endereço IP inválido de internet como 172 alguma coisa. E o software de VPN faz mais uma coisa, cria entradas nessa tabela de roteamento que falei.

Dá pra configurar de varias formas. Por exemplo, posso adicionar na tabela que toda vez que do meu PC de casa eu tentar acessar um IP que só existe na rede da empresa, os pacotes são direcionados não pra minha placa de rede de verdade, mas sim pra esse dispositivo virtual TUN que na realidade é um tunel criptografado ligado no servidor de VPN da empresa.

Vamos dar um exemplo. Como já falei existem dezenas de formas diferentes de VPN. Existe OpenVPN, existe Microtik, soluções baseadas em Wireguard como Tail Scale, mas eu escolhi usar a Zero Tier, que achei simples, fácil de usar, e resolve o meu problema de expor meu Plex de anime fora de casa. Pra começar crio uma conta lá e uma nova rede. Essa rede tem um código identificador que, obviamente estou escondendo uma parte. Ela começa com a84.

Agora vou no meu NAS e instalo o docker da ZeroTier, que é um programa cliente que vai se conectar no servidor deles. Seja no meu NAS, seja num PC com Linux, primeiro preciso carregar o driver pra criar o tal dispositivo virtual de TUN. Eu me conecto no NAS via SSH e, como root, crio o seguinte script:

echo -e '#!/bin/sh -e \ninsmod /lib/modules/tun.ko' > /usr/local/etc/rc.d/tun.sh chmod a+x /usr/local/etc/rc.d/tun.sh /usr/local/etc/rc.d/tun.sh ls /dev/net/tun /dev/net/tun

Estou só escrevendo um arquivo com o comando insmod e o caminho pro módullo de tun pra kernel carregar. Na sequência estou dando permissão pra esse script executar. Eu falei nos videos de Ubuntu pra estudar chmod e permissões lembram? Daí rodo da primeira vez manualmente, no próximo boot já vai carregar sozinho. No final checo se o dispositivo virtual apareceu com o comando ls pra listar e de fato, tá lá. Agora tenho o equivalente a uma placa de rede virtual, de mentira.

Ainda do terminal, agora baixo e rodo o container da zerotier que é um programa cliente que vai se conectar no servidor deles, furando um buraco em firewall e CGNAT. Relembrando, o conceito de furar é porque do lado de fora, meu PC é inacessível por conta de firewall ou NAT do provedor. O servidor da ZeroTire não tem como abrir uma conexão comigo. Mas eu consigo me conectar com o servidor deles. Pra entrar está bloqueado, mas pra sair está liberado. Agora que eu abri a conexão, o servidor da ZeroTier consegue falar de volta comigo por essa mesma conexão. Isso que significa “furar”.

docker run -d \ --name zt \ --restart=always \ --device=/dev/net/tun \ --net=host \ --cap-add=NET_ADMIN \ --cap-add=SYS_ADMIN \ -v /var/lib/zerotier-one:/var/lib/zerotier-one zerotier/zerotier-synology:latest

Nessa configuração eu faço esse container enxergar o dispositivo TUN que acabamos de criar, configuro rede pra ser host, ou seja, sem ser ponte, configuro um volume externo pra configuração que é onde o container vai gravar coisas que ele precisa e que não podem desaparecer se o container bootar. E é isso. Quando terminar de subir vai se conectar e vai ganhar um número identificador da zero tier.

Ainda pelo terminal, posso mandar comandos pra esse container e o que preciso fazer é mandar se conectar naquela rede da ZeroTier que criei que começa com a84 lembra? É um numerozão. Se você se registrar no site e criar uma nova rede, obviamente o número vai ser diferente. Então vamos conectar esse cliente que instalei via Docker com minha rede privada no servidor da ZeroTire.

docker exec -it zt zerotier-cli join e5cd7a9e1cae134f

Pronto. Do lado do NAS é só isso. Agora vou no meu celular e no meu PC e baixo o aplicativo da ZeroTier e instalo nos dois. É o equivalente ao docker que instalei no NAS, um aplicativo cliente da ZeroTire. No meu celular abre esse aplicativo feioso aqui. Mesma coisa, eu clico em Add Network e cadastro a mesma rede que começa com a84 e já posso conectar nela. No meu PC depois que instalei e rodei, aparece aqui embaixo na barra de tarefas. Mesma coisa, me junto na mesma rede. Note que em cada dispositivo diferente ele tem um outro número identificador. No meu celular lá embaixo tem esse outro número que eu escondi que começa com eeb, é o identificador do meu celular. E no app do PC mesma coisa, ele tem esse “My Address” que começa com 3d7.

Pronto, todo mundo configurado e conectado na mesma rede da minha conta na Zero Tire. Último passo, volto pro site, abro a configuração da rede a84 e lá embaixo vai ter uma lista de dispositivos que se conectaram. E olha só, meu PC que começa com 3d7 apareceu, meu NAS que começa com d46 aparece e meu celular que começa com eeb apareceu. Agora só preciso autorizar todos com esses checks do lado e pronto. Tá todo mundo conectado na mesma rede privada. Nessa nova sub-rede todo mundo tem endereços 172.22 ponto alguma coisa. Por exemplo, meu NAS ganhou o endereço 172.22.61.42, o mesmo vale pra todos os dispositivos, cada um com um endereço IP. Esses endereços não são válidos na internet, só dentro dessa rede privada.

Agora vamos entrar no meu celular com o ZeroTier desligado. Se eu abro o app do Plex, que não pago a assinatura, olha que tristeza. Vazio. Vamos fechar, abrir o ZeroTier e conectar na rede dele. Agora abro o app do Plex de novo e voilá!! Olha aqui minhas bibliotecas, e todos os meus animes bonitinho aparecendo! Estou via 4G, fora do Wifi de casa. Estou conseguindo falar com o docker de Plex no meu NAS porque estamos conectados na mesma sub-rede privada da ZeroTier via VPN.

Mesma coisa no meu notebook. Se estivesse fora de casa, em vez de usar o endereço IP da minha rede que é 192.168 ponto alguma coisa, ligo o ZeroTier e no navegador digito aquele endereço 172.22 porta 32400 e olha só, estou navegando no Plex de dentro do NAS, mesmo estando fora da minha rede. Mas como isso é possível? E aí vem o truque que a ZeroTier e outros softwares de VPN fazem. Vamos abrir o terminal do Windows.

Digitando route print -4 pra mostrar rotas de ipv4, tenho rotas pra todo endereço 192.168 interno da minha rede. É com essa tabela que ele sabe pra onde mandar pacotes. Mas depois que habilito o ZeroTier, podemos rodar o comando de route de novo e vemos que adiciona novas entradas nessa tabela. Olha só, ele passa a reconhecer endereços 172 ponto alguma coisa e o default gateway é esse dispositivo 172.22.121.226. Vamos de volta na janela de configurações avançadas de rede do Windows, onde lista dispositivos de rede e olha aqui o dispositivo virtual TUN da ZeroTier. É como se fosse uma placa de rede normal, mas ela não existe, é o driver mentindo pro Windows, ela é virtual.

Botão direito e propriedades. Vamos ver que configurações de IPV4 ele tem e olha o endereço, 172.22.121.226, que é o default gateway que registrou na tabela de roteamento. Por isso que toda vez que tento navegar, por exemplo, pro meu Plex, com o endereço 172.22.61.142, o sistema pega os pacotes, manda pro dispositivo virtual, que por sua vez é só um software cliente que tá conectado no servidor da ZeroTier. Ele faz forward desses pacotes, ou seja, redireciona pra fora, pra ZeroTier. E no mesmo servidor está conectado o cliente de docker que instalei no NAS, que recebe os pacotes por essa conexão.

O que eu tinha mostrado de abrir túnel SSH no episódio anterior é o modelo que se chama de client to site ou acesso remoto. Mas nesse caso eu tenho dois clientes atrás de uma rede privada conversando como se estivessem na mesma rede, ambos com clientes conectados num servidor de VPN, é o modelo site to site ou gateway to gateway. Depois estudem esses termos. Mas na prática, essa solução da ZeroTier cria um túnel criptografado entre meu celular ou meu notebook com o NAS usando um serviço no meio que permite burlar as restrições de cada uma das redes, seja firewalls, seja CGNATs.

Isso que mostrei da ZeroTier é uma solução boa quando você precisa acessar um servidor específico na sua casa ou na empresa, dentro de uma rede privada virtual. Mas isso deve soar um pouco diferente do que você já deve ter ouvido falar de VPN. Se eu tentar navegar na Web, esse tráfego não vai pra ZeroTier. Só endereços 172.22 que vão ser enviados pelo túnel, todo o resto é roteado normalmente pela sua rede local, sem mudar nada.

O que você conhece de VPN é o contrário, que todo tráfego Web passa pelo túnel da VPN e sai pelos servidores deles. Muita gente que vê propaganda de VPN pensa neles como uma forma de burlar o filtro de região de sites como Netflix ou Amazon Prime pra conseguir assistir séries que não passam no Brasil. Ou o uso mais correto que é conseguir navegar com segurança mesmo quando estiver em redes não-confiáveis como o Wifi do Starbucks.

Falando sobre redes públicas, obviamente, nunca, jamais, digite sua senha de qualquer coisa enquanto estiver conectado em rede da faculdade, do aeroporto, do starbucks ou o que for. Lembra no terceiro episódio da minissérie quando falei sobre o problema de hubs, modo promíscuo e tudo mais? Você não sabe quem está escutando seus pacotes numa rede aberta. Sempre que estiver numa rede pública, use uma VPN pra acessar coisas como seu banco. Assim você garante que vai estar tudo criptografado e mesmo se tiver alguém fuçando seus pacotes de rede, não vai conseguir ler nada. Se usa um celular android da Samsung, eles já tem embutido um serviço de VPN barato que ativa automaticamente quando se conecta em Wifi público. Recomendo testar se puder, mas qualquer um serve. NordVPN, ExpressVPN, qualquer um.

O que acontece quando você usa um cliente de VPN? Por acaso eu uso o NordVPN. Ele oferece opção de se conectar em servidores que eles mantém pelo mundo todo. Então vou me conectar num dos Estados Unidos. E pronto, conectado. Agora navego na web normalmente e parece que nada mudou. Vamos praquele site que mostra qual é meu ip, what is my ip. E olha só, fala que o endereço que ele enxerga de mim é um endereço nos Estados Unidos. Justamente porque todos os pacotes da minha máquina estão sendo tunelados pra um servidor da NordVPN nos Estados Unidos e de lá indo pros sites que quero navegar. Do ponto de vista dos sites, é um computador nos Estados Unidos que tá conectado.

Foi isso que fizemos com SSH no episódio anterior, lembra? Local Forwarding? É a mesma coisa, só que mais fácil de usar em vez de ter que digitar aquele comando grande no terminal. Mas o que de fato tá acontecendo? Pra isso vamos abrir a tabela de rotas de novo na linha de comando com route print. Veja a primeira linha e a última linha. Estou simplificando mas ele basicamente diz pra qualquer endereço IP que quero acessar de 0 até 255, pra mandar pro default gateway 192.168.1.1 que é meu roteador como mostrei no terceiro episódio. Mas agora vamos ver quando estou conectado na NordVPN.

Olha o que apareceu. Logo no começo e lá no final da tabela de rotas, agora tem novas entradas apontando pra interface 10.5.0.2. E quem diabos é isso? Ainda na linha de comando digitamos ipconfig /all no Windows pra ver todos os dispositivos de rede e olha só. Tem um dispositivo NordLynx Tunnel. Um dispositivo virtual de rede. O Windows acha que é uma placa de rede, mas não tem hardware por baixo. Ele cria um túnel e roteia os pacotes pela minha placa de rede de verdade, só que criptografado e sempre pro servidor que eu conectei na rede da Nord.

Como que o sistema operacional decide se deve mandar pacotes pra rota anterior do meu roteador 192.168 ou mandar pra rota nova da VPN em 10.5? É por causa desse número de métrica aqui no fim, que é um número de prioridade. Ele vai mandar pro menor número. E de curiosidade, esse “on-link” significa que são endereços que podem ser resolvidos localmente, sem precisar rotear pra fora. Claro, são dispositivos virtuais locais, estão na mesma máquina. Tem um tanto de outras rotas aqui mas é porque meu PC tem máquinas virtuais instaladas, e elas também tem placas de rede virtuais que precisam ser roteadas. Na sua máquina, vai ser uma tabela diferente, mas o princípio é o mesmo, a primeira coisa que vai ter é a rota pro seu roteador. É assim que os pacotes saem da sua máquina e sabem pra onde ir.

Toda vez que você aperta o botão pra conectar na VPN, o que acontece por baixo dos panos é que ele adiciona essas novas entradas na tabela de roteamento. Quando desconecta, apaga essas linhas, aí seus pacotes voltam a trafegar pelo seu roteador como sempre. É isso que um cliente de VPN faz, cria um dispositivo virtual e reconfigura sua tabela de rotas pra desviar os pacotes por esse dispositivo virtual.

Mas voltando pra conversa da ZeroTier e meu servidor de anime. Sem uma solução de VPN, todos esses dispositivos não conseguiriam se conectar através da internet, só seriam acessíveis na mesma rede local, no caso, dentro da minha casa. Mas agora meu NAS fica sempre conectado na rede da ZeroTier, esperando pacotes virem de lá até a placa de rede virtual TUN que criamos, e a partir daí, pro resto do sistema e aplicações, é como se fosse uma conexão local na mesma rede. E é assim que muitas empresas conseguiram ter funcionários trabalhando de casa, em redes restritas atrás de CGNAT, abrindo conexão em servidores que estão nas empresas, de forma segura, porque todas as soluções de VPN são criptografadas.

Por muito tempo se usou protocolos como PPTP que é Point to Point Tunneling Protocol, pra criar túneis ponto a ponto seguros, mas se não estou muito errado ninguém mais usa PPTP, já é obsoleto e acho que considerado inseguro. Se esbarrar num tutorial com PPTP pode pular porque deve ser velho. Muita gente ainda usa soluções derivadas de OpenVPN, que é um software complexo, escrito em cima de outro software complexo e controverso que é o OpenSSL. Mas no mundo Linux pelo menos, acho que povo tá migrando pro Wireguard, com código mais moderno e mais leve, que agora vem direto na kernel do Linux. Eu mesmo não sei muitos detalhes, mas se o assunto de redes e segurança te atrai, definitivamente estude Wireguard.

Como disse antes, a ZeroTier usa alguma solução proprietária que parece que é criptograficamente um pouco menos seguro que Wireguard, mas não significa que seja inseguro. Se quiser um serviço equivalente que use Wireguard por baixo, tem a Tail Scale, que funciona mais ou menos do mesmo jeito que mostrei. E no caso de soluções pra empresas, acho que muitos usam os produtos da Microtik. Só lembrando que nada disso sai de graça, e não digo no custo de assinatura dos serviços. Pacotes tendo que passar por outras máquinas intermediárias no meio do caminho, em túnel criptografado, adiciona tempo de processamento e tempo de rota, por isso seus pacotes vão chegar no destino levando mais tempo e por isso conexões atrás de VPN tem velocidade menor e latência maior. O que varia nos diversos serviços por aí é a oferta de servidores próximos de você que podem ajudar a diminuir essa latência. Pra navegar na web não faz diferença mas pra coisas como gamers, latência é importante.

Enfim, no frigir dos ovos consegui fazer o que queria. Configurei um NAS super rápido, o suficiente pra conseguir editar video pesado direto dele em rede de 10 gigabits local e consigo acessar coisas do meu NAS como meu Plex, mesmo estando fora de casa, usando uma VPN da ZeroTier. Tudo isso foi super simples de configurar porque já estou mais que familiarizado com VPNs, túneis e tudo mais. Do momento que decidi usar o ZeroTier, já estava com tudo configurado em todos os dispositivos em uns 15 minutos.

Mesmo você não sendo alguém de infraestrutura, é importante saber esses conceitos porque em pouquíssimo tempo dá pra criar soluções pra problemas simples como o meu, que era expor meu NAS na internet de forma segura. Eu falo como é impressionante o quanto se aprende quando brinca de pirataria. Mesmo gamers já tiveram que lidar com esse tipo de tecnologia. Quem aqui nunca arrancou os cabelos tentando fazer o Hamachi funcionar? Pra quem não sabe Hamachi é que nem o NordVPN, um serviço de VPN da LogMeIn. Por alguma razão gamers tendem a usar Hamachi.

Eu poderia ter criado tudo na mão, um servidor particular numa Amazon ou Digital Ocean, um túnel local forwarding com SSH ou mesmo uma VPN com Wireguard, tudo configurado via linha de comando no terminal, na mão. E é uma boa opção pra quem quer aprender. Mas eu queria algo plug and play. Como exercício deixo de lição de casa pra vocês que tem um PC em casa e um notebook, criar uma VPN usando Wireguard ou SSH, sem usar um software mais fácil como ZeroTier ou NordVPN. Acho que só o tanto de documentação pra ler e tentativa e erro que vão ter que fazer vai valer mais que muito curso de redes que tem por aí.

E com isso finalmente consegui concluir a mini-série de redes. Em seis episódios mostrei só o básico do básico do que considero introdução ao assunto de redes e internet. Ainda tem bem mais coisas e muito mais detalhes, como VLANs. Mas vou deixar pra falar sobre essas coisas mais pra frente. Por agora cansei de falar de redes. Se ficaram com dúvidas mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal e não deixem de compartilhar o video com seus amigos. A gente se vê, até mais!

Apesar de ser Parte 2 da mini-série de redes, vou falar pouco sobre redes propriamente ditas e focar em um aspecto que tem a ver com mais coisas que só rede: detecção e correção de erros.

Já se fez essa pergunta? Dados são transmitidos como ondas eletromagnéticas por cabos de cobre ou sem fio. Bits são gravados magneticamente em mídias como HDs ou Blu-Rays. Como que nenhum bit nunca é gravado ou transmitido errado? E se é, como poderíamos saber se 1 único bit é entendido errado?

Mas não se preocupem, apesar de não ser diretamente “redes” é importante saber o episódio de hoje, mas no próximo episódio vou realmente mostrar mais de “redes”.

Conteúdo

• 00:00 - Intro
• 01:20 - Recapitulando RAID-0 e RAID-1
• 05:37 - Bit Rot, Bit Flip e Raios Cósmicos
• 10:37 - Hamming Code
• 15:11 - Hamming e Cartões Perfurados
• 15:53 - Eficiência de bits de paridade
• 19:37 - Checagem de erros em rede
• 20:51 - Usernet e Par2
• 24:23 - M-Discs
• 27:27 - Data Scrubbing
• 28:40 - Conclusão
• 29:43 - Bloopers

Links

• WHAT CONNECTS AN INCIDENT IN 2003 WITH SPACE, ASSEMBLY ELECTIONS, INTEL, AEROSPACE AND ELECTRIC CARS? (https://www.linkedin.com/pulse/what-connects-incident-2003-space-assembly-elections-intel-jogani/)
• How An Ionizing Particle From Outer Space Helped A Mario Speedrunner Save Time (https://www.thegamer.com/how-ionizing-particle-outer-space-helped-super-mario-64-speedrunner-save-time/)
• COSMIC RAY FLIPS BIT, ASSISTS MARIO 64 SPEEDRUNNER (https://hackaday.com/2021/02/17/cosmic-ray-flips-bit-assists-mario-64-speedrunner/)
• Bit Rot: What It Is and How To Stop It From Destroying Your Data (https://getprostorage.com/blog/bit-rot-stop-destroying-your-data/)
• How to send a self-correcting message (Hamming codes) (https://www.youtube.com/watch?v=X8jsijhllIA)
• Hamming codes part 2, the elegance of it all (https://www.youtube.com/watch?v=b3NxrZOu_CE)
• What is error correction? Hamming codes in hardware (https://www.youtube.com/watch?v=h0jloehRKas)
• Reed–Solomon error correction (https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction)

SCRIPT

Olá pessoal, Fabio Akita

No episódio anterior eu quis trazer algumas noções de como dados trafegam por redes cabeadas ou wireless. Isso porque ultimamente andei brincando com coisas como meu novo NAS. Mas antes de poder falar dele e coisas que andei prometendo como Docker, achei que finalmente chegou a hora de falar um pouquinho sobre redes. Como já tinha falado antes, estou longe de ser especialista de redes, então quero explicar as coisas do ponto de vista mais de alguém que é programador e usa a rede mais do que monta redes.

No episódio de hoje quero explorar o motivo de porque eu montei um NAS: evitar perder dados. A maioria das pessoas hoje tá acostumado a um mundo plug and play, sempre conectado, serviços de cloud e tudo mais e tem muito menos preocupação com seus dados. Na real, a maioria não tem dados tão importantes que se perder vai ser um grande problema mesmo. Por isso acho que não tem problema. Se perder, perdeu. Se doeu, deveria ter se precavido. Mas programadores eu acho que deveriam ter um pouco mais de cuidado, especialmente porque lidam com dados dos outros.

Sobre isso tem dezenas de assuntos que poderíamos falar, como segurança de dados, mas hoje quero falar só sobre os blocos mais básicos de como erros podem acontecer e como a ciência da computação vem resolvendo esses problemas desde pelo menos os anos 60.

(…)

Veja meu NAS. Ele está construído numa configuração RAID-6. Mas vamos falar de novo do formato mais simples, só 2 HDs. Se ainda não assistiu minha playlist de armazenamento, vou resumir só essa parte de novo. Com dois HDs eu posso fazer 2 coisas: escolher segurança ou escolher performance. Se eu for um gamer que posso baixar tudo de novo da Steam caso perca os HDs, talvez faça sentido colocar em modo RAID-0. Nesse modo o sistema operacional vai enxergar os dois HDs num único volume lógico. Se os HDs tem 1 terabyte cada, em RAID-0 o volume lógico, o meu “C:” no Windows, vai ter 2 terabytes inteiros e vou ter quase o dobro de performance, porque posso escrever nos dois ao mesmo tempo.

Lembram o que já expliquei antes sobre arquivos e transmissão de dados em geral? A maioria das pessoas olha um Windows Explorer e assume que a menor unidade são arquivos. Os sistemas operacionais escondem os detalhes e mesmo programadores só lidam no máximo com arquivos na maior parte do tempo. Mas isso é ineficiente. HDs não são dispositivos de arquivos, são dispositivos de blocos. Por isso o serviço da Amazon onde posso instalar um HD virtual na minha máquina virtual do EC2 se chama EBS ou Elastic Block Store. Ele nos dá um dispositivo de blocos. Eu explico isso nos videos sobre armazenamento, assistam lá depois.

No episódio passado eu falei que comunicação de redes usa hoje em dia comutação de pacotes. Pacotes são essencialmente blocos de bits. Por isso tenha na cabeça que tanto arquivos no seu sistema como transfência desses arquivos pela rede, acontecem de forma fragmentada, um pacote de cada vez e não um arquivo inteiro de uma vez. Por isso tenho o dobro de performance num RAID-0. Se o sistema só enxergasse arquivos, quando fosse gravar, gravaria o arquivo inteiro só em um HD, daí a velocidade máxima seria só desse HD.

Mas como na realidade a partição é uma tabela que tem um registro dizendo “arquivo hello.mp3 tem 2000 blocos de 4 kilobytes cada, e os blocos de ID 1 até 1000 estão no HD 1 e os blocos de 1001 até 2000 estão no HD 2”, daí ele pode mandar gravar os blocos nos dois HDs ao mesmo tempo, e por isso eu tenho mais velocidade tanto pra ler quanto pra gravar, porque o arquivo pode ser segmentado nos dois HDs. Mas também por isso esse sistema de RAID-0 tem um grande calcanhar de aquiles: e se um dos HDs sofrer um defeito e morrer?

Se um HD morrer, você perdeu tudo dos dois HDs. Entenderam? Por que alguns blocos dos arquivos no HD que está vivo estavam no HD que morreu, então você ficou com um monte de arquivos quebrados que não servem pra nada. Por isso que você nunca deve usar RAID-0 se os dados que tiver sejam importantes. Se era só pra games que você pode recuperar tudo depois, beleza. Compra outro HD, remonta o RAID-0, formata tudo, reinstala o Windows do zero e baixa tudo de novo da Steam. A importância aqui era a performance e os dados tinha backup fora, então ok.

Mas se vai misturar com trabalho, e coisas que se perder vão te dar prejuízo, e só puder comprar dois HDs, então coloque eles em RAID-1. Esse é o sistema de espelhamento. O seu sistema operacional vai enxergar os dois HDs de 1 terabyte como se fosse um único HD de 1 terabyte. Toda vez que mandar gravar um arquivo, o sistema vai mandar todos os blocos pros dois HDs e fazer uma cópia idêntica, bloco a bloco. Então a performance vai ser a de 1 único HD, um pouco menos até porque agora vai ter o trabalho de gravar no outro HD também. Quando ler, não vai ter quase diferença. Em termos de performance, vai perder um pouco, então, qual a vantagem?

A vantagem é que se um dos HDs morrer, o sistema automaticamente elege o outro como HD primário e na prática você nem vai notar. Seu sistema não vai crashear e vai poder continuar usando tudo como antes. Zero perda de dados. Agora é só comprar outro HD, substituir o que falhou, e no próximo boot o sistema vai copiar tudo do HD que sobrou pro HD novo, criando outra cópia espelho. Aqui trocamos um pouco de performance e metade do espaço por segurança.

Pra entender os outros níveis de RAID com mais HDs, de novo, veja minha playlist sobre armazenamento pra entender mais sobre isso de blocos e redundância de HDs, mas pra hoje eu precisava que vocês tivessem na cabeça esse modelo de tradeoff de performance, segurança e redundância. Isso porque poderia parecer que um RAID-1 é perfeito e vai deixar seu sistema protegido. Isso é verdade até certo ponto. É muito raro de se ver, mas um evento que acontece é bit rot ou degradação de bit ou simplesmente bit flip.

Entenda, qualquer sistema de armazenamento, seja um HD mecânico, seja um SSD que usa chips NAND flash como também SD cards ou pendrives, seja memória RAM, tudo está sujeito a uma hora sofrer algum tipo de degradação. O melhor é quando a falha é bem aparente e ele pára de funcionar totalmente. O problema é quando ele continua funcionando mas os bits armazenados não são mais confiáveis. Tudo é gravado magneticamente. Informação é um linguição de bits. Bits são cargas eletromagnéticas, armazenadas ou transportadas num fio de cobre ou em ondas pelo ar. Qualquer tipo de interferência eletromagnética poderia flipar bits aleatoriamente.

Por isso existe blindagem e todo um processo de fabricação pra evitar ao máximo qualquer tipo de interferência externa, mas nada é perfeito. Escrevendo sobre isso me lembrou de duas historinhas que seria legal vocês saberem. Em 18 de maio de 2003 aconteceu a primeira eleição com voto eletrônico da cidade de Schaerbeek em Bruxelas. Milhões votaram eletronicamente pela primeira vez. Tudo correu conforme esperado até o dia de contar e checar os votos.

Aí a comissão da eleição notou duas coisas fora do comum. Primeiro porque uma candidata razoavelmente desconhecida ganhou milhares de votos a mais do que seria esperado. Mas a segunda coisa que foi mais absurda é que o total de votos foi maior do que o total de pessoas que votaram! Claramente isso é um problema e obviamente vocês imaginam o tanto de gente apontando o dedo um pro outro atrás de fraude. Teve diversas investigações pra entender o que aconteceu, se foi um bug ou manipulação, mas uma coisa chama a atenção. O excesso de votos contados dava exatamente 4096 votos.

Pra todo mundo, 4096 é só um número, mas pra gente de computação, 4096 é um número muito específico. Se vocês não sentiram alguma coisa quando ouviram o número, precisam praticar mais, porque é exatamente 2 elevado a 12. Lembra quando eu falo que vocês precisam se acostumar a converter números decimais e pensar em binário? Um número é uma cadeia de bits, digamos de 32 bits. Se você flipar o bit na posição 13, vai dar esses 4096 a mais se lá estivesse zero. Não quer dizer que não houve fraude, mas é muita coincidência alguém que fosse fraudar pensar num número exatamente assim.

O objetivo não é detalhar o caso, então depois Googlem pra saber como foram as investigações, de fato encontraram bugs de segurança e coisas assim no software. Todo software de votação, ainda mais na primeira vez, ainda mais se não foi visto e revisto, testado e retestado e auditado por diferentes grupos de programadores independentes, certamente tem bugs importantes. Não é talvez, é certeza absoluta. Mas mesmo assim, nenhum dos bugs encontrados conseguia explicar esse acidente em particular. E uma hipótese que não dá pra provar, mas tem chances de acontecer, é que esse bit foi flipado por raios cósmicos.

Pois é, caso você não saiba, estamos o tempo todo sendo bombardeados por milhares de partículas subatômicas que vieram de explosões de Supernovas, que caem na Terra como raios cósmicos. Muitos experimentos delicados são feitos abaixo da terra, com muita blindagem, pra tentar minimizar o efeito desses raios, onde qualquer mínima variação da ordem de um elétron, pode mudar os resultados. Dependendo do estudo que achar pode encontrar que é possível ter 1 bit flip por gigabyte de memória por ano. Sabe aquela tela azul de Windows que só aconteceu uma vez e nunca mais e não teve motivo nenhum? Talvez tenha sido um bit flip de raios cósmicos.

Tem muito mais histórias do que essa das eleições e só mais uma que eu achei interessante porque é um assunto que eu gosto, foi num speedrun de 2013 de Super Mario 64, do usuário DOTA_Teabag. Speedrun pra quem não sabe é competição pra ver quem consegue acabar um jogo no menor tempo possível. Durante esse speedrun, ele esbarrou num glitch considerado impossível sem manipular o jogo. Num determinado pedaço da fase, ele tava simplesmente pousando numa plataforma e fez um warp pra cima do teto sem nenhuma razão.

Todo mundo da comunidade tentou replicar isso, usando emuladores, replicando exatamente os passos do Teabag frame a frame com scripts, mas ninguém conseguiu replicar esse efeito. Isso porque pra realizar esse warp requer o que se chama de um single event upset que é fora do controle do jogador. A única forma de replicar o warp é fazendo um bit flip no número que representa o peso do Mario. Se você flipar 1 bit mudando de C5 pra C4 hexadecimal isso dá o peso exato pra fazer o warp pra cima naquele exato momento.

De novo, é impossível dizer que foi isso, mas a hipótese de novo é que raios cósmicos fliparam esse 1 bit naquela hora, causando o warp. Mas o ponto é que bit flips acontecem, e raios cósmicos é só mais um fator numa enorme lista de fatores que podem levar à corrupção de dados. Em particular quando usamos mídias magnéticas pra armazenar e transportar dados. E se tudo isso ainda não te convenceu, não precisa ir muito longe: quantos de vocês lembram da época de CDs piratas de games e como vocês gostavam de esfregar o disco na camiseta e mesmo o disco tendo vários riscos, ele ainda funcionava. Como pode essas coisas?

Isso é tudo pra vocês entenderem que erros e corrupção de dados são inevitáveis e se vocês nunca notaram isso é um testamento de como a ciência da computação já conseguiu resolver a grande maioria desses problemas e pra todo mundo, tudo simplesmente só funciona. Vamos recapitular. Imagine um arquivo de imagens como esse gato. Obviamente é sempre um gato. Mas o que a gente vê é a representação visual de um linguição de bits. Eu expliquei isso no episódio sobre compressão. Só por conveniência pra mostrar aqui na tela posso representar essa linha contínua de bits quebrando em várias linhas, digamos, em linhas de 11 bits. E eu posso organizar mais ainda cada linha de 11 bits como um bloco.

Em particular, vou organizar os 11 bits da primeira linha num bloco de 16 posições, numerado de zero a quinze. As posições 0, 1, 2, 4, e 8 vamos reservar e eu preencho as 11 posições seguintes com meus bits de dados. Agora vamos olhar metade dos bits e checar o que chamamos de paridade. Paridade é literalmente se temos um número par ou número ímpar de bits 1. Nesse caso temos 2 bits 1, então é par. E assim preenchemos o bit de paridade na posição 1 com zero.

Agora olhamos o próximo grupo e checamos a paridade. Temos 3 bits 1, é ímpar então na posição 2 preenchemos esse outro bit de paridade com 1. Agora que vimos os grupos de colunas na vertical, vamos checar grupos na horizontal. Esse próximo grupo também tem número ímpar de bits 1. Portanto no bit de paridade da posição 4 preenchemos com 1. E finalmente checamos o último grupo, que também tem número ímpar de bits 1, portanto preenchemos o bit de paridade da posição 8 com 1.

Finalmente, checamos a paridade do bloco inteiro. Temos 8 bits 1, é par, então o bit de paridade da posição 0 vai ser zero. Pode parecer complicado mas aguentem até o final do exemplo pra eu explicar o que estamos montando aqui. Nesse momento criamos um bloco de 16 bits pra carregar 11 bits de dados e 5 bits de checagem de paridade. Agora faz de conta que estamos transmitindo esse bloco pela internet, sujeito a todo tipo de interferência eletromagnética, erros de burst, degradação do material do fio e tudo mais, e um ou mais bits desse bloco vai ser flipado no meio do caminho. Mas na outra ponta a gente não sabe disso.

Agora a outra ponta recebeu esse bloco. Duvido que vocês lembrem de cabeça como era o bloco original, então vamos checar a paridade. Checamos o primeiro grupo e vemos número par de bits 1, então o bit de paridade na posição 1 está correto com zero e sabemos que a 2a e 4a colunas parecem ok. O próximo grupo tem um número par de bits 1 mas no bit de paridade na posição 2 está 1, o que é um problema. Sabemos que tem um erro em algum lugar nessas últimas duas colunas. Mas como já sabemos que a quarta coluna tava ok, o problema tá em algum lugar na 3a coluna.

Checando o próximo grupo, temos um número ímpar de bits 1 então o bit de paridade na posição 4 está correto sendo 1, portanto sabemos que a 2a e 4a linha estão ok. E no último grupo temos um número par de bits 1 mas o bit de paridade na posição 8 está 1 em vez de zero. Então temos algum problema nessa duas últimas linhas. Mas já sabemos que a 4a linha tava ok pela checagem anterior, portanto o erro tem que estar na 3a linha. E como já sabemos que tem algum erro na 3a coluna, cruzando as duas sabemos que deve ter um erro na posição 10. Esse bit foi flipado.

Mais do que isso, olhando o bloco inteiro, vemos que a paridade é impar, então no bit de paridade do bloco deveria estar 1 em vez de zero. Isso nos dá confiança de saber que só houve 1 bit flip e não dois, portanto só o bit da posição 10 foi flipado. E se mudarmos de 1 pra zero, jogarmos fora os 5 bits de checagem, temos o bloco correto original de 11 bits que foi enviado.

O que fizemos aqui foram duas coisas: nós tivemos a capacidade de checar a existência de um bit flip, e ainda tivemos a capacidade de recuperar o bit que foi danificado e recuperar o bloco inteiro. O que vocês acabaram de ver foi o algoritmo de correção de erros Hamming Code, nomeado depois de seu criador Richard Hamming. E essa é uma das formas que temos hoje pra correção de erros.

Essas animações devem ser familiares, porque peguei emprestado do excelente canal 3Blue1Brown, que fez dois videos excelentes dois anos atrás explicando exatamente como funciona o Hamming Code. E ele fez isso em conjunto com outro canal que vocês já viram eu mostrar aqui, o do Ben Eater, que implementou Hamming Code em protoboards, em hardware, pra demonstrar como é possível colocar correção de erros em hardware. Eu altamente recomendo que assistam os videos deles pra saberem em detalhes como que isso funciona. Eu assisti esses videos dois anos atrás e tava esperando uma oportunidade pra encaixar eles nos meus videos. Quem seguiu minha recomendação de seguir os canais deles já deve ter visto.

Richard Hamming é um pesquisador da época que se programava em cartões perfurados. Imagina você levar dias escrevendo um programa nesses cartões daí leva pra uma máquina mecânica que vai ler esses cartões através dos furos. Mas vira a mexe ele erra um furo e registra a informação errada. Se até hoje aquelas porcarias de máquinas de refrigerante não conseguem identificar seu dinheiro, imagina uma máquina mecânica velha que tem que ler centenas de cartões sem errar nenhum furo. Isso acontecia tanto que deixou o Hamming putaço. E não existe melhor forma de invenção do que não se acostumar com problemas e sim coçar a própria coceira. E assim ele fez, e inventou todo esse sistema de paridade do Hamming Code pra checar e corrigir erros.

A gente usa Hamming Code até hoje em coisas como memória ECC ou Error Correction Code em RAM de workstations e datacenters. A memória que você tem no seu PC provavelmente não é ECC, mas o servidor de cloud que armazena seus dados certamente tem ECC. E é por isso que coisas como raios cósmicos não são aparentes no nosso dia a dia. Outra forma de correção de erros é o Reed-Solomon Code, que é usado em CDs e Blu-Rays e é por isso que mesmo você riscando o disco, esfregando na sua camiseta, ainda é possível ler os dados.

Mas o mais astuto entre vocês assistindo poderia pensar. Peraí, você tá me dizendo que pra um bloco de 11 bits eu precisei reservar mais 5 bits pra redundância. Ou seja, 45% do espaço e banda de transferência foi desperdiçado pra isso? Então num Blu-Ray de 40 gigabytes eu precisaria ter quase 20 gigabytes a mais só pra redundância?

Mas o mais astuto do mais astudo entre vocês talvez tenha notado que eu fui fazendo checagens naquele bloco de metade em metade. Toda vez que em ciência da computação você vê procuras feitas de metades de metades deveria vir à cabeça procura binária. Lembra os episódios onde falei de árvores e porque árvores são uma das coisas mais importantes que todo programador deveria ter em mente?

Checamos 2 paridades de 2 grupos de colunas verticais, depois 2 paridades de 2 grupos de linhas horizontais. Num bloco pequeno de 16 bits precisamos fazer 4 perguntas de paridade pra localizar e corrigir o bit flipado. Mas e num bloco bem maior, de 256 bits? Vamos precisar fazer só 8 perguntas de colunas e linhas, e pra isso precisamos reservar só 8 bits de redundância. Ou seja, só 3% do tamanho dos dados e não 45% como era no bloco de 16 bits. Quanto maior for o bloco, menor vai sendo a quantidade de bits de redundância necessário. Esse é o poder da procura binária. E eis porque vocês precisam estudar algoritmos e estruturas de dados.

Estamos usando blocos de 16-bits só porque é mais fácil de colocar aqui na tela ou pra você ver no seu celular. Mas um bloco de sistema de arquivos costuma ter pelo menos uns 4 kilobytes de dados. Um bloco de rede costuma ter pelo menos 1500 bits. Mas em rede não se usa nem Hamming e nem Reed Solomon. Só pra coisas como programa espacial da Nasa, onde o Voyager por exemplo usa Reed Solomon Code pras transmissões. Hoje em dia se usa variações de Reed Solomon pra fitas magnéticas, CDs, Blu-rays e toda mídia de armazenamento, incluindo HDs. Você nem sabe disso, mas toda vez que um bloco de dados é gravado no disco, o sistema calcula esses bits de redundância e grava no lugar apropriado no HD.

Então tá resolvido tudo então? Só usar Hamming ou Reed Solomon em tudo que tá tudo certo? Mais ou menos. Por mais que eles sejam altamente eficientes e não gastem tantos bits assim, ainda assim são bits extras, pra cada bloco de bits. A indústria de HDs por exemplo vem pesquisando outras formas que sejam quase tão eficientes quanto Reed Solomon, mas perdem em 0.1% dos casos, como o LDPC code. Reed Solomon tem complexidade O(n^2) o que significa que pra discos gigantes de dezenas de terabytes leva muito tempo pra corrigir erros. Particularmente ruim em data centers que tem arrays com centenas de HDs. Um LDPC atinge 99.9% de recuperação comparado com Reed Solomon mas com complexidade O(n). É uma área ainda com pesquisas ativas.

Recuperar erros não só gasta bits extras de armazenamento como exige processamento pra fazer essa correção. Imaginem agora switches de rede em escala de internet. Por isso eu acho que em rede não se fala tanto em correção de erros e sim em checagem de erro. É muito menos trabalho identificar que tem um erro, mas não recuperar esse erro. Se você tá fazendo aquele download longo e vê a velocidade cair porque a internet da sua região é bem instável, não é tentativa de correção de erros que tá acontecendo e sim repetição de pacotes.

Em rede, funciona mais ou menos assim. Seu arquivão de download é quebrado em vários pacotes, enviados um atrás do outro. Seu PC vai recebendo esses pacotes e remontando o arquivo. Mas ele faz uma checagem antes. Essa checagem é parecida com a checagem de bits de paridade do Hamming Code, mas um pouquinho só mais sofisticado. No caso de internet falamos de checksum, em particular, Internet 16-bits. Esse checksum é uma soma dos bits do bloco dividido por palavras de 16-bits. Existem formas melhores como Fletcher’s checksum ou CRC, que é Cyclic Redundancy Check. Mas eu acho que ainda se usa Internet 16-bits mesmo.

De qualquer forma, entenda que existe essa checagem via checksum pra cada pacote. Se for detectado que houve um bit flip ou coisas como burst, que é comum, o pacote é rejeitado e seu PC manda aviso de volta pro servidor, “olha, o pacote ID xpto veio cagado, manda de novo”. Esse é NAK que falei antes. Daí o servidor manda o mesmo pacote outra vez. É um dos motivos de porque você vê a velocidade de download caindo e flutuando. No caso de rede é mais barato pedir o pacote de novo do que tentar corrigir ele. Correção é mais importante quando você não tem pra quem pedir uma cópia original, como arquivos no seu HD, que só você tem.

No começo da internet a gente usava um serviço chamado Usenet, que usava o protocolo NNTP. Pensa tipo um sistema de fóruns. Assim como o protocolo SMTP de email ou HTTP de web, era outro protocolo baseado em texto puro de 8 bits. Ele foi feito pra transmissão de texto e não arquivos binários. Pense em usenet como Wordpress que povo tenta entuchar mais coisa do que ele foi planejado pra fazer. Usenet foi feito pra sincronizar artigos de texto entre diferentes servidores Usenet. Mas obviamente, a gente achou jeitos de entuchar arquivos binários pra fazer pirataria. Estamos falando de uma era anos antes de bittorrent.

Eu mesmo fiz muito isso na faculdade. A gente baixava imagens, software e tudo mais da Usenet. O problema é que por diversas razões, os arquivos podiam acabar corrompidos. Erros de conversão. Erros nos discos rudimentares dos servidores da época e tudo mais. Mas o problema é que invariavelmente eles acabavam corrompidos. Primeiro, a gente precisa resolver o problema de trafegar arquivos binários num protocolo de textos.

Os mais astutos já tem a resposta na ponta da língua. Base64. É uma forma de transformar binários em textos de 7-bits. Base64 não é encriptação de jeito nenhum. O problema é que se você tentar abrir um arquivo binário num notepad, não tem como dar copy e paste em outro notepad e salvar o arquivo, vai corromper tudo, porque um editor de textos não reconhece todos os símbolos binários. A solução é converter o binário num sub-conjunto de ASCII que um editor de textos entenda e depois converter de volta num binário. O custo disso é gastar um pouco mais de espaço.

Cada dígito de Base64 representa exatamente 6 bits de dados. Então 3 bytes de 8 bits cada do arquivo, ou seja, 3 x 8 ou 24 bits, podem ser representados por 4 dígitos de 6 bits, que dá 24 bits também. Isso significa que a versão Base64 do arquivo vai ser 133% maior do que o original. Um arquivo binário de 100 megabytes vai virar 133 megabytes em Base64.

Como arquivos podem ter tamanhos variados, como um filme longo por exemplo, ou o instalador do Photoshop ou coisas assim, pra Usenet não reclamar, a gente quebrava esse binários primeiro em múltiplos binários usando o bom e velho formato rar ou WinRar, porque assim como Zip ele compactava o arquivo, mas diferente de zip, ele permitia quebrar em múltiplos arquivos com final .rar2, .rar3 e assim por diante. E depois que baixava todos os rars, o WinRar conseguia remontar e descompactar o original.

Então o processo era simples: faz vários arquivos rar, converte em texto Base64, na época usando a ferramenta uuencode do UNIX, que significa unix to unix encode. Postava cada pedaço em um artigo da Usenet. Do outro lado a gente baixava o base64 de cada pedaço, usava uudecode pra conseguir os binários de volta, e usava um equivalente WinRar pra descompatar os arquivos originais. Era assim que a gente fazia antes de Google Drive, Mega ou BitTorrent.

Como disse antes, a Usenet não foi feita pra transportar arquivos, e por inúmeras razões, incluindo defeitos nesse monte de passos que a gente tinha que fazer, alguns bits acabavam corrompidos. Então a gente precisava de uma forma de garantir que dava pra recuperar de alguma forma após o download, caso notássemos que o arquivo veio corrompido. E aí surgiu a idéia do Parchive ou arquivos .par ou a versão melhor que foi o Par2. Agora você podia baixar os arquivos rar e também os arquivos par2, que era bem menores. E se o rar estivesse corrompido na hora de descompactar, podia experimentar recuperar usando os arquivos .par2.

E o que é Par2? É basicamente aqueles bits de redundância como no exemplo do Hamming Code, só que são os bits pra Reed Solomon Code, como eu disse que funciona pra CDs. Os primórdios da Internet era muito legal porque a gente era obrigado a aprender essas coisas se quisesse baixar pirataria. Eu me lembrei disso porque recentemente decidi fazer backup dos videos originais aqui do canal em M-Discs ou Millennial Disc, a evolução dos discos Blu-Ray. É tecnologia nova, de 2010 pra cá. E me perguntaram se não era bom eu fazer parchives pra gravar junto, eu até fiz, mas acho que não precisava.

De curiosidade pra quem não sabia, CDs, DVDs e Blu-rays comerciais comuns, vem com uma camada de proteção pra proteger contra riscos leves, aquela esfregada leve na camiseta. Porém, essa camadinha é feita de material orgânico que reage com oxigênio e umidade do ar. Significa que mesmo que você guarde com todo cuidado possível, eventualmente essa camada vai degradar e você pode acabar com um disco que não dá mais pra ser lido. Pode demorar 10 anos, demorar um pouco mais, mas é questão de tempo. Sua coleção de CDs não vai durar pra sempre a menos que esteja numa câmara a vácuo com zero umidade e temperatura controlada. E mesmo com os bits de redundância de Reed Solomon, você vai perder dados se essa camada danificar o suficiente.

Por isso escolhi M-Discs. Eles são basicamente Blu-rays só que a camada de proteção é feita de material inorgânico, não reagente, não oxidante. Só pra ter uma imagem, pensa uma camada de proteção feita de pedra. Em testes de mais de 250 horas sob temperaturas de 90 graus Celsius, 85% de umidade, mesmo assim os discos permanecem intactos. Por isso se chamam millennial discs, são discos feitos pra durar mil anos, sob condições adversas. Perfeitos pros meus backups. Alguns vieram sugerir fitas magnéticas, mas nesse mesmo nível de durabilidade, custam ordens de grandeza mais caro por gigabyte.

E eu disse que não precisava ter manualmente criado arquivos par2 com os bits de Reed Solomon Code porque um Blu-ray por padrão já tem esses bits. Hoje em dia tem poucos motivos pra se preocupar com bits de redundância porque a maioria dos sistemas de armazenamento modernos tem esse cuidado, incluindo seu SSD e seu HD. Só sua RAM que ainda não porque memória ECC é bem mais cara. Mas como no mundo caseiro a gente dá refresh nessa RAM porque bootamos toda hora, a chance de um bit flip causar problemas é muito baixa. De vez em quando, uma tela azul de Windows sem motivo nenhum, é a rara consequência que você vai encontrar.

Hoje em dia não precisamos baixar arquivos par pra recuperar downloads corrompidos, mas muitos sites de downloads você já deve ter visto um código md5 ou sha1 junto pra checar a integridade do binário. Eu já expliquei sobre isso no episódio de criptografia, mas um sha1 é um algoritmo de hashing, um tipo de checksum. Se baixarmos a ISO de uma distro de Linux, e tiver sequer um bit flip, passando por sha1 o hash resultante vai ser completamente diferente do hash original que deveria ser. Por isso é um mecanismo importante pra sabermos se não houve bit rot ou mesmo manipulação no meio do caminho. Sha1 é muito superior a uma mera checagem de paridade, mas também custa mais caro pra processar.

Menciono isso porque já que comecei falando de NAS, em sistemas de RAID como o Linux Raid ou sistemas de arquivos realmente modernos como Btrfs ou ZFS que expliquei no último episódio da série de armazenamento, eles oferecem proteção contra erros e exigem rodar uma tarefa em background com alguma periodicidade chamada Data Scrubbing. No ZFS tem um comando justamente chamado scrub pra isso, detectar e corrigir data rot.

No meu NAS também tem essa opção de agendar um data scrubbing a cada 3 meses ou o período que eu quiser. Não precisa rodar sempre. Mesmo o HD tendo suporte a Reed Solomon Code, nem isso garante que vai estar tudo ok. Checar e corrigir erros é uma tarefa que custa processamento e tempo, por isso não se roda toda hora. Ele vai usar coisas como checksum de cada arquivo, equivalente ao que falei de checar o hash depois de um download, pra ver se o arquivo está intacto. Isso exige ler e calcular em cima de todos os bits do arquivo.

Por isso custa processamento. Se coisas como o checksum ou paridade não baterem, ele usa a cópia redundante do RAID pra reconstruir o pedaço com danificado. E vai fazendo isso arquivo a arquivo. Se tiver poucos erros é fácil de consertar, mas se deixar acumular por chegar num estado que é impossível recuperar, por isso se roda data scrubbing periodicamente.

Como disse antes, pra maioria de vocês, tudo isso é invisível. Se um pacote na rede é corrompido, seu sistema pede pro servidor reenviar os pacotes. Se um arquivo é levemente corrompido na hora de gravar no seu HD, ele tem sistemas pra se auto corrigir. Com exceção de desastres graves, você raramente tem problemas de ver corrupção de dados. Seu streaming sempre funciona, as páginas que carrega sempre vem inteiros, e tudo isso porque pesquisadores como Hamming, Reed, Solomon, Shannon e muitos outros criaram as bases pra que tudo isso funcione. Mas de qualquer forma é bom saber porque as coisas funcionam num ambiente hostil onde corrupção de dados deveria ser o normal.

O objetivo desse episódio era complementar o que falei nos episódios de armazenamento, no episódio sobre compressão, e o anterior onde comecei a falar sobre transmissão de dados e redes. Viemos muito longe desde um simples telefone de copinho e barbante e agora você sabe porque. Se ficaram com dúvidas mandem nos comentários abaixo. Se curtiram o video deixem um joinha, assinem o canal e compartilhem o video pra ajudar o canal. A gente se vê, até mais.

DESCRIÇÃO

Quais são todos os filesystems de todos os sistemas operacionais? Por que todos falam que ZFS é o melhor? E quais as alternativas mais modernas? Vamos ver tudo isso hoje!

Conteúdo

• 00:00 - Intro
• 00:32 - INode, DEntry
• 02:35 - VFS
• 03:18 - Journaling
• 05:54 - Filesystems com Journal
• 06:23 - Filesystems da Apple
• 07:59 - Filesystems de Linux
• 11:21 - Resumo
• 13:26 - ZFS
• 14:36 - checksums
• 16:28 - OpenZFS
• 18:11 - snapshots - Copy on Write
• 22:25 - de-duplication
• 23:46 - CoW vs Journal
• 24:49 - APFS
• 26:01 - compressão
• 26:32 - encriptação
• 29:04 - BTRFS
• 32:12 - o filesystem universal?
• 32:57 - NFS/CIFS/SMB
• 34:04 - SD Cards
• 35:36 - exFAT

Links

• The Inode Object (http://books.gigatux.nl/mirror/kerneldevelopment/0672327201/ch12lev1sec6.html)
• The Dentry Object (http://books.gigatux.nl/mirror/kerneldevelopment/0672327201/ch12lev1sec7.html)
• The Superblock Object (http://books.gigatux.nl/mirror/kerneldevelopment/0672327201/ch12lev1sec5.html)
• BSD - 9.4. Block Devices (Are Gone) (https://docs.freebsd.org/en/books/arch-handbook/driverbasics/#driverbasics-block)
• ZFS on Ubuntu 20.04 LTS (https://ruvi-d.medium.com/zfs-on-ubuntu-20-04-lts-53728f3bc9e9)
• Apple abandons ZFS on Mac OS X project over licensing issues (https://arstechnica.com/gadgets/2009/10/apple-abandons-zfs-on-mac-os-x-project-over-licensing-issues/)
• The Guts n’ Glory of Database Internals B+Tree (https://ayende.com/blog/174402/the-guts-n-glory-of-database-internals-b-tree)
• fs.h (https://github.com/torvalds/linux/blob/master/include/linux/fs.h)
• Anatomy of the Linux file system (https://developer.ibm.com/tutorials/l-linux-filesystem/)
• Linus - Deploying ANOTHER PETABYTE of Storage! (https://www.youtube.com/watch?v=fbipJUJLzpE)
• A short history of btrfs (https://lwn.net/Articles/342892/)

SCRIPT

Olá pessoal, Fabio Akita

No episódio anterior a gente viu o antigo FAT em detalhes e como ele evoluiu até o FAT32. Demos uma pequena olhada nos primórdios do NTFS, do HFS e como passamos a implementar filesystems com estruturas de árvore, os B+Trees. Vamos continuar exatamente de onde paramos pra falar dos principais filesystems que surgiram depois nos anos 90 até hoje. Vai ser uma longa história então vamos lá.

(…)

Pra começar, eu tava pensando em escovar bit do sistema de arquivos de UNIX e Linux, mas acho que o mais importante você já viu: que o conteúdo dos arquivos, a linguiça de bytes fica fatiado em cluster, e que as folhas de uma árvore B+Tree apontam pra esses clusters. A árvore em si tem nós com múltiplos filhos e cada nó é uma estrutura de dados que grava os metadados como nome de arquivo ou diretório e suas propriedades. No mundo Linux as duas estruturas mais importantes são os inodes ou index node e dentry ou directory entry.

Basta entender que inode e dentry são structs, interfaces. Se quiser saber mais sobre eles basta abrir o arquivo de cabeçalho fs.h no código fonte da kernel. Isto aqui do lado é uma versão simplificada. Um inode carrega os metadados que representam um arquivo ou um diretório. Veja por exemplo os campos de user id e group id que você normalmente modifica com comandos como chown. E olha aqui onde ele grava os timestamps. Você consegue ler esses metadados do inode usando o comando stat como eu fiz aqui, olha os metadados organizados de forma legível.

O nome do diretório ou arquivo fica na estrutura dentry que você pode ver aqui do lado simplificado. De importante é que o dentry também aponta pra uma estrutura mestra que é o superblock, que vai definir o filesystem em si. Pense nela como a raíz da árvore. Os dentry apontam pro superblock e pra inodes. E inode aponta pro file ou arquivo. E não só isso. Quando falamos que tudo em UNIX é um arquivo é porque arquivos propriamente ditos, dispositivos até named pipes são representados por inodes.

As diversas operações que podem ser feita em cima de inodes são definidos em outra estrutura, a inode_operations. Veja como ela tem ponteiros pra funções nomeadas como create, mkdir, rmdir. A kernel do Linux não fala diretamente com o filesystem. Ela fala com uma camada de abstração chamada VFS que é o virtual file system e ele fala com o filesystem.

Sistemas operacionais modernos aceitam diversos filesystems diferentes, como o Windows aceita NTFS ou FAT. Cada filesystem no Linux precisa preencher essa estrutura pra apontar pra funções específicas de sua implementação, mas todas devem lidar com essas estruturas como inodes ou dentry e assim se tornam compatíveis com Linux.

Se você for programador, o inode_operations é como uma interface implementada por uma classe num ext4 e os métodos dessa classe recebem objetos inode ou dentry pra trabalhar ir populando e gerenciando a árvore. Como você só vai ter que lidar diretamente com isso se estiver criando um novo filesystem ou módulos de kernel, saber só isso já deve ser suficiente pra continuar.

Um dos recursos que é normal hoje mas antigamente só se usava em máquinas corporativas, como mini-computadores AIX da IBM ou workstations Silicon Graphics, é Journaling. Muita gente nunca ouviu falar disso mas um journal ou um diário é tipo um log, implementado como um log circular. Circular pra não crescer pra sempre.

A gente costuma pensar que quando mandamos criar ou apagar um arquivo é só Uma operação que acontece instantaneamente. Mas não é assim, são conjuntos de operações, como qualquer programa que você escreve: uma função formada por múltiplas instruções.

Por exemplo, apagar um arquivo num sistema de arquivos de UNIX e compatíveis vai ter pelo menos umas três operações. Primeiro precisa remover a estrutura de entrada de diretório da árvore. Um detalhe de implementação é que precisa devolver a estrutura de inode pro pool de inodes livres. E finalmente precisa liberar os blocos do disco pro pool de blocos livres.

Quando tem um crash, por bug ou pane elétrica, pode justamente parar no meio de uma dessas três operações e isso vai deixar nossas estruturas de dados num estado inconsistente ou corrompido. Por exemplo, a entrada de diretório foi removida da árvore mas o inode corresponde não foi devolvido pro pool de inodes. E assim por diante.

Por isso que em Linux antigo, se você bootasse a máquina apertando o botão de reset, sem dar shutdown, no próximo boot ele forçava rodar a ferramenta fsck que é o filesystem check. Que quem já viu sabe que é lento e você é forçado a esperar. Porque pra detectar onde que pode estar corrompido não tem jeito, precisa navegar nó a nó da árvore do sistema de arquivos e checar inode por inode.

Por isso inventaram a idéia de um journal. Um journal pode ser implementado de várias formas. Numa partição escondida, num arquivo escondido, num outro HD secundário separado. Enfim, a implementação vai variar dependendo do filesystem mas a idéia é primeiro escrever aquelas três operações nesse log e só depois começar a executar em cima da árvore de verdade. Se a operação for interrompida na metade, no próximo boot o sistema de arquivos pode checar as últimas operações no journal. Daí ele termina se puder, ou volta pro último estado indicado no journal.

De novo, é um trade off. A gente tá usando mais espaço em disco pra uma estrutura de suporte, ou seja, vai de novo ter um pouco menos de espaço livre pra você. Por outro lado temos menos chance de acabar com nosso sistema de arquivos corrompido e perder tempo tentando detectar o erro pra consertar. Num Windows antigo quando isso acontecia no boot ele carregava o Scandisk que é o equivalente fsck no Windows. Hoje você nunca vê ele.

Isso porque FAT32 não suportava journal, mas o NTFS que foi introduzido pelo Windows NT suporta. Essa era uma das grandes diferenças. O Mac também evoluiu seu HFS e lá pela versão 8 do antigo MacOS dos anos 90 criou o HFS Plus, que além de atualizar suas estruturas pra 32-bits também, passou a adotar um journal. Até poucas versões atrás o MacOS ainda usava HFS+ como filesystem principal, depois foi substituído pelo APFS, mas já falo dele.

Falando rapidamente em Macs, todo mundo sabe que depois de ter sido expulso da Apple no meio dos anos 80 o Steve Jobs fundou a NEXT pra produzir workstations UNIX e competir no mercado da Sun e Silicon Graphics. Pra isso o time dele criou o NEXTStep que era um UNIX no espírito de um Solaris ou IRIX. E usava o filesystem UFS como outros UNIX da época.

Durante os anos 90 a Apple foi decaindo sem parar. Passou na mão de vários CEOs e ninguém conseguiu recuperar a Apple. No meio dos anos 90, só 10 anos depois, todo mundo já tava contando os dias pra Apple declarar falência e fechar as portas. Daí o último CEO dessa geração, Gil Amelio fez a única coisa que dava pra fazer: convidou o Steve Jobs pra voltar. O resto é história.

Nessa época o sistema operacional dos Macs era o System 9. O System naquele ponto já tava praticamente perdendo pro Windows 98. Era ridículo como o software deteriorou em pouco mais de 10 anos, partindo da referência que todo mundo queria ser, pra um sistema legado e atrasado. Quando o Jobs voltou em 97 ele trouxe toda a propriedade intelectual da NEXT, incluindo o NEXTStep e toda a biblioteca orientada a objetos feito em Objective-C pra criar aplicativos modernos distribuídos em rede, que deixou até John Carmack babando.

Mas pra ficar compatível com os Macs, decidiram trocar o UFS, o Unix File System, pelo HFS, mais especificamente pelo HFS+ que foi lançado junto com o System 8.1 e adicionou suporte opcional a journaling. Até hoje se você for no Disk Utility dos MacOS, que é o equivalente ao Disk Management do Windows ou um GParted do Linux, vai ter a opção de formatar o volume com HFS+.

Como podem imaginar, journaling foi uma das grandes discussões da comunidade open source no fim dos anos 90. Distros Linux começaram usando o MINIX File System. MINIX que é o sistema operacional inspirado em UNIX criado pelo lendário professor Andrew Tanenbaum pra ensinar sistemas operacionais na faculdade. Já não se fazem mais professores como o Tanenbaum. O File system dele era muito bom, muito estável, mas tinha as limitações daquela época do começo dos anos 80 onde a gente economizava bytes, desperdiçando o menos possível, e por isso os nomes de arquivos só suportavam 14 caracteres de comprimento e partições de 64 megabytes.

A comunidade ajudou o Linux Torvalds e perto da versão 1.0 o MFS foi trocado pelo extended file system ou ext, que era inspirado um pouco no MINIX mas também no UFS que é o UNIX File System e seu sucessor que foi o Berkeley Fast File System ou BSD FFS. Se não me engano a gente ainda usa uma versão atualizada do FFS nos FreeBSD da vida.

O ext foi substituído pelo second extended filesystem. O ext2 foi o filesystem mais adotado no meio da década de 90 no mundo Linux. Comparado ao FAT do MS-DOS, era muito superior. Suportava volumes de até 32 terabytes, arquivos de 16 gigas até 2 tera, nomes longos de 255 caracteres e mais. Não devia nada ao HFS do Mac ou HPFS do OS/2.

No meio dos anos 90, acho que só o HPFS, o ext2 e o FAT32 é que ainda eram popularmente usados e não tinham um sistema de journaling. O OS/2 foi caindo em deuso e no fim dos anos 90 a IBM substituiu o HPFS pelo mesmo filesystem que usavam nos mini-computadores mais parrudos AIX, o JFS que significa justamente Journaling File System.

Os Silicon Graphics tinham o sistema operacional IRIX como falei alguns episódios atrás e o filesystem deles era um dos mais sofisticados, de alta performance com operações paralelas de I/O, extents, implementado com B+Trees e, claro, journaling. Esse era o XFS. Ambos XFS e JFS foram portados pra Linux no começo dos anos 2000. Por isso que você ainda vê eles por aí.

Em paralelo surgiram outros como o controverso ReiserFS que foi o primeiro filesystem com journaling que apareceu pra Linux, antes ainda do JFS e do XFS. Ele virou o filesystem padrão da distribuição SUSE que migrou pro ext3 em 2006. Eu imagino que uma das razões da migração foi o que aconteceu com o autor do ReiserFS, o Hans Reiser, que tinha fundado a empresa Namesys. Em 2006 ele foi preso e em 2008 foi condenado por ter assassinado a esposa, Nina Reiser. Depois disso ex-funcionários da Namesys deram continuidade ao ReiserFs junto com voluntários.

No fim dos anos 90 a adoção do Linux cresceu exponencialmente e as fraquezas do ext2 davam mais e mais dor de cabeça, especialmente a demora que era o fsck que era forçado a rodar no boot toda vez que você resetava a máquina sem dar shutdown. E de fato, vira e mexe você perdia inodes no caminho. Então fizeram um fork do ext2 e acrescentaram a funcionalidade de journal em cima, renomearam tudo pra ext3 e ele foi fácil de adotar porque era compatível com o ext2. Não precisava reformatar as partições, só carregar o novo filesystem. Então migrar era fácil.

Vamos dar uma pausa pra resumir um pouco. No mundo Microsoft a gente pulou dos anos 80 pros anos 90 evoluindo o maldito FAT, de FAT12 pra FAT16 pra VFAT e FAT32. Era essa porcaria que usávamos no Windows 95, 98 e Me. Depois da parceria do OS/2 com a IBM a Microsoft foi evoluindo em paralelo o Windows NT que era código novo feito do zero e diferente do Windows 95. Ele tinha o NTFS que, comparado com o FAT32, era anos luz à frente, suportava volumes muito maiores, arquivos muito maiores, nomes longos, sistema de permissão e tinha journaling. NTFS sobrevive até hoje.

No mundo Mac, depois do lançamento do revolucionário Macintosh em 1984 eles pularam do Macintosh File System ou MFS pro Hierarchical File System ou HFS, que já era baseado em B+Tree, suportava nomes longos, mas tinha limitações no tamanho de arquivos e partições. Era tipo um VFAT pouca coisa melhor. Isso ia melhorar em 1998 com o lançamento do System 8.1, a gente ainda estava alguns anos antes da Apple terminar de adaptar o NEXTStep pra virar o MacOS X que só seria lançado no ano 2000. Por quase 20 anos os MacOS iriam usar o HFS+.

No mundo Linux tinha a herança dos UNIX File System e isso derivaria no extended file system ou ext. Ele ia evoluir pro ext2 que foi o mais usado nos anos 90 e começo dos anos 2000. Como tava ficando atrasado outros começaram a aparecer como o ReiserFS que foi um dos primeiros a suportar journaling e outras funcionalidades que melhoravam a performance.

Ao mesmo tempo a IBM contribuiu abrindo o journaling file system ou JFS pro mundo Linux e além do OpenGL a Silicon Graphics, nos seus últimos dias, também abriu o XFS que usava nos IRIX pro mundo open source. Mas quem acabou sendo mais adotado, principalmente pela facilidade e compatibilidade, foi o ext3. A partir de 2006 começou o desenvolvimento do ext4 que só passou mesmo a ser adotado depois de 2010. Hoje o filesystem mais usado de Linux em desktops e notebooks provavelmente é o ext4 mesmo. Mas em servidores talvez seja um pouco diferente, como já vamos ver.

Esse é o panorama até os anos 2010. Não sei porquê, no mundo doméstico filesystems meio que estagnaram nos primeiros 15 anos do século XXI. Mas no mundo de data centers a coisa evoluiu diferente. Uma das últimas contribuições da antiga Sun e seu sistema operacional Solaris, baseado no DNA do UNIX System V, foi a introdução do filesystem ZFS, o Zetta File System. Se você nunca ouviu falar, devia procurar saber.

O ZFS foi definitivamente a próxima grande evolução na história de filesystems. Nenhum dos que falei até agora chega perto. Ele inicia a geração de filesystems que não enxergam só uma partição no HD mas é também um gerenciador de volumes ao mesmo tempo. Ele sozinho suporta criar um único volume em cima de vários HDs num pool ou piscina. A gente fala bastante o termo pool, mas pense nessa palavra como sendo um “conjunto” de alguma coisa. É só um nome mais fancy.

Enquanto tava todo mundo achando que ter journaling já era suficiente o ZFS tava preocupado com coisas maiores. O mercado da Sun e seu Solaris, principalmente depois que foi comprada pela Oracle, era equipar servidores que rodavam bancos de dados realmente massivos como a própria Oracle. Quando a Oracle comprou a Sun, ela continuou evoluindo o ZFS.

Muitos dos filesystem domésticos sequer incluiam checksums. Pra quem não sabe o que é um checksum recomendo assistir esse video do Ben Eater que vou deixar linkado nas descrições abaixo. Mas em poucas palavras é uma forma de certificar um bloco de bytes. Se alguém inexperiente quisesse saber se um bloco não foi corrompido talvez ele mantivesse pelo menos uma cópia exata desse mesmo bloco.

Mas isso seria um puta desperdício. Não dá pra saber qual dos dois blocos que tá certo ou se os dois tão errados, só que ficaram diferentes por alguma razão. Essa é a forma mais rudimentar de detectar erro mas desperdiçando o dobro de espaço. Em vez disso, o checksum é um número bem menor, que sim, consome alguns bytes a mais, mas é da ordem de 1% ou menos pra certificar um bloco de bytes e detectar erros. Pense em dígito verificador num código de barras.

O NTFS do Windows incrivelmente implementa checksums mas o HFS+ da Apple não e só no ext4 do Linux que passamos a ter checksums nos journals, que é crucial porque dependemos dele pra reconstruir as últimas operações no sistema de arquivos antes de uma pane. O ZFS vai além de checksums. Ao contrário do ext4 e outros derivados do UNIX file system, o ZFS não usa ferramentas como o fsck. Ele tem sistemas próprios pra diagnosticar erros e corrupção de dados.

Nenhum filesystem é imune a corrupção de dados, mas lendariamente pra você corromper um ZFS precisa ser defeito de hardware. E se estiver usando um pool de HDs, precisa acontecer erro catastrófico de hardware em múltiplos HDs. É bem mais difícil um erro acontecer no ZFS do que qualquer outro. Nenhum outro chega perto. Eu sei, tem outras opções, vou chegar lá, mas entenda que de 2005 em diante, se você quer montar um servidor de armazenamento sério de petabytes num datacenter, nunca vai usar HFS+ ou NTFS e nem ext4. Vai usar ZFS.

ZFS tá disponível também em FreeBSD e chegou a ser portado tanto pra Linux quanto Mac OS X. Mas no Mac eles deixaram de suportar. Aliás, por muitos anos a gente ficou discutindo quando a Apple ia oficializar o suporte a ZFS como filesystem principal. Alguns acreditam que o problema foi a Sun ter sido comprada pela Oracle, que deixou o resto da indústria meio insegura.

Quando a Oracle adquiriu a Sun em 2010 ela parou o desenvolvimento da versão open source do Solaris, o OpenSolaris. Muitos engenheiros originais da Sun se demitiram e iniciaram projetos paralelos como o OpenZFS, que tenta substituir todo o código proprietário do ZFS da Oracle, pra uma versão open source compatível com licenças de software livre.

No outro lado do espectro, a licença CDDL do ZFS e OpenZFS é um problema pro mundo Linux e GPL. Alguns dizem que GPL e CDDL não são compatíveis mas acho que ainda não tem um consenso. Na dúvida, o Linux não vem com OpenZFS. Você pode manualmente baixar e instalar, mas suportar ZFS em Linux sempre vai ser um problema até esse ponto de licenças ser resolvido. Como a licença BSD é menos restritivo, mais livre que o GPL, o CDDL não é um problema. Por isso que se você for montar servidores de armazenamento, é melhor preferir usar FreeBSD em vez de alguma distro Linux.

No mundo doméstico de Linux como Ubuntu, só recentemente passou a suportar, a partir da versão 19 ainda meio experimental. Hoje mais estável a partir da versão 20 do Ubuntu, dá pra instalar ZFS de forma mais fácil, direto do instalador. A Canonical não é da bandeira xiita de software 100% livre, então ela tem versões de Ubuntu que vem com coisas proprietárias como os drivers binários fechados da NVIDIA e agora o OpenZFS.

Além de checksums no nível de blocos e outras funcionalidades de auto-recuperação pra impedir corrupção de dados e dezenas de outras funcionalidades importantes que eu não conheço, a mais interessante mesmo pra usuários como nós é a capacidade do ZFS de ter snapshots baratos por conta do sistema de COW ou copy on write.

Agora fodeu. Vamos entender copy on write. Interessante que dos filesystems domésticos, nem o ext4 do Linux e nem o HFS+ da Apple tem suporte a snapshots baratos mas, de novo, o NTFS do Windows tem, se você tiver o serviço de Volume Shadow Copy ativado. Se for programador um sistema de copy on write é mais ou menos parecido em conceito com um commit de Git.

Como expliquei no começo, um arquivo no nível do sistema de arquivos é uma coleção de clusters ou blocos. Quando a gente edita um arquivo de texto e manda salvar, vai alterar só os blocos que foram modificados. O problema na maioria dos filesystems é que essa modificação é feita “in-place”, é literalmente escrever o dado novo “em cima” do bloco original. Se der bug ou falta de energia isso pode deixar o bloco original num estado corrompido.

Arquivos são divididos em clusters. Pra simplificar vamos imaginar que eu tenha um array que representa o arquivo. Cada posição do array aponta pra um cluster. Se meu arquivo tem 10 clusters, vamos ter um array de 0 a 9. Faz de conta que o nó da árvore que diz “hello.txt” aponta pra esse array.

Quero salvar uma modificação que vai alterar o conteúdo só dos cluster 5 e 6. Antigamente eu iria escrever os bits diretamente em cima desses clusters e pronto. Mas hoje eu posso fazer diferente. Primeiro eu faço uma cópia só desse array. Isso vai ser rápido porque ele é uma estrutura pequena só de endereços pros clusters. Agora eu escrevo o novo conteúdo em dois clusters novos. Feito isso basta alterar o endereço das posições 5 e 6 desse novo array pra apontar pros novos clusters.

O eu que eu tenho agora? Do ponto de vista do sistema de arquivos eu tenho dois arquivos com o mesmo nome, duas versões diferentes, mas eles não ocupam o dobro de espaço, porque os dois arrays apontam pra maioria dos mesmos clusters. Uma vez terminado, eu sei que o arquivo tá seguro, então eu vou na árvore e só mando trocar o ponteiro do array antigo pro array novo. Pronto, salvei meu arquivo de uma forma segura.

Mais do que isso. Porque eu preciso apagar o array antigo? E se eu chamar a estrutura do array antigo de versão 1 e a estrutura do array novo de versão 2? Essa é a raíz pra idéia de snapshots.

Faz de conta que você quer fazer uma atualização de sistema meio arriscada, talvez dê pau e você não consiga mais bootar o sistema. Antigamente a única opção que você tem é plugar um HD externo e fazer um backup de tudo. Dependendo do tamanho do seu HD isso pode levar horas. E se desse pra fazer uma cópia de tudo em segundos?

Um backup normal vai levar horas porque precisa copiar todos os bytes de todos os arquivos. Mas num sistema que suporta snapshots como eu expliquei, via copy on write, dá fazer uma cópia só da estrutura de árvore. Só os trechos modificados de cada arquivo que vai ocupar espaço novo. Não vai sobrescrever em cima. Se você tem 100 giga de arquivos e faz um snapshot, ter duas versões ocupando praticamente os mesmos 100 giga. Por isso falei que em conceito parece um commit de Git. Um commit só tem as linhas modificadas de um arquivo e não uma cópia do arquivo inteiro. Se não assistiram meu video de como Git funciona, recomendo ver depois.

Se é tão fácil assim porque não dá pra fazer isso em FAT32 ou HFS+? Por que as operações de escrita são in-place. Elas sobrescrevem em cima dos blocos antigos, pra economizar espaço. Mas como os HDs de hoje são ordens de grandeza maior, podemos copiar só os novos blocos pra um espaço livre, e manter os blocos originais sem tocar neles. Essa é a idéia por trás de garantir que você não vai acabar com dados corrompidos se crashear no meio do caminho. As versões originais nunca foram tocadas.

Snapshots são como commits de Git. E assim como Git você consegue voltar no tempo. Facilmente consegue recuperar diretórios ou arquivos apagados ou modificados, porque os blocos originais permanecem no disco. Obviamente vai ocupar mais espaço com o tempo, mas de novo, espaço em disco hoje é muito barato. A gente pode desperdiçar espaço em disco pra garantir que não vamos perder dados. E com o tempo podemos consolidar versões pra recuperar espaço.

Falando em duplicar, se você fizer uma cópia de um arquivo de um diretório pra outro diretório, iria realmente copiar bloco a bloco do arquivo original. Se o arquivo original for grande e tiver vários gigabytes, isso ia levar pelo menos alguns segundos e ocupar o dobro de espaço. Mas num sistema de copy on write vamos ocupar zero bytes a mais. Tem até um processo de deduplicação pra quando for copiar um arquivo ele vê se já não tem outro com os mesmos bytes, daí só aponta pra ele.

Como o ZFS tem copy on write por bloco, enquanto ninguém mexer nos dois arquivos, eles vão apontar pro mesmo linguição de bytes. A vantagem é que vai custar tempo zero e espaço zero pra criar a duplicata. Só se um dos arquivos for modificado que realmente vamos precisar ocupar espaço novo só dos blocos que foram modificados.

A mesma coisa acontece na memória quando o Linux faz um fork de um processo, ou seja, cria uma duplicata de um processo pra usar os diversos cores de uma CPU moderna. Se fosse uma cópia exata, e o processo estiver ocupando 100 mega de memória, cada vez que fizermos uma cópia deveria duplicar a memória do processo novo. Se fizermos 3 forks, deveria ocupar 300 mega de memória a mais. Mas no momento do fork, o processo original e os 3 forks vão todos ocupar os mesmos 100 mega originais. Só quando o processo voltar a rodar e o programa começar a modificar a memória, que só esses bytes modificados vão ser copiados pro espaço do processo novo e serem modificados.

E como copy on write não altera os blocos originais, você não corre risco de corromper os dados originais durante uma operação se cair a luz. Os blocos originais permanecem no mesmo lugar. Significa que um sistema de copy on write bem implementado descarta a necessidade um journal tradicional.

Não é que ZFS não tem um journal, mas ele é superior a só um mero log circular. Além das provisões anti-corrupção com checksums por bloco, pode ser configurado pra realmente manter múltiplas cópias, usar algoritmos de checksum melhores como dedup, influenciar como requisições síncronas são feitas e controlar o cache pra balancear performance, mas com algum risco de perder o que tá no cache como já expliquei.

O ZFS olha pra um NTFS ou HFS+ e cospe no chão. Porém o ZFS é tudo menos de fácil. Usabilidade pra usuários não técnicos é baixa. Se você configurar o ZFS errado vai sim perder dados ou corromper tudo. É aquela velha história, você pode configurar todos os aspectos de como o ZFS funciona, mas se mandar ele acelerar e bater na parede, é isso que vai acontecer.

Mesmo assim, muita gente gostaria de ver o ZFS no MacOS e por anos ficou no ar essa expectativa. Mas isso nunca se materializou. A Apple não gosta de arriscar. E com o controle da Oracle ela desistiu do ZFS e começou a desenvolver um novo filesystem dentro de casa mesmo. Isso levou ao APFS que saiu só em 2017 no iOS 10.3 e macOS 10.13 High Sierra.

Não é um ZFS mas pelo menos é moderno. Eu chutaria que supera o NTFS do Windows. De cara ele tem essa funcionalidade de cópias baratas e deduplication usando delta extents. Se você tentar copiar um diretório gigante, vai ser barato porque não vai duplicar os bytes do conteúdo.

Melhor que isso, APFS implementa snapshots sem fazer cópia de todos os diretórios e arquivos, parecido com o que expliquei do ZFS. O Time Machine da própria Apple que é o sistema de backup deles meio que já tentava fazer isso usando o recurso de hard links. Isso é em nível de arquivo, ZFS é no nível de bloco.

Além disso o APFS incluiu recursos que o NTFS já tinha como encriptação moderna, integridade de dados via checksums, proteção contra crashes usando uma redirect-on-write que é parecido com copy on write e por último compressão dos dados.

Eu nem mencionei ainda, mas compressão é uma coisa que eu particularmente não curto muito. Acho que não compensa o trabalho nem o risco. NTFS e ZFS também tem suporte a compressão. Talvez valha a pena se a maioria dos arquivos no sistema for fácil de comprimir como arquivos de texto, que desperdiçam muito espaço. Mas coisas que já são comprimidas como imagens JPG, videos com codecs que já são comprimidos como H.265 ou NVENC, o benefício é muito pequeno. Se você não sabe que precisa de compressão então não precisa de compressão.

É diferente de encriptação, isso eu recomendo que todo mundo ative, especialmente em notebooks que podem ser facilmente roubados num aeroporto da vida. A última coisa que você precisa é que alguém acesse seus dados. Ter uma senha não é suficiente porque dá pra montar um HD em outro computador e ler os dados. Macs sempre tiveram o FileVault em cima do HFS+ mesmo, NTFS tem o sistema BitLocker e Linux tem o LUKS. Então todos os principais sistemas operacionais suportam encriptação e você deveria ligar.

Como a maioria das CPUs modernas tem instruções de encriptação como AES implementados em hardware a perda de performance é imperceptível. Então perda de performance nem é uma boa desculpa. Só se lembre de não esquecer a senha, porque se esquecer é impossível recuperar seus dados. A única boa desculpa pra não encriptar seus volumes é se você for uma desgraça pra gerenciar chaves.

Isso me lembra de outro recurso de sistemas de arquivos que é safe delete. Não sei se você já consegue intuitivamente entender, mas um arquivo é dividido em múltiplas estruturas. Uma coisa é uma struct como dentry e inode que vão guardar coisas como o nome do arquivo, datas de modificação criação, permissões, etc e outra coisa é o data fork, o linguição de bytes do conteúdo do arquivo propriamente dito.

Quando você apaga um arquivo, é rápido porque só tem que apagar o inode da árvore e ponto. Porém os bytes do arquivo em si vão continuar no disco. Só não ter nenhuma estrutura apontando pra eles. Se você tiver treinamento forense vai conseguir ler os bytes crus do HD e pode achar dados não encriptados em arquivos texto. Se você guardou senhas num arquivo de texto e depois apagou, esse conteúdo ainda vai estar no disco. Por isso sempre se fala pra não guardar senhas em arquivos.

A única forma de garantir que os dados em si foram apagados é sobrescrever bits por cima dos bits originais múltiplas vezes. Se você sobrescrever os bits do conteúdo, de fato tá apagando os dados. E precisa ser múltiplas vezes por uma característica de discos magnéticos de HDs mecânicos de manter as camadas magnéticas antigas embaixo das novas.

De novo, se você for um técnico forense com técnica e equipamento adequado, consegue “raspar” os bits da camada mais nova e tentar ler os bits da camada de baixo. Por isso que um safe delete vai sobrescrever todos os bits do arquivo múltiplas vezes. E por isso é demorado e quase ninguém faz. Mas se seu HD estiver encriptado, basta perder a chave. Os dados já eram invioláveis porque os bits tão bagunçados e sem a chave não dá ler, então não precisa sobrescrever nada.

Além do APFS pra Mac, o mundo Linux também ganhou uma opção mais moderna. Como teve toda essa controvérsia da Oracle, licenças e tudo mais, apesar de existir uma versão aberta de OpenZFS pra Linux, a adoção é baixa. Só distribuições focadas em serem instaladas em servidores de arquivos que usam. No mundo doméstico, só agora com um Ubuntu 20 que apareceu a opção de modo fácil de instalar.

Mas toda essa controvérsia abriu caminho pra um projeto novo e mais moderno, o btrfs que se lê como butter, de manteiga, embora eu sempre achasse que era better, de “melhor”. Mas btr tem a ver com a estrutura de dados que usa por baixo, que é um B+Tree melhorado. Tem um paper que explica a inovação dessa nova estrutura de dados. Lembra toda a movimentação de nós que precisa fazer pra rebalancear uma árvore? Essa versão o interessante parece ser que ele precisa fazer bem menos operações de rebalanceamento.

O importante é que o btrfs também é um filesystem de nova geração como o ZFS, que ao mesmo tempo é um filesystem e um gerenciador de volumes. E também como o ZFS permite criar volumes em cima de um pool de HDs. É implementado com copy on write, permite deduplicação de dados e snapshots baratos.

Assim como o OpenZFS, poucas distros suportam btrfs desde a instalação. O Ubuntu 20, além de OpenZFS também passou a suportar btrfs na instalação. O OpenSUSE já vinha suportando também. A Suse tem histórico de adotar filesystems mais modernos mas possivelmente mais instáveis como foi o caso do ReiserFS no começo do século. O Fedora 33 também começou a adotar em 2020 então estamos bem num ponto de inflexão onde o btrfs tá estável o suficiente pra ser mais adotado.

O fato é que o ext4 é compatível com o ext3 que é compatível com o ext2. É um dos códigos mais antigos da história do Linux. Isso facilitou adoção mas adicionar funcionalidades novas foi ficando mais e mais difícil e mesmo os desenvolvedores do ext4 concordam que já chegou num limite e acham que coisas mais avançadas só vão ser possíveis em cima do btrfs.

Não tem mais nenhum outro filesystem no Linux com potencial porque o OpenZFS precisaria resolver esse problema de licenças e tudo mais. O JFS da IBM ou o XFS da Silicon Graphics também são antigos e pouca gente tem interesse em dar suporte. APFS é proprietário só da Apple e NTFS continua proprietário só da Microsoft. Só sobrou mesmo o btrfs.

Eu comecei a usar btrfs no meu Arch Linux Manjaro. E embora o Manjaro não dê suporte total na instalação, foi bem fácil configurar a partição manualmente. E uma vez instalado é transparente pro Linux e funciona muito bem. Essa transparência é muito porque todo sistema operacional moderno hoje funciona com um VFS ou virtual file system, como falei no começo.

Dessa forma você não precisa fazer aplicações específicas pra cada filesystem e por isso o Nautilus do GNOME que é o equivalente do Explorer de Windows ou Finder de Mac vai conseguir realizar as operações básicas como listar diretórios, copiar arquivos, renomear diretórios e coisas assim em qualquer filesystem, seja ext4 ou btrfs.

Mas pra fechar a história ainda faltou falar do último filesystem. Eu disse que o APFS e mesmo o HFS+ antes dele são proprietários da Apple, sem código aberto. Então, se você formatar um pendrive em APFS, na prática só vai conseguir ler em outro Mac. O mesmo vale pro NTFS da Microsoft. Hoje em dia a gente até consegue pelo menos ler dados de NTFS em Mac e Linux, mas escrever ainda é instável porque os drivers não são suportados pela Microsoft e nunca se sabe quando uma atualização do NTFS vai deixar volumes que dependem do driver open source corrompidos.

Por outro lado, todo filesystem de Linux é aberto mas nem Apple e nem Microsoft tem interesse em dar suporte nativo no MacOS ou Windows. Ou seja, se você precisa transferir dados entre diferentes sistemas operacionais, como faz?

A forma mais fácil talvez seja usando NFS que é o network file system. É como você se conecta a pastas compartilhadas na rede local. NFS é um protocolo pra filesystems distribuídos em rede, desenvolvido pela Sun. Pois é, a Sun foi um dos desenvolvedores mais influentes dos anos 90 e 2000, uma pena que morreu. Como é código aberto, praticamente todo mundo suporta NFS.

O mundo Windows obviamente tem protolos proprietários como SMB e CIFS. CIFS é o sucessor do antigo Samba. A menos que você precise se conectar em algum servidor antigo em Windows 2000, vai usar CIFS. SMB é o Server Message Block mas a gente conhece como Samba mesmo, é bugado, tem buracos de segurança e não é recomendado. CIFS é o Common Internet File System. Mesmo em Linux e Mac dá pra se conectar com esse protocolo.

Felizmente nunca precisei lidar muito com nenhum deles mas meu feeling é que NFS tende a simplesmente funcionar e CIFS vira e mexe tem probleminhas. Mas hoje em dia, pra maioria da população, ambos funcionam bem o suficiente pra copiar arquivos entre seu PC e seu notebook por exemplo.

Mas e pendrives? Pendrives são dispositivos USB com chips de armazenamento com memória flash. Além de HDs externos que são basicamente caixinhas com adaptadores SATA pra USB, temos pendrives e SD cards. E SD cards variam em qualidade. Os melhores são os SDXC UHS. Se você não é da área de video nem deve saber que existia diferença. Mas SD card e mini SD card tem classes diferentes de velocidade.

A classe 2 é a mais lenta, nem sei se ainda existe porque é só de 2 mega por segundo, horrível de lento. A Classe 4 é 4 mega por segundo. Classe 6 é 6 mega por segundo. Classe 10 é 10 mega por segundo. Eu pessoalmente acho 10 mega por segundo horrível, mas a maioria dos SD card baratos que você achar podem ser de 6 mega ou menos.

Os realmente bons, que qualquer câmera de 4K vai exigir, são os SDXC UHS que é Ultra High Speed. E mesmo assim não é tão ultra high assim. O UHS 1 ou U1 são os mesmos 10 mega por segundo da classe 10. O top de linha são os UHS 3 ou U3 que são 30 mega por segundo de velocidade de gravação sequencial.

Assim como no caso de USB que tem o tipo de conector como USB Type-C e USB, o protocolo, como 3.2 Gen 2, ainda tem os tipos de barramento de SD Card. Normal é pras classes 2 até 6. High Speed é pra clase 10, e UHS-I é pra U1 e UHS-II é pra U3. Na prática é simples, se você for amador, classe 6 é mais que suficiente. Se for profissional, pára de fazer economia porca e compra SDXC U3. Senão não tem como gravar 4K acima de 60 quadros por segundo.

Outro dia quero tentar explorar mais sobre video. Mas de volta a SD Cards e pendrives. Que filesystem vamos usar neles? Qualquer um serve, mas se quiser usar o pen drive pra copiar arquivos de um Mac pra Windows ou Linux, existe algum filesystem que funciona em todos?

Ironicamente tem, e é um derivado do FAT32. Sei lá porque a Microsoft resolveu ser bonzinha com o mercado a abriu a especificação do FAT e criou o exFAT ou extensible FAT em 2006. Provavelmente pelo crescimento do mercado de multimidia, de câmeras fotográfica e video. Ela viu que ninguém tava a fim de adotar o NTFS. Antes que acabassem adotando outro padrão, ela escolheu o menor de dois maus e criou o exFAT como padrão aberto.

O exFAT é um filesystem com cheiro de mofo desde o nascimento. É o pior em termos de funcionalidades comparado com todos que expliquei hoje. Perto de um ZFS ou btrfs ou mesmo o APFS, o exFAT é um neandertal andando nos tempos modernos.

Mas isso não importa. Um filesystem de dispositivos pra gravação de câmera não precisa de gerenciamento de volumes e pools de storage. Não precisa de compressão nem de encriptação porque velocidade é prioridade. E não tá nem aí pra journaling, copy on write ou qualquer coisa assim. Um dispositivo pra câmera precisa só ser muito rápido e suportar arquivos muito grandes. Só. Porque logo depois da gravação os arquivos vão ser copiados pra um servidor de ingestão de video e o SD card ou HD externo vai ser apagado pra próxima gravação.

Ninguém vai manter nada importante em exFAT por muito tempo. Os arquivos só precisam durar o suficiente pra serem transferidos pra outro lugar depois, como um servidor rodando OpenZFS. E lá sim, precisa de todas as garantias de redundância que já expliquei. Mas numa câmera? exFAT suporta volumes de até 16 exibites teóricos, e nem existe um SD card perto disso. E suporta arquivos de até 16 exibites também. Ou seja, não tem nenhuma garantia que semana que vem seus arquivos vão estar lá, mas foda-se, não precisa durar tudo isso, só precisa ser rápido.

E a ironia é isso: o exFAT sendo o filesystem o descendente dos anos 80 e não tendo implementado nenhuma funcionalidade moderna, ficou rápido hoje. Ele é simples de dar suporte. Não tem nada complicado como gerenciador de volumes ou encriptação, é só o bom e velho FAT só que sem limites de espaço e tamanho de arquivos. Sendo simples assim, ficou fácil dar suporte e por isso além de Windows tanto a Apple quanto Linux passaram a dar suporte.

Interessante como o único filesystem universal hoje é o exFAT. Se você vai transferir arquivos entre máquinas com sistemas operacionais diferentes ou com coisas como câmeras, provavelmente vai usar SD cards ou HDs externos formatados em exFAT.

E aqui termina nossa jornada sobre dispositivos de armazenamento e sistemas de arquivos. A intenção foi dar contexto de como as coisas evoluíram, como uma se relaciona com a outra e porque são importantes. Espero que isso tenha ajudado a dar uma luz nessa sopa de letrinhas. Se ficaram com dúvidas mandem nos comentários abaixo. Assinem o canal, cliquem no sininho, compartilhem o video pra ajudar o canal. A gente se vê, até mais.

DESCRIÇÃO

Como seus programas sabem onde encontrar arquivos no HD? Como diretórios e arquivos são organizados?

Conteúdo

• 00:00 - Intro
• 00:47 - Revisando sobre Cartuchos
• 03:46 - Sprites em Arquivos?
• 06:24 - Primeiros Sistemas de Arquivos
• 09:12 - Anos 80: Tudo incompatível
• 09:34 - Revisando MBR
• 12:55 - FAT12
• 15:42 - FAT16
• 16:37 - Windows 95 - Nomes Longos
• 17:48 - Introdução a Bit Vector
• 19:28 - VFAT
• 21:09 - FAT32
• 22:03 - Microsoft e IBM
• 23:23 - IDE, SATA, AHCI, etc
• 25:15 - HPFS ao NTFS e HFS
• 25:53 - B+Tree
• 27:28 - Resource Fork e Alternate Streams

Links

• Design of the FAT file system (https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system)
• A Disk Editor View of the NTFS Boot Sector and “Bootstrap Code” for Windows™ 2000 and XP (https://thestarman.pcministry.com/asm/mbr/NTFSbrHexEd.htm)
• FAT (https://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html)
• FAT (https://wiki.osdev.org/FAT)

SCRIPT

Olá pessoal Fabio Akita

Depois dos últimos episódios espero que vocês tenham entendido mais sobre como HDs são organizados em partições e volumes e como seu computador boota e acha o sistema operacional instalado no HD. Hoje quero explicar o que tem dentro dos volumes do HD: os sistemas de arquivo ou filesystems.

Vou começar contando um pouco o que me lembro. De como a vida era difícil nos PC dos anos 80 e 90 com o maldito filesystem FAT, que corrompia fácil. Apesar de muita gente não gostar, o NTFS do Windows NT foi um adianto de vida enorme. No Linux a gente tinha a série ext de filesystems. Nos Macs tinha HFS. Mas qual a diferença?

(…)

Antes de começar o assunto eu queria voltar de novo alguns episódios pra trás. Vocês já devem ter notado que fico insistindo nos videos de introdução a computação com videogames e mencionar cartuchos. Quando falei de cartuchos pela primeira vez foi só pra chegar nessa introdução de hoje.

Vocês lembram que nos chips da ROM a gente guarda as instruções do jogo em si mas numa região especial tem todos os assets do jogo, as imagens ou tiles, que formam os sprites dos personagens, por exemplo. O intervalo de endereços que definem a área CHR, que provavelmente quer dizer characters. Sem mappers só tem um intervalo pequeno de 8 kilobytes do endereço 0000 até 1FFF.

Sprites, como do Super Mario, são formados por tiles ou azulejos. Quatro tiles formam o Super Mario. Cada tile com 8 por 8 pixels. Então o Mario inteiro são 16 por 16 pixels. Vamos fazer umas continhas de padeiro. Sem nenhum mapper, pode ter no máximo 8 kilobytes ou 8 mil cento e noventa e dois bytes. Acabei de falar que cada tile tem 8 por 8 pixels. No Super Mario conseguiram entuchar quinhentos e doze tiles.

Portanto, cada pixel só pode ser representado por 2 bits de cor. E pra um NES é mais que suficiente. Hoje em dia, numa imagem normal, se representa cada pixel com pelo menos 24-bits, 8-bits pra cada cor. Se você já mexeu com HTML e CSS, já deve ter escrito uma cor em 24-bits.

Por exemplo FFFFFF é branco. O primeiro FF é o hexadecimal de 256, e representa vermelho. O segundo FF é pra verde e o terceiro é pra azul. Os três no valor máximo de 8-bits que é FFFFFF, vai dar branco. FF0000 significa vermelho no máximo e zero pra verde e azul.

Hoje em dia tem bem mais cores que isso, em vez de 24-bits podemos usar 30 bits, onde cada uma das 3 cores básicas pode ser representada com 10-bits. Por isso, quando você vê um monitor ou TV moderna dizendo HDR-10 é High Dynamic Range com cores de 10-bits. Mas cores é assunto pra outro dia. O problema é o seguinte: se um tile de nintendinho fosse representado com esse tanto de cor, 30-bits, um tile de 8 por 8 pixels seria 8 vezes 8 vezes 30, ou seja mil noventos e vinte bits. Divide por 8 pra ter em bytes e isso seria duzentos e quarenta bytes.

Só que aí, nos nossos pobres 8 kilobytes de ROM no cartucho, só caberia trinta e quatro tiles. Pra fazer caber quinhentos e doze, o máximo que podemos usar pra cores são 2 bits, meio byte. E por isso em videogame antigo tinha uma outra estrutura de dados que são as paletas de cores. Note no debugger do emulador Mesen que embaixo do zoom do tile tem uma estrutura de 4 cores, essa é a paleta atual.

A gente pode mudar a paleta e as cores dos tiles vão mudando. É assim que se consegue reusar os tiles que formam a nuvem e tem cores como azul e branco e pra fazer o arbusto, basta trocar a paleta pra verde. Olhem aqui no nosso debuger como esse tile tá verde, mas quando aparece a nuvem na tela, muda pra branco. É o mesmo tile, só muda a paleta.

Sem detalhar porque, o nintendinho tinha uma paleta total de 54 cores mas cada tile só podia escolher entre uma paleta que tem no máximo 3 cores, mais o preto, então 4 cores, representado por 2-bits. Isso faz cada tile de 8 por 8 pixels ocupar 32 bytes e num cartucho simples, sem mapper, do endereço 0000 até 1FFF, cabe no máximo quinhentos e doze tiles.

Se a gente fosse fazer esse joguinho do super mario num computador moderno, como você faria? Um jeito ingênuo, já que não usamos mais cartuchos, seria gravar cada tile em um arquivo, tipo tile1.png, tile2.png, etc. Cada arquivo contendo exatamente os 32 bytes de cada tile. A parte divertida é que o arquivo na verdade vai consumir mais que 16 bytes. Por que?

Porque só o nome do arquivo “tile1.png” tem 18 bytes (em double byte, letras em UNICODE, lembra?). Só o nome já aumenta quase 50% o tanto de bytes. E não acaba aí. Em qualquer gerenciador de arquivos você consegue ver coisas como a data de modificação do arquivo. Precisa guardar esses bits, e digamos que ocupe 1 byte ou mais. E tem que guardar em que diretório esse arquivo tá, então no mínimo mais um ponteiro de endereço pra estrutura de diretório.

E na realidade tem mais metadados que isso, então cada arquivinho de 32 bytes vai ter quase o triplo de bytes pros metadados. Num Linux, na realidade, é mais que isso. Cada arquivo tem 2 kilobytes de metadados e estruturas. Os metadados são maiores que esse conteúdo. Por isso que você não deveria tentar guardar uma coisa tão pequena num arquivo. Claro que ninguém faz isso, mas só pra explicar caso você nunca tenha pensado nisso: metadados custam bytes e não são poucos. O tamanho de um arquivo não é só o tamanho do conteúdo.

Se o cartucho de Nintendo usasse um sistema de arquivos como um ext4 de Linux moderno, a gente não ia conseguir colocar quase nenhum tile nele. Só de metadados inúteis já ia encher. Aliás, a configuração do ext4 não ia caber no cartucho. E por isso que um cartucho não usa sistema de arquivo. Nenhum tile tem nome nem nada, só direto o endereço. Sistema de arquivos substitui a necessidade de lidar com endereços, ao custo de adicionar peso pra dar nome e organização pras coisas.

Se eu fosse simular um cartucho numa linguagem moderna, os bytes de tiles, guardaria num array. E se fosse gravar num dispositivo, gravaria todos os bytes crús juntos num arquivão só. Aliás, é isso que é uma imagem de ROM de cartucho que você roda num emulador: todos os bytes crus do cartucho. Mas aí, como você ia carregar só o tile correto? Igual se fazia antigamente: indo na posição desse arrayzão onde começa o tile e mandando ler só 32 bytes.

Quando a gente espeta um cartucho num videogame ou num microcomputador antigo como um Commodore, é o equivalente a espetar mais memória já pré-carregada. Quando executa um jogo num PC que tá gravado num disquete ou mesmo HD, primeiro ele carrega o jogo na memória, então tem um passo a mais e gasta a RAM. Sistema de arquivos aparece quando a gente passa a ter um dispositivo de armazenamento, de onde vamos carregar dados pra memória pra depois usar. Não usamos os bytes direto do dispositivo porque é lento demais.

É a transição da fase que computador só tinha memória e expandia com cartuchos. Daí passamos a usar gravador de fita cassette pra guardar os bytes do programa, literalmente uma fita de bytes. Um Commodore 64 usava um sistema de arquivos bem rudimentar, basicamente uma lista ligada com a coordenada de trilha e setor, 2 bytes pro próximo bloco e duzentos e cinquenta e quatro bytes de dados. Acho que era uma tabela de nomes de arquivos e cada arquivo sendo uma lista ligada assim.

O problema é que só dava pra escrever sequencialmente, e o próximo arquivo começava a partir do último endereço do último arquivo mais um byte e seguia assim. Se apagasse um arquivo, aquele espaço no meio não dava pra ser reusado automaticamente sem usar um comando como MOVE pra literalmente mover os arquivos que tavam depois pra ocupar os bytes antes.

Quando pensamos em dados, seja um único arquivo ou vários arquivos, na nossa cabeça a gente pensa como num cartucho: tudo empacotado um atrás do outro bonitinho. E no fim dos anos 70, no mundo doméstico, muitos computadores eram usados assim: você plugava um cartucho de jogo, jogava e desligava a máquina. Fazia uma conta de calculadora, e desligava a máquina.

Carregava um jogo de uma fita cassette, jogava, e desligava a máquina. E toda vez que desligava, tudo que tava na memória RAM apagava e era isso aí. Videogames até a era de um super nintendo, não gravavam nada em lugar nenhum. Com exceção de cartuchos que dava pra salvar o progresso do jogo, que era basicamente um chip de RAM ligado numa bateria daquelas de relógio dentro do cartucho.

Sistema de arquivos era mais comum num computador comercial, um mainframe ou minicomputador, rodando UNIX, gravando as coisas em rolos de fita gigantes ou nos primeiros HDs, que também eram gigantes, suportavam só alguns kilobytes e custavam uma fortuna. Mas foi só no começo dos anos 80 que coisas como disquetes e fitas cassete começaram a aparecer.

Daí surgiram os primeiros programas de produtividade, como eu já tinha mencionado em outros episódios, editores de texto como Wordstar ou Wordperfect, planilhas como Lotus 1-2-3 ou Visicalc, bancos de dados como dBase. Você ficou o dia todo criando uma planilha de custos, precisava gravar esses dados em algum lugar. Não podia ser como antes que ia desligar a máquina, perder tudo e ter que redigitar tudo no dia seguinte. Daí surge a necessidade de sistemas de arquivos que começaram bem rudimentar em micros como MSX ou Commodore.

Nos anos 80, cada microcomputador como Apple II, Commodore e tudo mais usava um sistema de arquivos proprietário. Trocar arquivos entre micros era um saco. Além do sistema de arquivos, no caso de arquivos texto, nem todo mundo usava ASCII, então mesmo conseguindo copiar pra outra máquina, quando abrisse pra editar vinha caracteres estranhos porque cada um usava códigos diferentes pra símbolos diferentes.

Com a dominância dos clones de IBM PC e todo mundo rodando ou MS-DOS ou um clone de MS-DOS, meio que estabilizou que o sistema de arquivos mais comum seria FAT e a tabela de caracteres seria ASCII ou uma variante. FAT é sigla pra tabela de alocação de arquivos. Assim como expliquei sobre MBR ou GPT dois episódios atrás, FAT é uma estrutura de dados que define como que arquivos e diretórios são gravados e organizados. O MBR ocupa o primeiro setor da primeira trilha do primeiro cilindro, logo na sequência os próximos setores vão guardar a FAT.

Naquela época a maioria das pessoas não tinha HDs, no máximo floppy ou disquetes. Acho que os primeiros tipos, que gravava só de um lado não era mais que 160 kilobytes no total. A gente grava informações sobre o disco e a tabela de arquivos, ou mais corretamente, tabela de alocação de arquivos que é File Allocation Table ou FAT, nos primeiros setores da primeira trilha do disco, lembra? Se as estruturas de dados pra guardar esses dados fosse muito grande, ia usar parte significativa desses 160 kilobytes.

Pra ter uma imagem na cabeça pense no seu disco sendo um linguição de bytes, que a gente pode desenhar como sendo várias linhas uma embaixo da outra. Você já sabe que HDs lêem bytes em blocos. O HD reconhece setores e vai lendo de 512 em 512 bytes. O primeiro setor do disco, lá no endereço 0 é o master boot record, que é uma estrutura de dados que vai configurar as partições. Sendo 512 bytes vai do endereço 0 até 01FF.

Existem várias versões de MBR, que foi evoluindo até ser substituido por GPT como você já sabe. Mas na primeira versão, a partir do endereço 01BE tinha entradas de partição, que é outra estrutura de 16 bytes. No MBR original eram 4 espaços de 16 bytes reservados pras 4 partições possíveis. Era só isso até criarem o conceito de partições extendidas, mas nem vou perder tempo detalhando porque hoje a gente usa GPT, que permite muito mais partições, mas também ocupa mais que um setor no começo do disco.

Independente se é MBR ou GPT, só entender que o primeiro setor do disco é reservado pra ter esse índice. E cada entrada de partição que você configurar com um fdisk da vida vai ter a coordenada em CHS no caso de MBR ou LBA no caso de GPT. Enfim, o endereço onde começa e outro endereço pra dizer onde termina. Daí a BIOS ou UEFI, depois de achar a primeira partição, vai continuar o bootstrapping, carregando o bootloader do sistema operacional, que finalmente vai carregar a kernel, drivers e terminar de bootar a máquina.

Agora você entende quando a gente abre um aplicativo como o Disk Management do Windows e vê essas partições. Elas ficam gravadas nessa área de GPT, e olha só como tem uma partição de 184 mega que é o EFI System Partition, que é pra onde a UEFI vai apontar no boot pra carregar a kernel do Windows. Tem outras partições maiores, de quase 500 mega, que provavelmente é a partição de recuperação. Quando você tá com problemas no boot, vai ter um sistema de emergência pra diagnosticar. Hoje que temos espaço sobrando, deixar reservado meio giga ou um giga, não é uma perda grande se for facilitar nossa vida caso algo dê pau.

Hoje é comum ter pelo menos 128 giga num HD barato. Mas no começo dos anos 80 o comum era no máximo ter 40 kilobytes num cartucho ou 160 kilobytes num disquete. A gente não tinha espaço pra ficar perdendo. Então imagine que os primeiros sistemas de arquivo tinham que ser super simples. Daria pra fazer vários episódios falando de cada um mas vou resumir.

O mais comum no começo foi o FAT12, que tinha endereços de 12 bits. Diferente do que fizemos com memória onde cada endereço aponta pra um byte na memória, endereços de HDs apontam pra clusters. Neste ponto vocês já devem estar começando a se acostumar com o conceito de uma estrutura de dados, tipo uma struct de C mesmo, onde cada campo tem um tamanho fixo em bytes. Sabendo o tamanho de cada campo podemos ir achando os campos no linguição de bytes. Foi assim quando expliquei sobre arquivos executáveis como ELF de Linux, ou o próprio MBR que é tipo uma estrutura de cabeçalho que define o drive.

Do byte 0 até 2 vai ter uma instrução de JUMP de assembly pra um endereço. O bytecode dessa instrução e o endereço vai depender da versão do MS-DOS ou Windows NT, mas é aqui que a BIOS passa o controle pro sistema operacional. Nos bytes seguintes vai ter outras informações como o nome do fabricante, daí vem as informações do layout do drive.

Nos bytes 11 e 12 tem o número de bytes por setor, que costuma ser 512 mas pode ir até 4 kilobytes que é 4096. No byte 13 tem o número de setores por cluster. Eu falei que o sistema de arquivos vai lidar com clusters e clusters pode ser um ou mais setores. É aqui que vai definir isso. Podemos colocar quanto de espaço queremos ter no drive.

Aqui que vem o 12-bits no FAT12. A tabela FAT12 consegue indexar até 2 elevado a 12 endereços pra clusters. Até 4 mil e noventa e seis clusters. Se o cluster tiver 2 setores de 512 bytes cada, o tamanho máximo que dá pra ter na partição vai ser 4 mil e noventa e seis vezes 2 setores, vezes 512 bytes, ou 4 megabytes. O que seria muito pouco. Mas se aumentar o tamanho dos setores de 512 bytes pra 4 kilobytes, esse valor aumenta pra até 16 megabytes.

Qual o problema de fazer isso? Lembra que expliquei no episódio de HDs que um arquivo vai ser gravado um setor de cada vez. Na realidade, vai ser gravado cluster a cluster porque é isso que o FAT reconhece. Então se cada cluster tiver 2 setores e cada setor tiver 4 kilobytes, se pegarmos um arquivo de 40 kilobytes pra gravar, precisamos reservar 2 clusters inteiros na FAT pros primeiros 32 kilobytes. Mas os 8 kilobytes restantes vai ocupar o próximo cluster inteiro. Ou seja, vai desperdiçar espaço no fim desse cluster. O arquivo de 40 kilobytes na realidade vai ocupar 48 kilobytes reais no disco. É um desperdício de 20% do disco.

Se você escolher um setor de 512 bytes como antes, cada cluster só vai ter 1 kilobyte. Mas o FAT só consegue indexar os mesmos 12-bits, 4 mil e noventa e seis clusters. Aí só dá pra ter uma partição de 4 megabytes em vez de 16. Naquela época isso não era ruim, porque a gente lidava mais com disquetes. No começo dos anos 80 o mais comum acho que era o disquete de 5 e 1/4 polegadas de 360 kilobytes. Então setores de 512 bytes tava de boa.

O problema foi do meio pro fim dos anos 80, quando passamos a ter HDs ou winchesters. Em 1990 eu tinha um winchester de 10 megabytes. Agora o FAT12 sozinho não ia dar conta. Por isso foi atualizado pra FAT16. Agora a tabela podia ter 2 elevado a 16, mais de 65 mil clusters. Se manter 2 setores por clusters e setores de 512 bytes mesmo, ainda assim já daria pra ter uma partição de até 64 megabytes. Então tava seguro. Até o meio dos anos 90 pouca gente tinha um HD tão grande assim.

Se você não tá acostumado com megabytes. Seu HD no seu computador aí deve ser de 128 giga ou mais. Se for um computador bem barato talvez seja de 64 gigas. Espero que não, porque o diretório C:\Windows sozinho deve estar ocupando mais de 20 gigas. 1 giga é mil e vinte quatro vezes 1 mega. Ou seja, um HD de 64 giga é mil vezes maior que um HD de quase 30 anos atrás.

Mas aí, no meio dos anos 90, chegou a hora de aparecer o Windows 95, que ia tentar tirar o atraso nas interfaces gráficas que sistemas como Amiga e Mac já tinham faz anos. Mas construir uma interface gráfica em cima do FAT16 tinha um grande problema: a estrutura de dados que se chama “directory entry” era gravado assim no disco:

Os primeiros 11 bytes era o nome do arquivo de 8 bytes e uma extensão de 3 bytes. Só quem usou micros antes de 95 lembra disso. Era horroroso ficar criando vários documentos, planilhas, código fonte de programa e estar limitado a nomear arquivos só com 8 letras. A gente tinha que ser criativo. Mas era assim porque espaço de memória ou disco até aquele ponto custava muito caro. Lembra que eu falei que nome de arquivo ocupa espaço?

Eu lembro quando programava Clipper que a gente seguia essa convenção no nome dos campos em tabela de banco de dados. Era muito comum ter campos como CODCLI pra código de cliente, ou NOMCLI pra nome de cliente, DATVAL pra data de validade e assim por diante. Aliás, era pra economizar memória que datas eram gravadas no formato YYMMDD que é dois digitos pra dia, pra mês e pra ano, considerando que se YY fosse 80 então era 1980.

De qualquer forma, precisava resolver isso. Nessa entrada de diretório, que usava pra diretório e pra arquivo, o byte 11 depois da extensão era um vetor de bits. Outro dia vou falar das vantagens de um bitvector e bitmasks, mas deixa eu resumir.

Um byte tem 8 bits. Você pode pensar em cada bit como se fosse um interruptor de luz. 1 é ligado e 0 é desligado. E o campo inicializa com tudo zerado. No caso do FAT, se eu ligar o 1o bit, o bit 0, significa que é um arquivo ou diretório só de leitura. Se ligar o bit 1, é um arquivo ou diretório escondido. No caso de um Linux, ser escondido é ter o primeiro byte do nome sendo um ponto, os dotfiles. Mas no FAT é só 1 bit, então pra indicar se um arquivo é escondido em FAT usamos 7 bits a menos que no Linux.

Continuando, se ligar o bit 2 vai indicar que é um arquivo especial do sistema. Se ligar o bit 3 é a etiqueta ou nome do volume. Se ligar o bit 4 finalmente indica que essa estrutura tá definindo um subdiretório. Por outro, lado se ligar o bit 5 é um arquivo. Imagino que os bits 4 e 5, só um deles pode ser 1 e o outro 0. Já os bits 6 e 7 não significam nada e são ignorados.

Ou seja, em um único byte a gente conseguiu enfiar 6 informações diferentes. Se você fizesse do jeito ingênuo como uma struct com 6 campos int, ia gastar 6 bytes inteiros, 5 bytes a mais do que usando um único campo de 1 byte. Isso é muito comum pra guardar informações que é só verdadeiro ou falso, 1 ou 0. Você só precisa de 1 bit pra representar essa informação. Essa técnica aumenta a densidade de informações por byte.

E eu me dei ao trabalho de explicar isso porque a forma de permitir nomes longos a partir do Windows 95, foi atualizar o FAT16 pra VFAT. E a principal diferença é que toda vez que cria um arquivo vai criar duas entradas de diretório. Um igualzinho o que acabei de explicar, começando com 11 bytes pro nome no formato antigo de 8 letras e extensão de 3 letras. Mas a segunda estrutura ia entuchar mais bytes no meio pra caracteres, agora em formato UNICODE em vez de ASCII, já que a ambição do Windows 95 era expandir pelo mundo em diversas línguas.

Pra programas de DOS antigos não se confundirem, ainda ia ter a estrutura antiga, que ia ignorar a estrutura nova. Pensa que na mesma lista você tem as duas estruturas. Mas aí o DOS antigo ia ler o byte 11 que é o bitvector de atributos e encontrar 0xF, tudo ligado 11111111, que é um atributo inválido, então um DOS antigo ia ignorar.

Na prática, você podia digitar um documento no Word do Windows 95 e salvar como hoje, com um nome como “Escopo do Projeto Secreto.doc”. Vai gerar uma entrada de diretório com caracteres UNICODE normalmente e junto gerar uma segunda entrada com uma versão no formato antigo de 11 bytes. Provavelmente vai ser “ESCOPO1.DOC”. Se gravar outro arquivo como “Escopo do Projeto do Ano que vem.doc”, vai gerar uma versão de DOS chamado “ESCOPO2.DOC”.

Esse esquema dura até hoje no NTFS do Windows 10. Se não acredita abre um command prompt e digita “cd c:\progra1” e ele cai no “Program Files”. Se abrir o Explorer do Windows e digitar “C:\progra1”, ele vai te mandar certinho pro diretório “Program Files”. O DNA do DOS ainda existe.

O VFAT foi uma versão feita pro lançamento do Windows 95, mas logo no segundo DLC que foi o Windows 95 OSR2, a versão que funcionava de verdade, o VFAT foi substituído pelo FAT32. Você já imagina que a tabela subiu pra endereçar 2 elevado a 32 cluster em vez de 16, até 4 milhões de clusters. Com setores de 512 bytes isso daria uma partição de tamanho máximo teórico de 4 terabytes.

Se o cluster só tiver 1 setor, então ia até 8 terabytes, mas cada arquivo dentro só poderia ter 4 gigabytes. É 32-bits, então só dá pra ler e gravar 2 elevado a 32 bytes de dados crús, o que dá o famoso limite de 4 giga por arquivo. Mas a gente já viu no outro episódio que era a BIOS e o MBR que não permitiam ter partições maiores que 2 terabytes. Finalmente o FAT32 seria o filesystem que ia durar a virada do século.

Em paralelo a isso a Microsoft tentou muitas coisas dos anos 80 até começo dos 90 pra abrir mais pro mercado de workstations, onde tava a Silicon Graphics ou a Sun. Mas MS-DOS e Windows 3 não era suficiente. Por isso teve as iniciativas como o XENIX que foi um UNIX da Microsoft que não vingou e a parceria com a IBM que deu origem ao OS/2. Tem muito sistema como máquinas antigas de sacar dinheiro, as ATMs, sistema de bilhete de metrô e coisas assim que ainda rodam em OS/2.

Um dia eu tento falar do OS/2 mas ele era mais sofisticado que o Windows 95, que não era muito mais que um sistema parasita que espera o MS-DOS bootar em modo real pra depois ligar o modo protegido e dar controle pro Windows. Era uma gambiarra de coisas antigas de 16-bits misturado com coisas novas de 32-bits. A série do Windows 95, 98 até o famigerado Millenium Edition no final dos anos 90 foi uma bela de uma zona.

Já o OS/2 foi projetado pra ser um sistema mais completo de 32-bits. Acho que a primeira versão era 16-bits mas mudaram rápido. Eu cheguei a ver as primeiras versões do OS/2 que tinha a cara do Windows 3.1. O OS/2 mais famoso acho que o foi a versão 3 Warp e a que perdura até hoje em muitos lugares é a versão 4. E existe uma versão open source que foi feita via engenharia reversa, porque a IBM nunca abriu o código fonte do OS/2.

É quase impossível rodar um MS-DOS ou OS/2 dos anos 90 em máquinas modernas sem modificação. Pra começar, o processo de boot mudou de BIOS e MBR pra UEFI e GPT além disso o hardware de hoje tem mais integrações como ACPI e AHCI que é o Advanced Configuration and Power Interface e Advanced Host Controller Interface. O primeiro pra facilitar o sistema operacional encontrar hardware, configurar e gerenciar energia e a segunda pra falar com os controladores de SATA que fala com drives.

Seu HD provavelmente é SATA e não mais IDE ou SCSI. Sem entender AHCI, a gente nem encontra o HD. Quando você configura uma máquina virtual num VMWare ou Virtualbox da vida, vai notar que eles configuram um HD SCSI e não SATA. SCSI era a melhor interface da época, usado em workstations e Macs. PCs mais baratos usavam IDE mesmo.

Antigamente a gente tinha porta serial, porta paralela e barramento IDE que falava ATA. Ligava impressora na porta paralela, modem na serial. Era um saco configurar alguma coisa nessas portas e barramentos antigos. Ainda não tinha protocolos pros dispositivos se identificarem automaticamente pro sistema operacional. Pensa que isso exige mais bytes e um protocolo mais gordo e a velocidade de transferência era bem lenta.

Hoje em dia a gente tem conectores USB como Type C em vez do antigo SCSI, protocolos como USB 3.2 Gen 2 ou Thunderbolt 3 em vez do antigo ATA. Aliás, depois do ATA veio o Serial ATA ou SATA. E esses conectores se ligam em barramentos internos que falam direto com a CPU como PCI Express ou PCIe, que substituiu o antigo PCI e AGP. Essa é uma parte da história que tenho zero saudades: o tanto de problema que era conectar e configurar dispositivo. Nunca funcionava de primeira. Muito diferente de conectar um HD externo num Thunderbolt hoje, que é plug and play de verdade.

Mas vamos deixar dispositivos de lado por hoje. A parte importante é que da parceria da Microsoft com a IBM, no OS/2, surgiu o sistema de arquivos HPFS ou High Performance File System. E ele serviu de inspiração pra outro filesystem, o New Technology File System ou NTFS do Windows NT.

Em paralelo a essa história de FAT. No mundo dos Macs, tinha o Macintosh com o Macintosh File System, que era um pouco melhor que um FAT12 da vida. Mas com a Apple querendo lançar HDs nos Macintoshs eles evoluíram pra uma nova versão de filesystem chamada Hierarchical File System ou HFS.

Assim como o HPFS da IBM pro OS/2 e diferente do FAT, o HFS seria implementado usando B+Trees. Você já entendeu um pouco sobre estruturas de árvores alguns episódios atrás. E eu expliquei rapidamente sobre Balanced Trees ou B-Trees e derivações como B+Trees e B* Trees. Vocês vão ver que essas estruturas estão por baixo de quase tudo que você usa num computador.

Em resumo, são árvores balanceadas de baixa profundidado onde cada nó tem vários filhos de uma só vez. Além disso os filhos nos galhos internos só tem metadados e chaves, onde ficam os inodes. E só as folhas da árvore, os últimos nós externos lá embaixo, é que apontam pros dados em si. No caso, pra clusters ou blocos.

Tem a vantagem de ter tempo de procura razoavelmente bom, especialmente se comparar com uma mera tabela. E diferente de uma árvore binária, a profundidade vai ser baixa porque cada nó vai ter vários filhos em sequência. E como tem vários filhos por nó, nem toda operação de inserção ou deleção vai precisar promover um rebalanceamento, como eu mostrei que acontece numa árvore como red black trees.

Em discos, a vantagem é que isso ajuda a diminuir a fragmentação e aumenta a performance. Os dados são lidos e escritos em conjuntos grandes de blocos de uma só vez. Provavelmente vai desperdiçar um pouco de espaço. Mas isso é outro trade off, a gente troca um pouco de espaço em disco pra evitar fragmentação e aumentar a performance de leitura e escrita. Provavelmente tirando o antigo FAT, todos os file systems usam B+Trees. Mesmo o HFS da Apple em 1985 já era implementado com B+Tree.

Num Mac você sabe que dá pra abrir as propriedades de um arquivo e atribuir uma cor pra aparecer destacado no Finder. E dá pra selecionar o ícone, copiar, e colar em outro arquivo. Sem ter um arquivo de icone separado. E muito mais, mas você já pensou onde que se armazena essas coisas?

A cor do arquivo até pode ir nos metadados no nó da árvore mas e um ícone que tem múltiplos bytes? Ele vai num resource fork. Na realidade o nó da árvore pode apontar pra dois galhos de dados, um é o data fork que aponta pro primeiro byte do conteúdo do arquivo propriamente dito. O outro galho é o resource fork que aponta pro primeiro byte de um outro conjunto de dados escondido.

Por isso que quando você faz um arquivo zip comprimido num Mac e descompata num PC, vem um diretório estranho chamado “underline” MACOSX. Digamos que você tava compactando um arquivo chamado “retrato.jpg” então nesse diretório estranho vai ter um arquivo “._ retrato.jpg” que são os bytes que ficavam no resource fork.

Como nem todo filesystem tem suporte a resource forks, em particular FAT não tem nada nem perto disso, então o Mac é obrigado a criar arquivos de suporte pra não descartar informações. Se você copia de um Mac pra outro Mac, isso é transparente. Mas se usa um filesystem intermediário, ou um formato de arquivos como Zip, ele é obrigado a dar um jeito. O NTFS tem suporte a forks, que chama de ADS ou alternate data streams.

Se você abrir um command prompt num Windows 10 de hoje, sabe que dá pra criar arquivos texto como num shell de Linux. Basta fazer echo "hello world" > hello.txt e tá criado. Se usar o comando more hello.txt vai listar de volta o conteúdo. Trivial, todo mundo sabe isso. Mas o que muitos de você não sabem é que posso escrever bytes nesse alternate data stream do arquivo. Tente fazer echo "isto é um segredo" > hello.txt:segredo. Pronto. Se usar o comando more de novo, não vai enxergar nada, só o texto original. O que aconteceu?

Agora posso fazer more < hello.txt:segredo e olha só, o texto secreto apareceu! Se abrir num editor de textos normal, nunca vai ver esses bytes. Praticamente ninguém suporta alternate streams nos programas. Mas esse arquivo agora carrega esse segredo escondido. Pena que é um recurso que acaba sendo desperdiçado. Esse ‘segredo’ é o nome do stream de bytes e a gente pode criar vários streams diferentes.

E é mais chato ainda porque se a gente tentar copiar esse arquivo pra algum pendrive em FAT32 da vida, o Explorer vai avisar que o arquivo tem propriedades que não vão ser copiadas e parar por aí. Daí perdemos aquele segredo porque, diferente do Mac, ele nem tenta criar um arquivo separado. Como as ferramentas que gerenciam arquivos do próprio Windows male male reconhecem esses forks, eles acabam sendo inúteis pra gente.

E por hoje vou pausar essa história porque no próximo episódio vou começar a falar sobre os outros filesystems e a nova geração que usamos hoje em dia e como esse estudo em estruturas de dados foi modificando a forma como pensamos em arquivos. Se ficaram com dúvida mandem nos comentários abaixo, assinem o canal e não deixem de clicar no sininho pra não perder a continuação. Compartilhem o video pra ajudar o canal. A gente se vê, até mais.

DESCRIÇÃO

É dia de falar tudo que você sempre quis saber sobre todas as sopas de letrinhas do mundo de dispositivos de armazenamento, desde MBR, GPT, EFI/UEFI, RAID, DAS, NAS, SAN, SSD, NVME, USB, Thunderbolt e muito mais!

Conteúdo

• 00:00 - Intro
• 01:01 - Master Boot Record
• 03:32 - GPT
• 06:39 - EFI/UEFI
• 09:27 - processo de boot
• 10:41 - Secure Boot
• 13:40 - HDs como Livros
• 16:02 - Partições e Volumes
• 17:08 - RAID 0
• 17:51 - RAID 1
• 19:03 - RAID 1+0
• 19:43 - RAID 5
• 19:59 - DAS
• 20:42 - Entendendo SSD
• 21:57 - Protocolos USB
• 22:53 - NVME
• 23:50 - Conectores USB
• 24:50 - Thunderbolt
• 25:17 - HDMI
• 26:22 - Tipos de SSD
• 28:43 - Cabos Ethernet
• 30:31 - NAS
• 31:59 - Video ocupa MUITO espaço
• 34:30 - SAN e Cloud
• 36:20 - Character vs Block Device e BSD
• 39:33 - Conclusão

SCRIPT

Olá pessoal, Fabio Akita

No episódio anterior eu contei um pouco sobre meus servidores de arquivos, o Drobo e o Synology, algumas noções sobre RAID, e desci um pouco no detalhe sobre fdisk, sistema de coordenadas CHS e LBA. Hoje vou continuar essa saga falando sobre boot. Como um computador entende seus HDs.

No episódio anterior eu parei a instalação daquele RedHat de 1997 explicando sobre cilindros e como do sistema de coordenadas de cilindro-cabeça-setor chegamos no LBA que é um endereçamento linear. Acho que o mais importante era entender que num HD ou pendrive ou qualquer dispositivo de armazenamento a gente não lê e escreve dados bit a bit ou byte a byte e sim em blocos, no caso em setores, que normalmente são blocos de 512 bytes. Mas beleza, particionamos o HD com fdisk e agora, como o computador boota minha máquina?

(…)

No nível do sistema operacional você ainda tem as opções de escolha de como particionar o disco. Falando rapidamente, antigamente e até em algumas máquinas não atualizadas de hoje, o sistema mais usado era MBR ou Master Boot Record. É um setor especial no primeiro cilindro reservado como setor de boot. Os primeiros 512 bytes.

Quando o computador boota, precisa iniciar algum programa, uma primeira instrução. Essa vai ser a BIOS, um firmware que hoje é atualizável. É um chip persistente que independe do seu sistema operacional. A BIOS vai detectar o hardware, configurar sua máquina e deixar disponível pra uso. No final desse programa vai ter uma instrução de JUMP pra um endereço fixo no primeiro HD que ele encontrar. No caso o endereço com segmento 0000 e offset 7C00.

Parêntese, se você assistiu o episódio da CPU montada em protoboard do Ben Eater que expliquei no Guia Mais hardware de Introdução à computação e um dos mais recentes que foi explicando sobre os 640 kilobytes de RAM, você entendeu 100% do que acabei de falar. Instrucões, jump, segmentos. Se não entendeu, recomendo assistir esses episódios depois.

Depois ele vai checar o cabeçalho da estrutura até achar 55 AA. Essa sequência identifica um MBR. Daí vai encontrar uma estrutura, literalmente como uma struct de structs de C. A estrutura do MBR permite registrar até no máximo 4 partições.

Era o que cabia no espaço que foi definido e pra época provavelmente acharam que era suficiente. E as configurações nessa struct tem tamanho fixo. Por isso que não dá pra plugar qualquer HD moderno num computador antigo e por isso que no fdisk antigo você vê que ele só deixa cadastrar 4 partições.

O máximo que dá pra ter é 2 elevado a 32 vezes o tamanho padrão do setor que são quinhentos e doze bytes. Isso dá 2 terabytes. Então máquinas antigas com MBR não conseguem ter partições maiores.

Ah sim, falei 2 elevado a 32. Lembram do tal LBA que falei no episódio anterior? É uma lista de 32-bits. Então só vai ter endereços pra 2 elevado a 32 setores. A distinção aqui é importante. Em outros episódios eu falava de listas ou arrays onde cada endereço apontava pra um byte.

Mas a gente pode apontar qualquer coisa e um LBA é uma lista onde cada elemento aponta pra um setor. E cada setor tem X bytes. Quanto maior o setor maior a partição que daria pra usar. Acho que MBR não suportava setores de 4 kilobytes por exemplo. Então o máximo vai ser esse mesmo.

Tem jeito de gambiarrar isso um pouco com partições extendidas. Mas é gambiarra, nem vou explicar, mesmo porque hoje em dia ninguém mais usa MBR em computadores e laptops, o normal é usar GPT ou GUID Partition Table que, como o nome diz, vai usar GUIDs pra identificar as partições.

Se ficou confuso, no MBR você identificava as partições com 4 números, de 1 a 4. Mas no GPT você vai identificar a partição com um numerozão de 128-bits. Não só partição, mas tipo de partição também. Se você assistiu meu episódio sobre criptografia, eu explico GUIDs lá. Mas em resumo, quando a gente quer dar um número que tem alta probabilidade de ser único, usamos ou UUID ou GUID, no caso GUID é a versão da Microsoft do conceito de Universally Unique Identifier, GUID é Globally Unique Identifier. Quase mesma coisa.

Usar números inteiros sequenciais pequenos é garantido que alguém já vai estar usando. É que nem quando você tenta cadastrar seu apelido numa plataforma qualquer. Certeza que já tem um joão cadastrado e você é obrigado a cadastrar tipo um joão99123 e até isso já deve existir. Por isso muitas plataformas pegam seu apelido e concatenam um número aleatório no final, como o Discord.

Não usar números sequenciais é uma boa prática e outro dia eu falo sobre isso em particular, mas o ponto é que suas partições são identificadas com um GUID. O GUID é um número binário de 128-bits. E ele é representado em 5 blocos legíveis em hexadecimal. Por convenção a gente separa esses blocos com hífen pra ficar mais fácil se precisar digitar manualmente.

Vamos recapitular porque foi muita letrinha de uma vez só. Toda a explicação sobre cilindros e cabeças foi só pra relembrar como era antigamente, mas hoje é LBA, uma lista linear de endereços de 32-bits em máquinas antigas com MBR e 64-bits em máquinas modernas com GPT. Elas representam o mapeamento de setores no seu HD. Com 32-bits e setores de 512 bytes daria pra no máximo endereçar 2 terabytes de HD. Mas com 64-bits a gente tem capacidade pra ir até um HD de vários Zetabytes. Um zetabyte é tão grande que se você pegar todo o conteúdo da Internet, não ia chegar perto disso.

A gente quer conseguir endereçar tamanhos absurdos porque mesmo não tendo um único HD de mais do que terabytes, você sabe que existem recursos como stripe ou RAID-0. Nada impede alguém de tentar ir ligando vários HDs gigantes num único volume.

No fim da vida de MBR a gente tava limitado no tamanho do HD porque não tinha endereços suficientes, mesmo problema dos 640 kilobytes de RAM, mas depois que migramos pra LBA e GPT agora temos endereços sobrando e quantidade de partições sobrando.

MBR ou GPT são estruturas de dados, como structs de C, que tem campos de tamanho fixo pra armazenar a configuração do seu HD e das partições. O HD é dividido em partições e as partições são divididas em setores. Daí os primeiros setores do primeiro cilindro são ocupados com essas estruturas. Na verdade você começa a partição propriamente dita mais pra frente na lista LBA. Mas é tudo o mesmo linguição de bytes no HD, é tudo uma questão de quantos setores você quer perder pra guardar esses metadados.

No caso de GPT, ele precisa de uma partição ESP que é EFI system partition. Aí fodeu, que GPT existe mais uma sigla junto que é EFI e UEFI. Em resumo é o seguinte, o esquema BIOS e MBR ficou velho muito rápido na virada do século daí surgiu Extensible Firmware Interface ou EFI da Intel que define uma nova interface pro sistema operacional conseguir falar com o firmware.

Mas em 2005 o EFI foi atualizado pra virar UEFI. No mundo open source, quando você boota um virt-manager da vida, pra rodar uma máquina virtual vai ver que o logo que aparece é da TianoCore que desenvolve uma implementação de UEFI aberta chamada EDK2. Se você é das antigas, o que a gente chama de firmware hoje é o que antigamente era mais conhecido como BIOS. Na prática é o primeiro código que qualquer computador executa.

No caso de HD, o primeiro setor é o boot sector ocupado pela estrutura MBR. E continua sendo assim por motivos de compatibilidade. Vai ter a estrutura de dados antiga, mas se você tentar rodar ferramentas velhas tipo o fdisk de 1997, ele ainda vai encontrar o MBR lá, mas as partições de verdade não estão mais lá, vão estar em setores mais pra frente. Acho que são uns 32 setores pelo menos, com 512 bytes cada, significa que os primeiros 16 megabytes do seu HD você já não tem, porque é lá que ficam as informações pro resto.

A idéia do GPT é facilitar fabricantes e desenvolvedores de extender os metadados. Digamos que o Windows precisasse identificar uma partição como sendo de Windows, que número ele usa? Se escolher 1, e se agora a Apple também quiser usar 1 pro tipo dele? Daí que usar GUID é mais prático. Eles podem escolher um GUID qualquer e a chance de alguém já ter escolhido o mesmo é muito baixa. Em qualquer documentação sobre GPT você vai achar tabelas como essa que listam os GUIDs pra tipos de partição por exemplo.

E em sistemas UEFI tem essa partição especial pequena que se chama EFI system partition ou ESP. Se você é de linux já deve ter visto um /boot fora da sua partição principal. Pra ser universal ela costuma ser formatada em FAT, normalmente VFAT ou FAT32. E quando o UEFI termina de bootar, ela aponta pra essa partição e carrega o que tiver lá, que no caso do Linux é onde vai ter o bootloader e a kernel mais drivers.

No caso de Mac ele força que essa partição seja em HFS+ que é o filesystem antigo deles, e no caso do Windows em vez de ser /boot costuma ser /EFI/Microsoft/Boot, mas é a mesma coisa. Essa partição especial costuma ficar escondida, mas sabendo que ela existe você pode montar ela num diretório usando comandos como mount. Inclusive num Linux, quando você baixa e instala uma kernel mais nova, ao rodar comandos como update-grub da vida, ele vai atualizar a imagem vmlinuz que contém a kernel e drivers, nessa partição.

Quando a UEFI termina o que tinha pra fazer, no final do procedimento de POST que é sigla pra Power-on self-test, daí vai lá nos primeiros setores do primeiro disco e acha a tabela de partições. E dentro procura se tem uma partição com um tipo especial de GUID que começa com C12A e termina em C93B. Em todo computador com sistema operacional instalado vai ter ela, que é o ESP ou partição de boot.

Encontrado essa partição então consegue montar e ler os arquivos dentro. Se você tiver mais de um sistema operacional na mesma máquina, vai ter mais de uma configuração de bootloaders ali. Encontrado o bootloader, também acha a imagem do sistema operacional. No caso do Linux acho que cria uma ramdisk ou initial ramdisk, onde vai carregar um filesystem mínimo e continuar o processo de boot.

É o mínimo do mínimo que precisa carregar pra continuar lendo as outras partições que estão na tabela e montar com os filesystems adequados, como ext4 no caso de Linux ou NTFS no caso de Windows. Agora ele consegue abrir a partição principal, montar a raíz e ler as configurações num diretório como /etc ou o Registry no caso do Windows e segue subindo serviços, daemons, e tudo mais pra completar o boot do sistema até chegar na tela de login.

Aliás, se você tá prestando atenção deveria estar se perguntando, mas se no processo de boot ele vai pegar seja lá que bootloader e seja lá que imagem estiver nessa partição aberta de FAT, não é perigoso? Alguém malicioso ou algum virus não poderia modificar essa imagem e fazer ele carregar alguma coisa ruim?

Este não é um episódio sobre segurança então detalhes ficam pra outro dia. Mas sim, isso inclusive acontece de verdade e quando um virus ou programa carrega antes da sua kernel, ela consegue se injetar e ter privilégios de kernel. É isso que faz um rootkit. Se conseguir se injetar na kernel antes do boot, seu sistema operacional não vai conseguir detectar e ele teria a capacidade de enganar os antivirus que carregam depois, ou até comprometer os executáveis dos antivirus. Quando um programa malicioso se carrega no espaço privilegiado da kernel, ele tem acesso a basicamente tudo, é game over.

Na prática você precisou ser bem imprudente com o que instala na própria máquina. Nesse caso, rootkit ou não você tá inseguro de qualquer jeito já. Ou, você já deixa sua máquina desprotegida, qualquer um pode usar, e aí também é inseguro. Se alguém tem acesso a sua partição de boot, sua máquina tá escancarada por definição. Se você faz trabalho importante não deveria deixar aberto.

Tem gente que não sabe disso, mas conexão Thunderbolt e USB tem defeitos e bugs, e um pendrive preparado com software malicioso, só de plugar na sua máquina vai conseguir injetar malwares ou no mínimo causar um monte de problemas. Por isso em corporações tem até políticas pra proibir espetar um pendrive no notebook. Além disso UEFIs mais novas tem uma coisa chamada Secure Boot.

Resumindo, na instalação do sistema operacional, ela permite registrar um certificado digital numa área segura e assinar os binários que precisam carregar no boot como kernel e drivers. Daí em todo boot a UEFI vai checar se o binário foi modificado ou não. Se algum rootkit da vida ou alguém manualmente tentou trocar os binários então a checagem da UEFI vai falhar e ele não vai deixar bootar. Procure saber sobre isso.

Aliás, se você é gamer de jogos da Riot por exemplo, já teve que desligar o Secure Boot da sua máquina porque o sistema de anti-cheats ou anti-trapaça deles funciona como um rootkit, um driver que carrega junto com a kernel, alterando seu boot justamente pra você não ser capaz de desligar o anti-trapaça. E não é só a Riot que faz isso. Foi uma controvérsia boa porque desligar o secure boot é desligar segurança da sua máquina e isso é super intrusivo. Não sei se ainda funciona assim, mas isso é bem tosco, pra dizer o mínimo.

Parece complicado, mas ainda estamos só começando. Durante a primeira década dos anos 2000 a gente tava em transição da arquitetura de 32-bits pra 64-bits, e ao mesmo tempo fazendo a transição da BIOS com MBR antigo pra GPT e EFI e depois UEFI. Foi uma bela de uma zona pelo que me lembro, mas hoje em dia tá mais normalizado e estável. Depois de ter passado todas essas transições, eu diria que a era de 64-bits finalmente parece bem mais com o conceito de “plug and play” que vinham prometendo pra gente desde os anos 90.

Voltando pro HD, deixa eu tentar ilustrar o conceito. Os primeiros setores dessa fita é como se fossem o índice de um livro, dizendo de qual página até qual página fica cada capítulo, que seria a partição. Faz de conta que meu livro tem um índice que diz que da página 1 até a página 50 é o primeiro capítulo e da página 51 até a página 100 é o segundo capítulo.

Pra apagar o segundo capítulo, basta apagar do índice que esse capítulo existe. As páginas em si continuam no livro, mas ela só não é mais identificada. Eu não sei se da página 51 até o fim é uma partição só, ou se antes tinha dois capítulos de 25 páginas cada por exemplo. Mas o que tinha escrito nas páginas continua lá. Quando a gente apaga alguma coisa, não é que o HD foi nessas páginas e apagou tudo que tava escrito. Ela só tirou do índice.

Por isso que é possível reparticionar um disco sem perder dados. Voltando no exemplo dos dois capítulos, digamos que eu quero aumentar a segunda partição. Pra isso eu poderia ir no índice e escrever que o primeiro capítulo é só da página 1 até a 25 e da 26 até o 100 é o novo segundo capítulo.

Se as páginas estavam todas em branco, não vai fazer nenhuma diferença. Mas e se já tinha coisa do primeiro capítulo escrito lá pela página 40? A diferença de HD pra livros é que a gente não vai escrevendo necessariamente em ordem sequencial, tipo preenche toda a página 1, depois vai pra página 2 e assim por diante. A gente cria arquivos, apaga arquivos, atualiza, então vai ficando fragmentado. Pode ter metade da página 1 usada, página 2 em branco, página 3 cheia e assim vai. Portanto toda página, em média, vai ter espaço sobrando se o HD não estiver totalmente cheio.

Então eu vejo o que tem na página 26 até a 50 e se o que tem escrito lá couber nas páginas anteriores, posso copiar tudo pra lá e agora sim, reescrever o índice pro capítulo 1 ser da página 1 até a 25 e o capítulo 2 ser da página 26 até a 100. E é assim que se redimensiona partições. Só não vai dar pra reparticionar se o primeiro capítulo já tava quase cheio, daí não tem como.

No MBR antigo, nosso livro só podia ter até 2 terabytes, e só podia ter 4 capítulos ou partições. Com GPT, agora podemos ter milhares de partições e cada uma com praticamente quanto espaço a gente quiser, porque o hardware ainda não chegou nos limites estabelecidos no GPT. Lembra? zetabytes. Agora, o sistema operacional, sabendo onde começa e onde termina cada partição, quantos setores tem, toma conta e se encarrega de formatar a partição.

Vou falar de filesystems no próximo episódio. Mas a história de partições não acaba aqui. Se você presta atenção a nomenclaturas já deve ter visto a palavra “partição” mas também a palavra “volume”. Como a gente já viu, uma partição é uma divisão lógica de um HD ou qualquer outro dispositivo de armazenamento, como um pen drive. Um pen drive também pode ter mais de uma partição.

Já um volume é uma abstração do sistema operacional. No caso mais comum a gente pode ter uma partição de boot EFI, uma partição principal do sistema operacional e todos os seus programas e dados, e talvez uma terceira partição pra swap no caso de um Linux. Aliás, essa terceira partição hoje em dia é opcional porque é mais comum um swap ser só um arquivão na partição principal mesmo.

Então a gente tá acostumado a ter só uma partição que por sua vez é um único volume. Num Windows cada volume costuma ser uma letra, tipo C:, D:, e assim por diante. Quando você espeta um pen drive no seu computador, vai aparecer um novo volume montado como um E:. No caso do Linux volumes são montados como diretórios e podem aparecer como em /run/media/pendrive por exemplo.

Mas lembrem-se do caso que eu expliquei lá no começo do video, sobre RAID, e o caso mais simples como o RAID-0 que é stripe. Você instala dois HDs de 1 terabyte no seu computador. No caso normal, vai formatar um como volume C: e o outro como volume D:. Mas digamos que você não queira um segundo volume e na verdade quer que os dois HDs sejam combinados. Dá pra fazer isso, você cria um volume lógico que é a combinação dos dois HDs.

Pro Windows, mais espeficificamente pro sistema de arquivos NTFS, vai ser um único volume de 2 terabytes. O volume é uma forma de organizar partições no mesmo HD ou até em HDs diferentes como um único armazém de dados. Lógico, você já entendeu que nunca deve fazer isso porque se der pau num dos HDs você perde o volume inteiro.

O segundo jeito que eu ainda não falei é RAID-1, que é como alguns sistemas caseiros de backup com 2 HDs podem vir configurados. Mesmo exemplo, imagina os dois HDs de 1 tera cada. Podemos configurar um pra ser backup quente do outro. Ambos ficam ativos mas pra você só aparece um volume C: de 1 terabyte.

Por baixo seja um hardware de RAID na sua placa mãe ou um módulo de software RAID que seu sistema operacional carrega no boot vai identificar os dois HDs mas organizar como um único volume. Diferente do RAID-0 que você ia enxergar como um único volume com a soma do espaço dos dois HDs, no RAID-1 você enxerga só como se um dos HDs estivesse ligado e o outro não. Metade do espaço total.

Parece desperdício, mas essa é a redundância mais simples. Toda vez que você escreve um arquivo, por baixo vai escrever igual nos dois. Um vai ser uma cópia exata do outro e por isso RAID-1 é chamado de mirroring, ou espelhamento. Digamos que daqui alguns meses um dos HDs resolve dar pau. O sistema de RAID vai identificar o problema e você não vai perder nada porque o outro HD ainda tá intacto e com 100% dos seus dados. Basta trocar o HD defeituoso e o sistema de RAID vai reconstruir esse novo HD fazendo uma cópia do outro.

A gente pode combinar o espelhamento do RAID 1 com o stripping do RAID 0. Se eu tiver agora quatro HDs de 1 tera cada, ou seja, total de 4 tera, eu posso organizar como dois conjuntos de stripe: dois HDs de 1 tera viram um volume de 2 teras. E agora eu pego esses dois volumes maiores e mando um espelhar no outro. Eu continuo perdendo metade do espaço pra backup, mas também tenho a vantagem de mais performance de ter HDs em stripe. É tipo juntar o melhor dos dois esquemas: redundância e performance.

Você vai ver esse arranjo sendo chamado de RAID 10, mas não é número 10 e sim 1 mais 0 porque é Raid 1 combinado com Raid 0. Em qualquer dos casos estou perdendo bastante espaço pra backup. E existe um jeito mais inteligente, e aí voltamos pro RAID-5 do meu Drobo e do Synology e da maioria dos bons servidores de armazenamento. Aliás, no mundo de storages ou armazenamento, existem 3 siglas que você precisa saber: DAS, NAS e SAN.

Direct Attached Storage é o mais simples. Um pendrive ou HD externo é um DAS, que é storage anexado direto no seu computador, seja via USB ou Thunderbolt hoje em dia. Aliás, USB é outro ninho de siglas que confundem. Fazendo uma pequena tangente, tudo que é USB antigo de uns 10 anos pra trás é USB 2.0 que tem velocidade máxima de uns 480 megabits por segundo ou 60 megabytes por segundo.

Quando você só tem HDs mecânicos, um USB 2.0 tá mais que bom. Mas desde 2008 existe USB 3.0 que opera na faixa de 400 megaBytes por segundo, bem mais que o melhor HD mecânico. E isso é necessário porque nesse ponto a gente já tava começando a adotar mais SSDs.

Acho que todo mundo pelo menos tem idéia do que é um Solid State Drive. SSD é uma placa com chips de NAND Flash. Modelos mais sofisticados tem chips de RAM também pra operar com cache e melhorar os piores casos. Como eles foram feitos pra conectar na interface Serial ATA ou SATA 3, que tem velocidade teórica máxima de 750 megabytes por segundo, não espere um SSD comum ser muito melhor que isso.

Na prática um bom SSD vai operar na faixa de 500 megabytes por segundo, que já é pelo menos 10 vezes melhor que a velocidade média de um HD mecânico. Se for lidar com milhares de arquivos pequenos então, o HD mecânico pode cair pra velocidades ridículas de 3 ou 2 megabytes por segundo. Num SSD o tempo de procura é muito mais rápido porque é que nem um chip de memória, não tem que lidar com um motor e ficar reposicionando cabeças em cima de discos.

Se a gente judiar do SSD a velocidade dele pode cair pela metade, mas mesmo assim ainda estamos falando da faixa de 200 megabytes por segundo. Notebooks não tão velhos já devem pelo menos ter um SSD numa caixinha de 2.5 polegadas igual um HD mecânico de notebook mais antigo. Tanto que é fácil trocar um pelo outro e você vai ganhar 10 vezes mais performance. Nenhum upgrade num notebook velho vale mais a pena do que colocar um SSD.

De qualquer forma, um USB 2.0 agora é porcaria, daí pulamos pra série 3. Toda vez que você vê um conector USB que é azul é porque é da série 3. E eu falo série porque desde 2008 ele virou 3.1 e 3.2. Na prática quando se fala USB 3, quer dizer pelo menos 3.2 Gen 1. E são quatro tipos, a Gen 1 que é de 5 gigabits por segundo, gen 2 é 10 gigabits, gen 1 x 2 é 10 gigabits, gen 2 x 2 é 20 gigabits. A nomenclatura de USB é uma droga assim mesmo.

5 gigabits que é o USB 3.2 gen 1, é 5 dividido por 8 que dá na faixa máxima de 600 megabytes por segundo. Que é próximo da velocidade máxima de um SSD SATA-3 de qualidade. E 20 gigabits do USB 3.2 gen 2 por 2 é 2.5 gigabytes por segundo. E pra que tudo isso? Porque o mundo de HDs não é só mecânico e SSD. Hoje em dia o melhor são os NVME.

NVME é Non-volatile Memory Express. Assim como SSDs eles continuam usando chips NAND flash, mas em vez de ser limitado pelo barramento SATA-3, o NVME usa lanes de PCI Express. Pensa assim, a série ATA e SATA de interfaces foi pensada pra HDs mecânicos. Então os SSDs mais comuns que usam SATA-3 tem uma série de obstáculos de tecnologia legada. PCI Express é o mesmo barramento onde você liga coisas como sua placa gráfica. Trocando SATA-3 por PCIe, a gente ganha menos overhead e menos obstáculos.

Se um bom HD mecânico faz na faixa de 50 megabytes por segundo, se um bom SSD SATA-3 faz na faixa de 500 a 600 megabytes por segundo. Um bom NVME que usa PCIe e se conecta em slots que chamamos de M.2, faz na faixa de 2 a 3 gigabytes por segundo que, por acaso, é a faixa de velocidade do USB 3.2 Gen 2 por 2 que eu falei antes.

O que todo mundo fica confuso é não saber que USB 3 é um protocolo e que tem várias gerações que variam bastante de velocidade. Aí tem a gente confunde o protocolo USB 3 com o conector USB Type C. Isso é outro problemão porque agora estamos falando de conector e cabos.

O conector mais comum sempre foi o USB type A que é aquele retângulo maior. Tem o Type-B que é menor e mais quadrado que liga em impressora e que existe pra você não inverter os lados do cabo. Cabo USB transmite energia só pra um lado. Normalmente do Type-A sai energia e no Type-B recebe. Se fosse tudo Type A você podia acabar invertendo o cabo e queimar alguma coisa.

Enfim, Type C é novo conector que saiu uns 3 ou 4 anos atrás pra justamente arrumar um pouco essa zona. Todo mundo só pensa que com o Type-C não tem jeito certo pra encaixar. Mas não só isso, você pode ter cabo com as duas pontas sendo Type-C, porque ele é multi-direcional pra energia e o protocolo vai garantir que você não vai queimar nada se inverter o cabo.

O cabo Type-C, junto com o protocolo 3.2 Gen 2 x 2 tem capacidade máxima de 20 Gigabits por segundo, que são os mais de 2 gigabytes por segundo de velocidade. Mas tem acima disso. Computadores Intel e Mac, ou seja, menos a AMD, tem Thunderbolt 3, com velocidade máxima de 40 gigabits por segundo ou 5 gigaBytes por segundo. E aí você pode pensar, mas ué, o NVME mais rápido é na faixa de 2 a 3 gigabytes, pra que precisa do dobro?

Porque Thunderbolt não é feito só pra dispositivos de armazenamento, mas pra tudo, incluindo monitores. Um cabo HDMI 2.0 que é o mais comum e que você deve ter na sua TV, sozinho, tem banda de 18 gigabits, perto do máximo de uma USB Type C. Você consegue transmitir no máximo 4K a 60 quadros por segundo.

Sem entrar muito no assunto de video, mas só pra complementar, pra jogar Playstation 5 ou Xbox Series X em 4K a 120 hertz em HDR, precisa de cabo HDMI 2.1 que tem banda de 48 gigabits por segundo. Então, num USB 3.2 Gen 2 x 2 não dá pra ligar mais de um monitor 4K e ainda ter boa velocidade pra copiar arquivos pra um SSD externo. Thunderbolt serve pra isso.

E isso porque estamos pra receber já já USB 4 e Thunderbolt 4. Só mencionei porque tanto USB 3.2 quanto Thunderbolt usam cabos com o mesmo conector Type-C. Por isso é uma zona. Quando a entrada Type-C suporta Thunderbolt, costuma ter um ícone de raio do lado. Mundo Mac tá mais acostumado com tudo Thunderbolt, no mundo PC a gente tá um pouco mais atrasado na adoção.

Voltando a falar de SSDs e NVMEs, laptops e placas mãe modernas já vem com pelo menos um slot M.2 que dá pra colocar um NVME. E se não tiver, no mínimo você deveria jogar fora o HD mecânico e colocar um SSD SATA-3. Qualquer coisa vai ser no mínimo 10 vezes melhor que um HD mecânico. No caso de NVME vai ser quase 100 vezes melhor.

Agora, SSDs e NVMEs não são todos iguais. NAND Flash tem em diversas variedades. Você tem chips que suportam 1 bit de dados que é single-level cell ou SLC. Você pode ter um chip que suporta 2 bits, que é multi-level cell ou MLC. Entendeu? O próximo tipo suporta 3 bits e se chama triple-level cell ou TLC e o último suporta 4 bits ou quad-level cell ou QLC. Então SLC, MLC, TLC e QLC. Quanto mais bits melhor? Na realidade não, o melhor é o single level cell, SLC.

Quanto mais bits você entuchar numa célula, menos espaço ocupa. Então tem drives com maior capacidade no mesmo espaço. Porém, quanto mais bits ele tem, mais lento ele fica e, pior, menos tempo ele dura. Chips NAND tem capacidade máxima de escrita. Todo SSD tem uma quantidade máxima de vezes que dá pra usar antes das células pifarem.

Chips SLC, de 1 bit por célula, vão durar na faixa de 50 a 100 mil ciclos de program e erase ou PE que é a unidade que se usa. Um chip QLC vai suportar 100 vezes menos, talvez uns 1000 ciclos de PE. Então, no mesmo preço, ou você escolhe um SSD de menor capacidade mas que vai durar muito tempo ou um de maior capacidade que vai durar menos tempo. Mais um trade-off.

Nenhum SSD vai durar pra sempre. Apesar de não ter peças móveis ele também deteriora com o uso. A vantagem é que não vai estragar antes do tempo porque você derrubou e estragou o motor ou riscou o disco. E justamente porque a gente sabe que tanto HDs, quanto SSDs ou NVMEs uma hora vão todos morrer, que você precisa de tempos em tempos garantir que tem backup.

A tangente toda começou porque eu comecei falando de DAS. Um HD externo mecânico ligado via USB 2 é um DAS porque tá anexado direto no seu PC. Se usar um SSD externo, provavelmente vai ser via USB 3. Se usar um NVME externo vai ter conexão Thunderbolt. E mesmo soluções de RAID com múltiplos drives também pode ser de SSDs, e se for você pode conectar via Thunderbolt também.

Mas não é sempre prático ter uma caixona grande com múltiplos drives na sua mesa. Às vezes você pode preferir colocar esse servidor em algum lugar mais escondido. Dentro do seu closet, no porão ou algo assim. E aí tem uma desvantagem de cabos como USB ou Thunderbolt. Eles não foram feitos pra serem longos assim.

Mas existem cabos que foram feitos pra ser bem longos, são cabos Ethernet de rede. E indo direto ao assunto, adivinhem, só porque um cabo é azul ou amarelo, e tem o mesmo conector RJ-45 de rede, não quer dizer que são iguais. Mesma coisa que eu falei dos diferentes tipos de USB 3.2. Cabos ethernet são divididos em categorias. Hoje não é episódio sobre redes, mas deixa eu só explicar os cabos.

Existem categorias como cat5E, cat6, cat6A, cat7, cat8. De cat5 a cat6 é velocidade máxima de 1000 megabits por segundo, que é uns 125 megabytes. Isso é o dobro de USB 2.0 mas é 5 vezes mais lento que USB 3.2 Gen 1.

Cat6A e Cat7 é categoria dos 10 gigabits por segundo. Agora igualamos com USB 3 Gen 1. Se o comprimento for menos de 50 metros, ainda pode subir pra 100 gigabits e aí já ficou melhor que Thunderbolt. Um cabo cat8 já entra em território de velocidade de fibra ótica. Além de velocidade varia a construção do cabo, resistência, blindagem. Acho que Cat 6 ou 7 são mais comuns, eu nunca vi um Cat8, vai ser mais em data center.

Quem lembra de física elétrica básica do colégio lembra que num fio que passa eletricidade gera um campo magnético ao seu redor, por todo o comprimento. Se colocar vários fios em paralelo um do lado do outro, eles vão dar interferência entre eles. Um cabo Ethernet é um conjunto de vários cabos mais finos dentro, organizados em twisted pair, ou par trançado. Se você já clipou um cabo de rede já deve ter visto isso.

Normalmente esses cabos conseguem atingir distâncias de até 100 metros e se precisar mais longo existem extensores pra isso. Mas o ponto é que você pode tranquilamente puxar cabos de dezenas de metro pela sua casa sem problemas. É o que eu faço: em vez de usar um DAS conectado direto no meu PC eu tenho um NAS, um network attached storage do lado do meu roteador e do meu PC sai um cabo ethernet cat7 que vai até o roteador.

Meu Synology DS420j é um NAS de entrada. Tá configurado com 4 HDs mecânicos de 4 terabytes cada, reservando uns 5 giga espalhado pelos drives. É uma porção de cada drive reservado pra redundância. Um NAS é só um nome mais bonitinho pra um PC pequeno com Linux. Ele tem uma CPU Celeron antiga, uns 1 giga de RAM e só.

Um NAS mais sofisticado vai ter um processador melhor, muito mais RAM e até opção de colocar um SSD, normalmente formato mSATA ou talvez até M.2. Você mesmo pode montar um NAS caseiro num PC velho que tiver sobrando com placa de rede ou até Wifi. Como a gente acaba usando HDs mecânicos, velocidade de Wifi acaba sendo suficiente.

Eu ainda não coloquei um NAS melhor porque não preciso editar arquivos grandes direto dele, só uso como backup mesmo. Mas existem casos que você precisa trabalhar direto do NAS. Exemplo disso são estúdios que editam videos profissionais. Aí você tem vários editores trabalhando de computadores bons mas todos precisam acessar os mesmos arquivos ou os arquivos são tão grandes que não é prático ter na máquina de cada um.

Se você não tem noção, video ocupa muito espaço. Mesmo na minha produção caseira, um video de 30 minutos em 4K ocupa nada menos que 3 gigabytes e meio. Um dos meus últimos videos longos, antes de editar, foram 4 arquivos que dá quase 2h de gravação e ocupa quase 40 gigabytes no total. Pra um video de YouTube! Tudo bem que é um video que editado deu uns 45 minutos, mas mesmo assim. 10 episódios nesse formato já seria quase meio terabyte. Menos de 20 videos e acabou um terabyte. Lembrem que meu canal já tem 100 videos.

Numa produção profissional bem mais cara, usando uma câmera RED Monstro, gravando no formato Redcode com compressão de 8 pra 1 e video de 8K custaria nada menos que 1 terabyte pra cada 30 minutos. Ouviram? Se eu tivesse gravado as mesmas duas horas que eu falei nesse formato ia me custar mais de 3 terabytes. Num único video! Imagina 100!

Ah, mas depois de editar o video final é só jogar fora os originais. Não, isso é pensamento de amador. A gente NUNCA joga fora originais de nada. Você nunca sabe quando precisa voltar nos originais pra re-editar, ajustar, talvez fazer um remaster amanhã. Profissionais guardam tudo em servidores.

Por isso você vai num canal como Linus Tech Tips e ele fala tanto em servidores de armazenamento como esse aqui dele montando 1 petabyte num servidor com 60 HDs, 256 Giga de RAM controlado por uma CPU AMD Epic Threadripper acho que de 24 cores. E eles tem mais de um desses servidores.

Nossos computadores domésticos e laptops costumam vir no máximo com um plug Ethernet de 1 gigabit, que é suficiente pra no máximo 128 megabytes por segundo de transferência. Pra navegar na Web e copiar arquivos pequenos pela rede tá mais que bom. Quase nenhum plano de Internet doméstico que você achar vai saturar isso, nem perto, especialmente se for uma porcaria como NET da vida. Meu NAS Synology e o Drobo não fazem muito mais que 25 megabytes por segundo. Mas pra conseguir editar video de 8K em tempo real, direto num drive montado na rede, precisa ser Ethernet 10 gigabit, pra ter velocidades de mais de 1 gigabyte por segundo.

Um servidor desses, aliás, provavelmente vai ter múltiplas saídas de ethernet 10 gigabit pra conseguir lidar com múltiplos computadores editando video ao mesmo tempo. Aí a brincadeira começa a fica interessante. Recomendo procurar por videos dos bastidores do Linus Tech Tips que ele detalha bastante disso. O ponto importante é que a gente imagina computador como sendo só o HD interno e no máximo um HD externo via USB. Mas tem muito mais opção que isso.

Falando em opção a última coisa que eu queria comentar é sobre storage em cloud. Seja seu Dropbox ou AWS da vida. Num container virtual você não tem nenhum controle sobre os HDs por baixo. Quando você cria uma instância tipo um AWS EC2 da vida e monta um volume de EBS, provavelmente por baixo é um SAN ou Storage Area Network, que é o terceiro tipo que faltava falar mesmo.

NAS você já entendeu, é um servidor com HDs, em alguma configuração de RAID. O servidor de 60 HDs do Linus por exemplo, provavelmente tá configurado com filesystem ZFS e uns 8 HDs são reservados pra paridade. Parece bastante mas 8 de 60 é uma perda de pouco mais de 10% comparado aos 20% que eu perco no meu RAID-5, é bem justo. Significa que ele pode ter até 8 HDs crasheando ao mesmo tempo sem perder nenhum bit de dados. Nos próximos episódios vou falar de ZFS mas só entenda pra hoje que é o melhor filesystem pra configurações assim de múltiplos HDs.

Um SAN é uma infraestrutura mais complexa. Num NAS a gente cria um volume virtual em cima dos 4 HDs ativos e enxergamos tudo como se fosse um único drivezão em vez de enxergar. Um SAN é um volume virtual bem maior, que pode agrupar o equivalente a vários NAS por baixo. A grosso modo pense num SAN como um conjunto de NAS, um rackzão de data center com vários servidores ainda maiores que o do Linus. É em cima de hardware assim que funciona um Dropbox ou Google Drive.

E se você não conhecia, EBS é o serviço da Amazon Web Services pra criar volumes virtuais, que você pode montar na sua máquina virtual Linux como se fosse um drive. Máquinas da Amazon EC2 são voláteis. Quando desliga a máquina, tudo que tinha dentro se perde. Pra persistir dados, você monta um volume do EBS e vai gravando lá. Quando desligar a instância, os dados no volume do EBS continuam lá até você remontar em outra instância.

Outra hora eu explico mais sobre porque a AWS funciona dessa forma. Mas a curiosidade é o nome. EBS é Elastic Block Storage. Existem dois tipos de dispostivos, character devices e block devices. Character devices quando você conecta ele vai imediatamente transmitindo byte a byte individualmente pro seu software. Block devices recebem ou enviam bytes literalmente em blocos. Por exemplo, setor a setor de uma partição ou melhor, clusters de vários setores ao mesmo tempo.

Um character device ou também chamado de raw device, “raw” de crú, onde a gente recebe e envia byte a byte imediamente. Um block device tem uma espera, porque a kernel do sistema operacional vai manter um cache em memória. Blocos é mais eficiente quando o dispositivo é lento. Lembra do trabalho que é o motor mover as cabeças por um disco que fica em rotação? Por outro lado, coisas como teclado, mouse, você não quer que demore, pelo contrário, você quer a menor latência possível. Por isso tem dois tipos.

Em Linux pelo menos, a distinção deve ter motivos históricos, quando o normal era ter que lidar com HDs bem lentos, ou mesmo os antigos disquetes e CDs. Ao contrário de Linux a família de UNIX BSD não trata HDs como block devices e sim como raw devices, hoje em dia. Isso porque o fato do cache existir pra tentar melhorar a performance do HD trás uma desvantagem que usuários domésticos como a gente não vai notar. Mas num servidor com muito uso pode ser fatal.

Tudo que tá num cache é volátil. Memória RAM depende de energia e se a energia caiu, perdeu o que tinha lá. Você quer RAM porque acelera a transmissão, mas quanto mais demorar lá, maiores as chances de perder. O BSD quer partir da premissa que ele não vai interferir, e seu aplicativo pode implementar cache por cima e gerenciar o risco que está disposto a assumir em vez de tentar melhorar performance ao custo de um risco escondido.

Essa situação é raro de acontecer, mas não impossível. Quantas vezes no ano caiu energia bem quando você acabou de mandar salvar alguma coisa? É raro, mas comigo mesmo ao longo dos anos aconteceu algumas vezes. Mas o ganho de performance graças aos caches automáticos do sistema operacional tem mais validade pra mim do que talvez perder um arquivo uma vez por década.

Num servidor a história é outra. Lembra o servidor do Linus com 60 HDs? Pensa servidores muito maiores, centenas de servidores, com milhares de HDs. Num data center vai ser bem mais comum ter problemas, provavelmente até múltiplas vezes por dia. Num conjunto de dezenas de milhares de HDs, certamente alguns HDs vão dar pau. Algum servidor pode dar pane de algum tipo. E se seus dados estiverem num cache na memória, você pode perder arquivos importantes de algum cliente.

Talvez por isso os BSDs, cujo maior uso é em aplicações de servidor e muito menos como desktop, não suportam mais block devices, todos são character devices ou raw devices. Não quer dizer que block devices são ruins. Num laptop, que tem bateria, você corre muito menos risco de perder alguma coisa por conta de uma falta de energia aleatória. Por outro lado, a performance extra por ter o cache vai faciltar seu dia a dia.

Mas servidores é diferente, eles ficam ligados 24 horas por dia, 7 dias por semana, com milhares de pessoas realmente lendo e gravando dados sem parar. E você não pode perder um byte, ou já já vai ter usuários muito bravos com você.

Tem muito mais que isso pra se falar sobre dispositivos de armazenamento, mas eu acho que com o que falei hoje já deve cobrir a maioria dos casos de uso que um programador médio vai precisar. Você precisa entender o que está usando e não confiar numa abstração.

Eu lembro que antigamente a gente sabia que o programa tava funcionando e lendo ou gravando porque a gente colocava a orelha no gabinete e ouvia o som do motor e das cabeças trabalhando. Pra diferenciar se um programa tava travado ou só demorando pra acabar, era só ouvir o HD. Se estivesse em silêncio e o programa ainda pausado, é porque travou. Se desse pra ouvir o HD trabalhando, então tinha que esperar mais um pouco.

Hoje em dia, especialmente se você tá conectado numa máquina virtual em cloud, não tem mais esse contato com a máquina. Então é mais importante ainda saber como essas coisas estão estruturadas, pra saber em que parte pode estar com problema: na sua aplicação, no sistema operacional, num dos caches, na camada de rede se for um NAS, e assim diagnosticar o lugar certo.

A pior coisa que um programador pode fazer é acreditar em superstições porque não entende como as coisas funcionam. Daí quando realmente precisa resolver um problema difícil vai ficar achando receitas homeopáticas e ficar tacando tudo na parede pra ver se algum gruda. Não precisa ser programador pra fazer as coisas às cegas assim.

Espero que tenha dado pra aumentar o interesse de vocês em estudar mais sobre o hardware. No próximo episódio vou falar sobre o que vai dentro dos volumes: o sistema de arquivos. Cada sistema operacional usa um diferente e eles tem vantagens e desvantagens. Se ficaram com dúvida mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal, clique no sininho e compartilhem o video com seus amigos. A gente se vê, até mais.

Nessa nova mini-série quero explicar os diversos conceitos sobre armazenamento e neste primeiro episódio vou explorar um pouco sobre RAID e mostrar como antigamente a gente mapeava dados em disco usando o sistema de cilindros-cabeças-setores e como as coisas evoluiram hoje.

Conteúdo:

• 00:00 - Intro
• 02:17 - Drobo - o que é RAID?
• 04:11 - RAID-5
• 05:56 - Synology
• 06:52 - Resolvendo um problema catastrófico de HDs
• 09:23 - Você ainda não entende HDs/RAID-0
• 11:21 - o começo: instaladores de Linux
• 13:54 - CHS
• 17:28 - Blocos
• 21:18 - Velocidades
• 24:09 - fdisk
• 25:35 - LBA
• 26:54 - TBC

SCRIPT

Olá pessoal, Fabio Akita

Se você assistiu o episódio sobre meus Backups que fiz lá no começo do canal sabe que costumo ser um pouco obsessivo sobre armazenamento. Eu cheguei a perder algumas coisas que tinha em disquetes e cartuchos de zip drive, então meus primeiros projetinhos, coisas da faculdade, eu perdi. Desde então tento manter múltiplas cópias das coisas mais importantes.

Eu tenho backupsdo meu Outlook do ano 2000 por exemplo, todos os meus emails de mais de 20 anos atrás. Mesmo os atuais que ficam no Gmail eu baixo offline com o Thunderbird pra ter uma cópia local. Nunca confie em serviços cloud, especialmente se forem gratuitos. Você sempre vai receber exatamente o que paga. Um belo dia sua conta tá suspensa, por erro ou porque você foi imprudente e não habilitou autenticação de 2 passos nem manteve senhas fortes. Vai acontecer, é só questão de quando.

Mesmo usando coisas como Dropbox, Google Drive e Microsoft OneDrive - sim, eu uso os três - tenho uma cópia nos HDs do meu PC, outra cópia no meu laptop, e outra nos meus NAS. A grande vantagem que eu vejo hoje em dia comparado com os anos 90 ou anos 2000 é que armazenamento barateou muito.

No primeiro dia de 1995, ano que entrei na faculdade, o custo médio por 1 gigabyte era nada menos que 850 dólares, em dólares dos anos 90! Só 1 giga! 5 anos depois, no último dia de 1999 o mesmo 1 gigabyte agora custava em média 15 dólares. E em 2009 custava só 7 centavos. Hoje em dia 1 terabyte é menos de 100 dólares.

Hoje eu quero discutir um pouco sobre armazenamento. Na nossa saga pela máquina de Turing e a linguição de bytes, eu expliquei como bytes mais ou menos são organizados na memória, estruturas de árvores, stack, heap e tudo mais. Mas memória RAM é volátil. Toda vez que você desliga o computador essa memória foi pro saco.

Pra ter algo persistente agora precisamos entender como armazenar nossa fita de bytes numa mídia sólida, como os atuais drives de SSD NVME. Muita gente pensa que a única coisa importante sobre drives é que a gente particiona e tem uma estrutura de diretórios e arquivos, e só lê arquivos e grava arquivos e acabou a história. Só que é muito mais que isso. Então vamos entender.

(…)

Por muitos anos, desde 2008, eu mantinha meu backup num dispositivo chamado Drobo. Quando saiu parecia excepcional, hoje em dia é bem ultrapassado, mas eu ainda tenho um Drobo 5N que é um NAS. NAS é sigla pra Network Attached Storage ou armazenamento anexado na rede que é um nome mais bonito pra um PC na rede com vários HDs.

Esse Drobo 5N tem 5 baias pra HDs. E eu tenho 5 HDs mecânicos de 4 terabytes cada. Isso dá um total de 4 vezes 5 que é 20 terabytes, mas eu só posso usar pouco menos de 15. Se você nunca ouviu falar em redundância pode achar isso estranho, pra onde foi os outros 5 teras??

O Drobo e outros NAS costumam usar alguma variação do conceito de RAID que é sigla pra Redundant Array of Inexpensive Disks ou um arranjo redundante de discos baratos. O problema é o seguinte, HDs tradicionais mecânicos tem o problema de serem mecânicos, terem partes móveis. O HD tem discos um em cima do outro formando um cilindro e cada um tem cabeças de leitura, um pra cada lado do disco, ligadas num motor pra movimentar essas cabeças a milímetro de distância dos discos.

Eu lembro que nos anos 90 a gente tinha que dar um comando no MS-DOS chamado park que é estacionar. Era um comando pra forçar o estacionamento das cabeças. Pense em cabeças como a agulha que desliza sobre um disco de vinil de música. Apesar das cabeças num HD não tocarem fisicamente os discos e sim usar magnetismo pra ler os bits, se você esbarrasse no computador podia arriscar dessa cabeça tocar no disco, e aí podia estragar. Por isso era boa prática mandar estacionar antes de desligar o computador. Hoje em dia eles são mais inteligente e já fazem isso sozinhos.

O ponto é que existem muitas peças móveis, e tudo que tem peças móveis eventualmente vai falhar. Seja por problema de fabricação, seja só por tempo de uso. Tudo deteriora. E quando isso acontecer você pode perder acesso aos seus dados.

Existem variações na implementação de estratégias de RAID, mas no modelo clássico RAID-5 tem esse número porque se espera ter pelo menos 5 HDs. 4 vão estar ligados e um 5o fica offline de reserva, desligado mesmo e por isso chamamos de Cold Spare. Apesar de ser 4 HDs ligados ao mesmo tempo, você enxerga como se fosse um único drive. Um único volume pra ser mais exato.

Os dados, mais corretamente os blocos, são divididos entre os 4 drives e cada HD mantém uma parte da cópia do outro drive. Sabemos que HDs mecânicos eventualmente vão morrer. Mas vamos apostar que em 4 drives a chance de todos morrerem ao mesmo tempo é baixa. Normalmente só um vai morrer primeiro. Se isso acontecer os outros 3 drives vão ter cópias dos demais e seu volume vai sobreviver intacto, sem perder nenhum dado.

Isso te dá tempo pra pegar aquele 5o HD de reserva, o cold spare pra substituir pelo que falhou. Daí o controlador do RAID vai reconstruir o novo HD com os dados redundantes dos outros três. Por isso que apesar de eu ter um total de 20 tera nos meus 4 drives, ele só me deixa usar 15. Porque os outros 5 tera são gastos com redundância. São os dados de paridade. E eu já tive esse problema de HDs morrerem várias vezes e toda vez fui salvo por esse sistema.

Em data centers isso é crucial. Imagina que um data center como os do Google ou Amazon da vida tem milhares de HDs. Todos eles vão falhar uma hora. Não de uma vez, mas aos poucos. Com essa quantidade massiva, falha alguns por dia, especialmente porque ficam ligados e funcionando dia e noite sem nunca desligar. HDs usados em data centers são diferentes do que a gente usa nos nossos PCs caseiros. HDs como os Seagate Iron Wolf Pro, feitos pra serem mais robustos e resistentes. HD doméstico quebra mais fácil, por isso é mais barato.

No meu caso, eu precisava de mais de 15 teras. Eu tenho duas opções: uma seria trocar os HDs de 4 teras por outros maiores de 6 ou 8 teras. Em vez disso eu queria testar os produtos de NAS da Synology e por isso comprei um modelo de entrada que é o DS420j, e já digo que achei razoável.

Sem me alongar muito, nada de errado com esse modelo, ele faz exatamente o que diz que faria e acho que se for só pra backup tá bem mais que suficiente. Mas não dá pra usar ele no dia a dia com arquivos grande, porque ele é limitado pela velocidade dos HDs mecânicos e não tem opção pra aumentar a RAM e nem colocar um SSD NVME como cache. Uma versão como o DS920+ já tem opção pra esses upgrades e isso aumentaria bastante a velocidade: mais cache. E mesmo assim, se eu quisesse editar video direto dele precisaria ser um outro modelo que também tenha saída de rede 10Gigabit em vez do tradicional 1 gigabit. Lembrem-se disso quando estiverem escolhendo um.

Esses dias eu tive um problema. Uns dois anos atrás eu pedi pro meu sócio trazer HDs pra mim quando ele foi pros Estados Unidos. O problema de HDs, como eu falei, é que são frágeis. Se você jogar os HDs na na mala e não proteger muito bem, com todo o balanço da viagem, mala sendo jogada dentro do avião, é quase certeza que vai estragar.

Dito e feito, eles nunca se comportaram como deveriam. Eu usei eles no Drobo, mas aí o Drobo reclamou que os HDs tavam falhando. Resolvi comprar mais 4 HDs novos no Mercado Livre e fui trocando. Daí esses HDs massacrados ficaram sobrando. Quando comprei o Synology eu pensei: ok, eu sei que eles não tão 100% mas vamos tentar de novo. Se falhar não vai ser todos de uma vez.

Funcionou por alguns meses, esses dias o Synology desligou tudo sozinho. Tentei religar e entrar no painel de administração e batata, 3 dos HDs tavam marcados com defeito. Três de uma vez só é foda. Mas na prática os próprios HDs é que sinalizam pro servidor que tão começando a falhar e que é arriscado continuar, não quer dizer que quebraram totalmente. Ainda bem que hoje em dia os HDs são mais inteligentes, eles tem a funcionalidade de SMART que é sigla pra Self-Monitoring, Analysis and Reporting Technology ou seja, Auto-monitoramento, análise e tecnologia de relatório. O HD sabe que vai morrer a qualquer momento.

Enfim, lá vou eu encomendar mais HDs no Mercado Livre. Eles acabaram de chegar, dessa vez comprei Western Digital RED que são os equivalentes em robustez aos Seagate Iron Wolf. Qualquer uma das duas linhas eu recomendo. O problema é que 3 HDs de uma vez começaram a notificar problema. Num dia normal onde no máximo só um falha, bastaria trocar só ele e os outros três iriam ser usados pra reconstruir o quarto.

Como os três falharam, o próprio Synology se auto-desligava inteiro por garantia. Então seria arriscado tentar o processo de reconstrução dele mesmo. Eu queria uma forma mais direta de fazer um clone de um HD direto pro outro. Por isso procurei um sistema de clonagem e achei um genérico que parece que funciona, da marca Mymax e você acha no Mercado Livre.

É um dispositivo que não precisa estar ligado no computador pra funcionar. Você coloca o HD original no slot A, o novo HD no slot B, só garante que o novo HD é do mesmo tamanho ou maior que o original, aperta um botão e ele sozinho vai fazer um clone, bloco a bloco. E isso é importante. Esse dispositivo não tem a mínima idéia de que sistema de arquivos o HD tem, se é NTFS de Windows ou ext4 de Linux. Ele não precisa carregar um filesystem e copiar arquivo a arquivo, isso seria o arriscado. Em vez disso ele vai fazer um clone de verdade, copiando bloco a bloco de um HD pra outro. Isso é modo raw ou crú.

Daí veio a idéia desse episódio. Muita gente, incluindo programadores não tem a mínima idéia de como HDs funcionam. No máximo sabem que um SSD é mais rápido que um HD e só. Quando eu falei clonar um HD, muita gente deve imaginar tipo selecionar vários arquivos e copiar pro outro como faria num Windows Explorer.

Tem gente que tem até computadores ou HDs externos com mais de um drive configurado em RAID-0, formando um único volume, ou seja, estão em stripe. Mau eles sabem que se um dos HDs falhar você acabou de perder todos os dados dos dois ao mesmo tempo.

Se você não sabe o que é Stripe, é uma versão de RAID que faz um único volume em cima de dois ou mais HDs. Daí no seu Windows você enxerga só um drive C:, por exemplo. A vantagem é que a velocidade vai ser maior, porque você distribui o trabalho entre os dois HDs, em paralelo. No melhor caso você vai ter o dobro de performance. Alguns blocos vão pra um HD e outros blocos vão pro outro HD.

Mas você pode pensar, ué, se metade dos arquivos foi pra um HD e outra metade foi pro outro, se um dos HD falhar eu vou perder só metade dos meus arquivos, mas a outra metade tá salva, não tá? Não! Eu disse que vai distribuir blocos e não arquivos.

O você talvez não saiba é que arquivos são divididos em blocos, normalmente de tamanho fixo, digamos de 512 bytes. Então um arquivo de 1 megabyte pode ocupar pelo menos 2 blocos. Um arquivo de 10 mega vai ocupar 20 blocos e assim por diante.

Agora, o sistema RAID-0 de stripe vai DIVIDIR esses blocos entre os dois HDs. Por isso é mais rápido ler depois, porque ele pode ler partes do mesmo arquivo vindo de HDs diferentes. E por isso que se você perder um dos HDs, vai perder o arquivo todo, porque tá picotado. Se você perder só 1 bloco, seu arquivo inteiro foi corrompido. Você trocou confiabilidade por performance. E isso é válido, por exemplo, se você tá configurando um servidor de cache, onde se os dados forem corrompidos, consegue reconstruir porque tem os originais em outro lugar.

As aplicações tentam facilitar as escolhas pra você, por isso às vezes você não sabe o que está acontecendo. Por exemplo, toda vez que reinstala um Windows, ou qualquer distro Linux moderna, só precisa ir dando next, next, next e o instalador é inteligente o suficiente pra fazer as escolhas mais sensíveis e você nem precisa entender o que ele fez. Uma dessas escolhas é como particionar seu HD, como gravar uma partição de boot, qual sistema de arquivos escolher e formatar. Em poucos minutos você parte de um HD virgem pro sistema operacional instalado e funcionando.

Nem sempre foi assim. Talvez tirando os Macs, que mesmo nos anos 90 tinha 100% de controle do hardware e do software, então ele sabia exatamente que HDs estavam instalados e como formatar da melhor forma. A vantagem da idéia de comoditizar PCs da IBM é que você podia comprar os componentes separadamente, um chip compatível com x86 só que da Cirrus, uma placa mãe talvez da Soyo, uma placa de som da Sound Blaster, um modem da US Robotics, e um HD ou Winchester como a gente chamava naquela época da Seagate.

Agora você quer instalar MS-DOS ou um UNIX ou uma das primeiras versões de Linux no começo dos anos 90. Boa sorte. Falando especificamente de Linux, primeiro você ia encomendar uma distro comercial como um RedHat. A versão 4.2 foi minha segunda distro. Daí coloca o disquete de boot pra inicializar o sistema, detectar o hardware que a BIOS já achou, carregar os drivers mais básicos pra cada componente. No final ele monta um ramdisk, que é o equivalente a um volume de HD só que na memória.

Agora você troca o disquete e coloca o de root ou suplemento como a RedHat costumava chamar. Ele vai montar esse disquete como o diretório /usr no ramdisk. Agora ele tem as ferramentas pra continuar. O próximo passo é detectar seu HD, se é IDE ou SCSI, carregar o driver e te dar a opção de particionar os volumes usando o temido fdisk.

Se você já teve o azar de cair num sistema que só te dá fdisk, e você nunca usou na vida, vai ser difícil. Só no fim dos anos 90 a RedHat adicionou a ferramenta Disk Druid que já ajuda muito, e hoje em dia você tem um GParted ou equivalente que vai particionar seu HD automaticamente, indicar onde você tá errando, e você nem precisa saber muitos detalhes.

Mas fdisk não, fdisk ele te pede pra criar a partição nativa que vai montar como o root ou barra, a partição de swap e pra fazer isso você precisa digitar o número do primeiro e do último CILINDRO. Daí ele te mostra informações como setores ou sectors e cabeças ou heads. Esse é o sistema CHS, cylinder-sector-head que são as coordenadas que definem a geometria tridimensional do seu HD.

Se você nunca pensou nisso, vou resumir. Se você abrir um HD mecânico, vai encontrar vários discos organizados um em cima do outro. Em cima de cada disco vai ter um braço com uma cabeça na ponta, que é quem lê e escreve de fato no disco. Cada cabeça identifica um dos discos. Quantas cabeças tem depende do HD.

Agora, como se organiza o disco? Na época do LP de música, o disco de vinil era organizado numa trilha espiral. Você coloca a cabeça no começo da espiral, mais pra borda do disco e enquanto gira, a cabeça vai deslizando dentro da trilha, lendo o engruvinhado que representa as ondas, que ele traduz como som. E o final da trilha é perto do meio do disco.

HDs não são espiral, em vez disso é um conjunto de anéis um dentro do outro. É isso que chamamos de cilindro. A distância de cada cilindro varia de acordo com a evolução da tecnologia magnética da cabeça. Se os cilindros estiverem muito perto e o motor não tiver precisão suficiente, poderia acabar pulando cilindros. Então o número de cilindros é limitado pela resolução da cabeça e o limite onde o magnetismo causa interferência.

Em vez de ser um engruvinhado físico dentro da trilha como num disco de vinil, no caso de HD as trilhas são magnéticas. A cabeça serve pra magnetizar ou desmagnetizar um bit de cada vez. Faz de conta que se tem uma carga então é 1, se tira a carga é zero. Se as trilhas, ou cilindros ficarem pertos demais, a carga de um bit poderia afetar o estado do outro bit. Aliás, um jeito fácil de estragar um HD é colocar um ímã forte perto. Isso é verdade até hoje.

Um HD moderno tem mais de 16 mil cilindros por lado do disco. A estrutura de dados que identifica cada cilindro tem 16-bits então é possível ter até 65 mil quinhentos e trinta e seis cilindros. Eu acho que ainda não estamos perto de atingir esse limite. À medida que a precisão do motor e das cabeças foi aumentando a gente pulou de menos de 4 mil cilindros nos anos 90 até mais de 16 mil hoje. Por isso dá pra ter HDs com 18 terabytes ou mais.

Um disco pode ser escrito dos dois lados, assim como você pode virar um vinil e do outro lado tem mais música. Como num HD não tem como “virar” o disco, ele vai ter duas cabeças por disco. Numa estrutura padrão de 8-bits significa que podemos identificar até 256 cabeças, numeradas de 0 a 255, isso dá um máximo de 128 discos. Na prática, duvido que existe um HD que chega perto de 128 discos.

Continuando, esses cilindros são organizados em setores. Dependendo do sistema operacional, sistema de arquivos, os setores podem variar de tamanho. Um dos tamanhos mais comuns era 512 bytes. Hoje em dia acho que é 4 kilobytes. Estou especulando, mas eu acho que essa divisão existe pra ajudar a fragmentar menos os dados. Fora que não seria eficiente movimentar o motor pra ler um bit de cada vez. Ele vai ler blocos de bits de cada vez. Na realidade acho que mais de um setor.

Pra ler os bits no disco, o motor precisa mover a cabeça de uma borda a outra do disco, passando pelos cilindros. Digamos que você tenha um arquivo de 100 bytes. Agora imagine que você usou um sistema de arquivos bem estúpido que vai gravando cada byte em lugares aleatórios no disco. O pobre motor vai precisar trabalhar bastante pra achar cada byte. É um motor mecânico, se cada byte estiver num cilindro, isso vai fazer o motor trabalhar bastante e tudo vai ficar lento.

Agora, se os mesmos 100 bytes estiverem organizados sequencialmente, um byte atrás do outro, o motor só precisa ter o trabalho de chegar no primeiro byte do cilindro e pronto, girar o disco é mais fácil que mover a cabeça. Então é só deixar o disco girar e quando eu achar o primeiro byte vou lendo sequencialmente um atrás do outro. Isso minimiza o trabalho do HD.

Digamos que você tenha um arquivo de 21 mil e trezentos bytes, ou mais ou menos 21 ponto oito megabytes. Se dividir em setores de 512 bytes e arredondar, porque não dá pra ter números quebrados, seriam 42 setores. Mas isso daria um total de 21 mil quinhentos e quatro bytes, isso é duzentos e quatro bytes maior que nossos 21 mil e trezentos. E agora?

Na prática o HD vai reservar quarenta e dois setores. Ele vai usar quarenta e um setores inteiros e o último vai ocupar só trezentos e oito e deixar livre duzentos e quatro bytes. E esses duzentos e quatro bytes tão perdidos, não dá pra usar eles pra outro arquivo. Como os arquivos do seu sistema operacional e os que você produz nunca vão ser exatamente múltiplos de quinhentos e doze ou seja lá qual for o tamanho do setor, sempre o último setor vai desperdiçar alguns bytes de espaço inusável. E isso é normal.

É um dos motivos de porque o total ocupado no seu HD não é a soma do tamanho em bytes de todos os arquivos. Na prática vai ser um pouco mais, porque precisa ser múltiplo do tamanho do setor. Eu sempre falo que computação é um trade off. Pra ter zero desperdício de espaço, era só fazer cada setor ser 1 bit. Mas você já deve ter entendido que além de fragmentar bastante, isso ia fazer o motor do nosso HD suar sangue pra ler depois.

Com isso você entende porque a velocidade num HD nunca é constante. Depende do tamanho do arquivo, da fragmentação do drive. O problema é que nunca temos como saber se o drive vai ter mais arquivos muito pequenos ou poucos arquivos muito grandes. Por isso também costuma ser ordens de grandeza mais rápido ler um único arquivo gigante, tipo um zip grande ou um video ou um arquivo de ISO de 500 gigabytes em vez de quinhentos mil arquivos de 1 megabyte cada. O tamanho total é o mesmo, mas o número de operações do HD vai ser muito maior e é isso que mais afeta a velocidade.

O arquivo grandão tende a ter seus setores próximos. Mesmo com alguma fragmentação, você dá a ordem pro HD e ele só tem que se preocupar com uma sequência. Mas no caso de quinhentos mil arquivos, você vai ter que dar quinhentos mil comandos de leitura e pra cada arquivo o motor vai ficar se movendo pra achar onde no disco tá cada um. Isso que chamamos de overhead, o trabalho extra de ter que receber milhares de comandos em vez de só um.

Conseguem imaginar esse trampo? Não é à toa que um HD vai se deteriorando com o tempo. Daí como a gente não sabe se vai ter mais arquivos pequenos ou mais arquivos grandões, também precisamos achar um tamanho de setor que balanceia desperdício de espaço no último setor de um arquivo e não pode ser tão pequeno que vai fazer o HD ser mais lento tendo que caçar muitos setores por arquivo. Se eu quiser ter pouca ou nenhuma fragmentação, basta fazer setores gigantes, mas aí cabe poucos arquivos. Se eu quiser ter milhões de pequenos arquivos, desperdiçando pouco espaço, basta fazer o setor ser o menor possível, só que aí a velocidade vai cair drasticamente. Trade off.

Na maioria dos sistemas de arquivos o tamanho do setor não é menor que 512 bytes e em alguns casos pode ser mais próximo de 4 kilobytes. Isso desperdiça um pouco de espaço, mas o preço veio caindo então hoje temos espaço sobrando, daí dá pra desperdiçar espaço pra ter mais velocidade. Se estiver no Windows e quiser saber, basta abrir um command prompt com permissão de administrador e rodar fsutil fsinfo ntfsinfo c: ou outro drive. No meu caso por exemplo meu C: tem setores de 4 kilobytes e meu I: tem 512 bytes.

Voltando à nossa instalação de Linux RedHat do meio dos anos 90, cá estamos frente à frente com essa tela de fdisk pedindo pra gente adivinhar o tamanho das partições baseado em cilindros. Antigamente o tamanho máximo de um HD era pouco menos de 8 gigabytes. Eu falei que cada gigabyte custava uns 15 dólares? Então isso era um HD de uns 120 dólares. Em 2021 isso é o preço de um HD Barracuda de 6 Terabytes. Quase mil vezes maior.

Esse HD Barracuda de cinco mil e quatrocentos rotações por minuto, diz a propaganda que consegue uma velocidade máxima de 6 gigabits por segundo. Como é em bits, precisa dividir por 8 pra ter em bytes, que é uns 700 megabytes por segundo. Mas isso é velocidade teórica de pico. Na prática num HD desses você vai ter sorte se conseguir mais que uns 300 megabytes por segundo, em média.

Pra piorar nossa conta, HDs modernos mais caros tem módulos de memória RAM. Ou no caso de Intel Optane, tem um mini SSD de cache. A Barracuda tem duzentos e cinquenta e seis mega de RAM. Isso é pelo menos dezesseis vezes mais RAM do que eu tinha no meu PC em 1995, e é só pra cache. A vantagem de ter RAM no HD que ele pode manter dados mais acessados na memória daí não precisa movimentar o motor pra pegar nos discos, por exemplo. É uma das formas do HD mecânico ficar mais rápido.

Mais do que isso, quando você pede pra gravar seu arquivo na realidade você não pede pro HD. Você pede pro seu sistema operacional como seu Windows e o Windows que vai fazer o pedido pro HD. O HD tem RAM, mas sua máquina também tem RAM e o Windows vai primeiro gravar em RAM, esperar acumular mais operações de escrita, reordenar pra facilitar o trabalho e vai dar “ok” e devolver o controle pro seu editor de textos. Provavelmente ele nem mandou pro HD ainda. Quando mandar o HD pode usar a RAM dela e dizer pro Windows que tá tudo ok também.

Isso parece inteligente não parece? RAM é ordens de grandeza mais rápido que seu HD. Eu disse que a velocidade do HD mecânico vai ser na faixa de 300 megabytes por segundo, na média. Um pente de memória DDR4 de 3600 megahertz tem picos de velocidade de 28 GIGAbytes. Isso é quase cento e cinquenta vezes mais rápido. É isso que significa diferença de ordens de grandeza.

O problema desses níveis de cache no meio do caminho é que antigamente, quando você recebia OK que o arquivo foi gravado, com grande probabilidade ele realmente foi gravado. Se daqui 1 segundo a energia da sua casa cair e desligar seu computador, pelo menos aquele último arquivo com certeza gravou no seu disco.

Hoje, se a força cair, você não tem certeza que o arquivo foi gravado. Provavelmente foi, porque é rápido, mas não se sabe. Num desktop, computador doméstico, tudo bem, porque raramente vai dar coincidência de você estar no meio da operação de escrita e a energia cair. Mas num servidor, tipo do Dropbox, com milhões de pessoas subindo arquivos sem parar, as chances de perder dados se a energia cair é alta. Por isso data centers tem tantos sistemas de redundância. O sistema de RAID que eu falei é só uma das peças do Lego deles.

Enfim, acabei dando uma tangente. O ponto é que todas essas peças móveis, dos HDs mecânicos até seu programa, tem muitas camadas no meio do caminho, muitos caches, e uma pane em alguma dessas camadas vai fazer você perder arquivos. Felizmente em 2021 as chances de você perder ou corromper arquivos é menor do que na minha época de MS-DOS e Winchesters de meros 20 megabytes que custavam uma fortuna.

E eu ainda não terminei o fdisk do Linux que tava instalando. Se prestar atenção, mesmo o fdisk de 1997 já tem uma ajuda. Nas primeiras versões você precisava saber tudo o que eu falei até agora sobre a geometria física dos HDs. Se eu tinha um HD de 8 giga, ia querer reservar uma partição de swap de uns 128 megabytes, que era o máximo.

Olha só essa tela do fdisk. Eu dou p pra dar print nas partições. Não tem nada. Daí dou n pra new ou nova partição. Começo no cilindro 1. Agora eu precisaria fazer esse cálculo que ele mostra acima. Unidade é cilindros vezes 16 mil sessenta e cinco setores, onde cada setor tem quinhentos e doze bytes, então cada cilindro pode ter uns 8 megabytes.

Em cima ele fala que meu disco pode ter até mil e vinte e quatro cilindros, cada cilindro com sessenta e três setores, indo de zero até duzentos e cinquenta e cinco heads ou cabeças. Claro que meu HD vai ter menos que isso. 128 megabytes é do cilindro 1 até dezessete, o que vai dar cento e trinta e seis blocos. O fdisk assume cada bloco tendo uns mil e vinte e quatro bytes. Pra chegar no número de cilindros é só dividir os cento e vinte e oito que eu quero por mil e vinte e quatro.

Pra ter o número de blocos por cilindro é só dividir a unidade, os quase 8 gigas por mil e vinte e autro. Isso dá o número de blocos por cilindro que são uns oito mil. Agora é multiplicar isso pelo número de cilindros pra cada partição. Cento e vinte e oito mega dividido por 8 vai dar dezesseis e uns quebrados, por isso arredonda pra 17.

Achou chato? Pois é, isso era chato. Agradeça que os aplicativos de particionamento hoje fazem todas essas contas pra você. Na realidade, a partir de 2002 com o padrão ATA-6 finalmente mudamos pro sistema de endereçamento linear de 48-bits chamado LBA ou Logical Block Addressing. E com isso esse sistema CHS de cilindro, cabeça, setor foi declarado obsoleto.

LBA é um mapeamento de endereços lineares em cima do sistema de CHS que o HD entende fisicamente por baixo. 2 elevado a 48 dá um máximo de duzentos e cinquenta e seis terabytes. Parece bastante pra uso doméstico, mas pra servidores não é tanto assim não. Por isso depois foi de 48-bits pra 64-bits.

Assim você endereça o disco do endereço zero até duzentos e cinquenta e seis teras. E por baixo ele vai converter em cilindros, cabeças e setores como antes. Você vai notar que muito na programação é fazer “de-para” que é conversão de coisas complicadas em coisas mais simples.

Tabelas de-para é que nem um dicionário, você traduz as coordenadas tridimensionais do disco por exemplo, cilindro, cabeças e setores num número. E pro sistema operacional, pra você como programador, é como se fosse um arrayzão gigante de 0 até aquele máximo. À medida que as coisas evoluem a gente pode desperdiçar um pouco de memória e processamento em ficar fazendo essas conversões.

Desta vez vou quebrar o assunto em múltiplos episódios. Eu fui escrevendo e no final deu quase 80 páginas de coisas que se eu tentar explicar tudo de uma só vez vai ficar complicado demais. Acho que por hoje já foi o suficiente, mas não se preocupem que eu já escrevi a continuação então o próximo episódio vai chegar mais rápido dessa vez. Se ficaram com dúvidas mandem nos comentários abaixo, não deixem de assinar o canal e clicar no sininho pra não perder a continuação, e compartilhem o video pra ajudar o canal. A gente se vê, até mais.