Zdb: o guia definitivo para auditar metadados e estruturas do ZFS

Se você administra sistemas de armazenamento baseados em ZFS, provavelmente vive no conforto do comando zpool status. Ele é amigável, diz que tudo está "ONLINE" e você dorme tranquilo. Mas o ZFS é um sistema de arquivos transacional complexo, com uma árvore de Merkle gigantesca gerenciando cada bloco de dados. Quando algo estranho acontece — performance degradada sem motivo, taxas de compressão suspeitas ou a necessidade de planejar deduplicação — o zpool status não vai te ajudar.

É aqui que entra o zdb (ZFS Debugger). Ele é a ferramenta de engenharia reversa nativa do ZFS. Diferente dos comandos de administração (zfs e zpool), o zdb lê as estruturas on-disk diretamente, ignorando muitas vezes o cache do sistema operacional para mostrar a verdade nua e crua sobre como seus bits estão organizados nos discos.

Resumo em 30 segundos

• Ferramenta de análise profunda: O zdb permite visualizar estruturas internas do ZFS (MOS, DDT, DVA) que são invisíveis aos comandos padrão.
• Planejamento de capacidade: A flag -S é o padrão ouro para calcular se a deduplicação economizará espaço suficiente para justificar o custo de RAM.
• Cuidado com a memória: Executar o zdb em pools grandes pode consumir gigabytes de RAM e causar evicção do ARC, impactando a performance de produção.

O perigo de usar o debugger em produção

Antes de começarmos a dissecar os metadados, um aviso técnico necessário. O zdb roda em user space, mas ele precisa carregar metadados do disco para a memória para analisá-los.

Em um pool vazio, isso é trivial. Em um pool com centenas de terabytes e milhões de arquivos, rodar um comando como zdb -dddd pode forçar o sistema a ler uma quantidade massiva de metadados. Isso compete diretamente com o ARC (Adaptive Replacement Cache) do ZFS.

⚠️ Perigo: Em sistemas com pouca memória livre, o uso agressivo do zdb pode empurrar dados quentes para fora do cache ou, em casos extremos de OOM (Out of Memory), derrubar serviços. Use com cautela em horários de pico.

A configuração oculta do MOS (-C)

Muitos administradores acreditam que a configuração do pool vive apenas no arquivo /etc/zfs/zpool.cache. Na verdade, a fonte da verdade é o MOS (Meta Object Set), uma estrutura de dados especial gravada dentro do próprio pool.

Para ver a configuração real que está gravada nos discos, usamos a flag -C.

zdb -C tanque_dados

A saída revela detalhes que o zpool get all esconde:

• GUIDs dos vdevs: Identificadores únicos de cada disco e do pool.

• Ashift real: O alinhamento de setor configurado no momento da criação (ex: ashift: 12 para 4K).

• Caminhos físicos: Onde o ZFS espera encontrar o dispositivo (/dev/disk/by-id/...).

Isso é vital quando você importa um pool e ele reclama de dispositivos ausentes ou IDs duplicados. O zdb -C mostra exatamente o que o ZFS está procurando.

Figura: Diagrama esquemático do Meta Object Set (MOS) no ZFS, ilustrando como as configurações críticas residem fisicamente nos discos.

Mapeando a distribuição de blocos (-b)

Se você quer entender a eficiência do seu armazenamento, a flag -b (block statistics) é sua melhor amiga. Ela percorre todos os metadados de blocos e gera um histograma de tamanhos e tipos.

zdb -b tanque_dados

A saída é densa, mas focaremos em três colunas críticas que explicam o comportamento do seu storage:

1. LSIZE (Logical Size): O tamanho do dado como a aplicação o enviou.

2. PSIZE (Physical Size): O tamanho do dado após a compressão (LZ4, ZSTD).

3. ASIZE (Allocated Size): O espaço real ocupado no disco físico, considerando o alinhamento (ashift) e paridade RAID-Z.

💡 Dica Pro: Se o seu ASIZE for muito maior que o PSIZE, você tem um problema de "slack space". Isso acontece frequentemente ao gravar arquivos pequenos (4K ou 8K) em vdevs RAID-Z2 ou RAID-Z3, onde o overhead de paridade e padding consome mais espaço que o próprio dado.

A verdade sobre a deduplicação (-S)

A deduplicação no ZFS é famosa por ser um "assassino de performance" se ativada sem a RAM necessária. A regra prática antiga dizia "1GB de RAM para cada 1TB de dados deduplicados", mas isso varia.

