ZFS - a destruição de zvol desduplicado ou conjunto de dados interrompe o servidor. Como recuperar?

Estou usando o Nexentastor em um servidor de armazenamento secundário em execução em um HP ProLiant DL180 G6 com 12 unidades SAS de linha média (7200 RPM). O sistema possui uma CPU E5620 e 8 GB de RAM. Não há dispositivo ZIL ou L2ARC.

Na semana passada, criei um zvol esparso de 750 GB com desduplicação e compactação ativada para compartilhar via iSCSI com um host VMWare ESX. Criei uma imagem do servidor de arquivos do Windows 2008 e copiei ~ 300 GB de dados do usuário para a VM. Uma vez satisfeito com o sistema, mudei a máquina virtual para um armazenamento NFS no mesmo pool.

Depois de instalado com minhas VMs no armazenamento de dados NFS, decidi remover o zvol original de 750 GB. Isso impediu o sistema. O acesso à interface da web Nexenta e o NMC foram interrompidos. Acabei conseguindo chegar a uma casca crua. A maioria das operações do SO foi boa, mas o sistema estava travando no zfs destroy -r vol1/filesystemcomando. Feio. Encontrei as duas entradas a seguir do bugSilla do OpenSolaris e agora entendo que a máquina ficará emparelhada por um período desconhecido. Faz 14 horas, então eu preciso de um plano para recuperar o acesso ao servidor.

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6924390

e

http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=593704962bcbe0743d82aa339988?bug_id=6924824

No futuro, provavelmente vou seguir o conselho dado em uma das soluções alternativas do buzilla:

Workaround
    Do not use dedupe, and do not attempt to destroy zvols that had dedupe enabled.

Atualização: tive que forçar o sistema a desligar. Após a reinicialização, o sistema para em Importing zfs filesystems. Tem sido assim por 2 horas agora.

Isso foi resolvido. A chave é que os volumes deduplicados precisam ter o sinalizador de deduplicação desativado antes da exclusão. Isso deve ser feito no nível do conjunto, bem como no zvol ou no sistema de arquivos. Caso contrário, a exclusão será essencialmente deduplicada. O processo leva tempo porque a tabela de deduplicação do ZFS está sendo referenciada. Nesse caso, a RAM ajuda. Adicionei temporariamente 16 Gigabytes de RAM adicionais ao sistema e coloquei o servidor novamente online. O zpool foi importado completamente dentro de 4 horas.

A moral é provavelmente que o deduplicador não é super polido e que a RAM é essencial para seu desempenho. Estou sugerindo 24 GB ou mais, dependendo do ambiente. Caso contrário, deixe a deduplicação do ZFS desativada. Definitivamente, não é razoável para usuários domésticos ou sistemas menores.

Como usuário de longa data dos appliances Sun / Oracle ZFS 7000-series, posso dizer-lhe, sem dúvida, que a deduplicação não é polida. Nunca confunda vendas com entrega! Os vendedores dirão "Oh, foi consertado". Na vida real - minha vida real -, posso dizer que 24 GB não é suficiente para lidar com as "tabelas DDT". Ou seja, o índice de back-end que armazena a tabela de desduplicação. Essa tabela deve residir na memória do sistema para que cada E / S seja interceptada em andamento para descobrir se precisa ser gravada no disco ou não. Quanto maior o seu pool de armazenamento, mais alterações de dados, maior esta tabela - e maior demanda na memória do sistema. Essa memória custa às custas do ARC (cache) e, às vezes, do próprio sistema operacional - e é por isso que você trava, pois certos comandos acontecem em primeiro plano, outros em segundo plano. Parece que a exclusão do pool ocorre em primeiro plano, a menos que você diga o contrário na CLI. Os assistentes da GUI não farão isso.

Mesmo uma exclusão em massa de dados NFS em um compartilhamento definido em um volume deduplicado reduzirá a metade do sistema se você não tiver memória suficiente para processar as "gravações" no ZFS, solicitando que ele exclua os dados.

Em suma, a menos que você maximize sua memória e, mesmo assim, encontre uma maneira de reservar memória para o sistema operacional restringindo o ARC e o DDT (e eu não acho que você possa restringir o DDT por natureza), é apenas um índice vinculado exatamente à sua E / S) - então você é processado durante grandes exclusões ou zvol / pools de destino.