Nunca ative dedup=on sem antes consultar o zdb. A flag -S simula a Tabela de Deduplicação (DDT) na memória, lendo todos os blocos do pool e calculando quanto espaço você economizaria se a deduplicação estivesse ativa.

zdb -S tanque_dados

O resultado final é o Deduplication Ratio.

• Se o ratio for 1.05x, você economizaria 5% de espaço. Não vale o custo de RAM e CPU.

• Se o ratio for 5.00x (comum em ambientes de VDI ou backups), a deduplicação pode ser viável.

Este comando é pesado. Ele precisa ler todos os checksums de todos os blocos. Em pools grandes, pode levar horas ou dias.

Figura: Visualização do processo de deduplicação do ZFS, destacando a relação entre a Tabela de Deduplicação (DDT) na memória RAM e os blocos físicos únicos no disco.

Navegando por objetos e endereços DVA

O ZFS não pensa em "arquivos" da mesma forma que um sistema de arquivos tradicional pensa em inodes estáticos. Tudo no ZFS é um objeto, identificado por um ID dentro de um dataset.

Quando você vê um erro de corrupção no zpool status -v do tipo: tanque_dados/projetos:<0x1a4>

Aquele 0x1a4 é o número do objeto em hexadecimal. O zdb permite inspecionar esse objeto especificamente:

zdb -dddd tanque_dados/projetos 0x1a4

As flags -d controlam a verbosidade. Com quatro níveis (-dddd), você vê:

1. Atributos do arquivo: Permissões, acls, timestamps.

2. Ponteiros de dados: A lista de DVAs (Data Virtual Addresses).

Um DVA se parece com isto: vdev:offset:asize. Ele diz exatamente em qual disco (vdev ID), em qual setor (offset) e qual o tamanho alocado (asize) aquele pedaço do arquivo reside. Isso é a prova definitiva de onde seus dados estão fisicamente.

Comparativo: Zpool Status vs. Zdb

Para consolidar o entendimento, veja onde cada ferramenta brilha:

Característica	zpool status	zdb
Foco Principal	Saúde operacional e topologia	Estrutura interna, metadados e debug
Nível de Acesso	Alto nível (Kernel/API)	Baixo nível (Leitura direta de disco/User space)
Impacto no Sistema	Baixo (seguro para rodar sempre)	Alto (pode causar I/O wait e consumo de RAM)
Uso Comum	Verificar falhas de disco, resil scrub	Analisar corrupção, testar dedup, ver configs MOS
Complexidade	Baixa	Alta (requer conhecimento da arquitetura ZFS)

Troubleshooting: Quando o zdb falha

Às vezes, o zdb se recusa a abrir o pool. O erro mais comum é: zdb: can't open 'tanque_dados': No such file or directory

Isso geralmente acontece porque o zdb tenta ler o arquivo /etc/zfs/zpool.cache para saber onde estão os discos. Se você está em um ambiente de recuperação (Live CD) ou o cache está desatualizado, o comando falha.

A solução é usar a flag -e (exportado/externo). Isso diz ao zdb: "Não olhe o cache, escaneie os dispositivos disponíveis em /dev e procure pelo pool com este nome".

zdb -e tanque_dados -C

Isso é extremamente útil para análises forenses em discos que foram movidos de um servidor para outro sem serem importados oficialmente.

Veredito do debugger

O zdb não é uma ferramenta para o dia a dia. Se você está usando zdb diariamente, algo está muito errado com sua infraestrutura ou você é um desenvolvedor do OpenZFS. No entanto, para o arquiteto de storage, ele é a única lanterna disponível quando as luzes se apagam.

Ele transforma a "caixa preta" do ZFS em um sistema transparente de ponteiros, objetos e transações. Use-o para validar suas hipóteses sobre compressão e deduplicação, mas respeite o custo de recursos que ele impõe ao servidor.

---

O zdb pode corromper meu pool ZFS?

Geralmente não, pois o zdb opera em modo somente leitura por padrão. No entanto, ele pode causar alta carga de I/O e consumo de memória, o que pode impactar a performance de um pool em produção.

É necessário exportar o pool para usar o zdb?

Não é estritamente necessário, mas é recomendado para garantir a consistência dos dados analisados. Você pode usar a flag '-e' para operar em pools exportados ou snapshots para evitar inconsistências em sistemas vivos.

Como verificar se vale a pena ativar a deduplicação?

Utilize o comando 'zdb -S nome_do_pool'. Ele simulará a tabela de deduplicação na memória e informará a taxa de dedup real (DDT) baseada nos dados atuais, permitindo avaliar se a economia de espaço justifica o custo de RAM.