Substitui acidentalmente os dois ZILs na última versão do OpenSolaris, o que causou a perda irrevogavelmente de todo o pool. (Erro muito ruim da minha parte! Não entendi que perder o ZIL significaria perder o pool. Felizmente, recuperei-me do backup com o tempo de inatividade.)
Desde a versão 151a (não sei de antemão como a versão do ZPool significa isso), esse problema foi corrigido. E posso testemunhar que funciona.
Além disso, perdi dados ZERO em um servidor de 20 TB - inclusive devido a vários outros casos de erro do usuário, várias falhas de energia, gerenciamento inadequado de disco, configurações incorretas, vários discos com falha etc. As interfaces de configuração no Solaris mudam com frequência e de maneira irritante de versão para versão e apresentam um objetivo significativo de habilidades em constante mudança; ainda é a melhor opção para o ZFS.
Não apenas não perdi dados no ZFS (depois do meu terrível erro), mas ele me protege constantemente. Não tenho mais corrupção de dados - que me atormentou nos últimos 20 anos em vários servidores e estações de trabalho, com o que faço. A corrupção de dados silenciosa (ou apenas "bastante silenciosa") me matou várias vezes, quando os dados saem da rotação de backup, mas na verdade se tornam corrompidos no disco. Ou outros cenários em que os backups fizeram backup das versões corrompidas. Esse tem sido um problema muito maior do que apenas perder dados em grande escala de uma só vez, que é quase sempre feito de qualquer maneira. Por esse motivo, adoro o ZFS e não consigo entender por que a soma de verificação e a recuperação automática não são recursos padrão nos sistemas de arquivos há uma década. (É verdade que os sistemas de vida ou morte geralmente têm outras formas de garantir a integridade,
Preste atenção, se você não quiser entrar no inferno da ACL, não use o servidor CIFS embutido no ZFS. Use o Samba. (Você disse que usa o NFS.)
Não concordo com o argumento SAS vs. SATA, pelo menos a sugestão de que o SAS sempre é preferível ao SATA, para o ZFS. Não sei se esse comentário foi referente à velocidade de rotação do prato, confiabilidade presumida, velocidade da interface ou algum outro atributo. (Ou talvez apenas "eles custem mais e geralmente não sejam usados pelos consumidores, portanto são superiores". Uma pesquisa recente do setor (ainda nas notícias, tenho certeza) revelou que a SATA realmente sobrevive ao SAS em média, pelo menos com o tamanho significativo da amostra da pesquisa. (Chocou-me, com certeza.) Não me lembro se eram versões "corporativas" do SATA, ou consumidor, ou o que acelera - mas, em minha experiência considerável, os modelos corporativo e de consumidor falham ao mesmo tempo. taxas estatisticamente significativas. (Existe o problema de as unidades consumidoras levarem muito tempo para esgotar o tempo de falha, o que é definitivamente importante na empresa - mas isso não me incomodou, e acho que é mais relevante para os controladores de hardware que podem levar todo o tempo. volume off-line nesses casos. Mas isso não é um problema SAS vs SATA, e o ZFS nunca me falhou com isso.Como resultado dessa experiência, agora uso uma combinação de 1/3 de unidades empresariais e 2/3 de unidades SATA de consumo .) Além disso, não vi desempenho significativo com esse mix de SATA, quando configurado corretamente (por exemplo, uma faixa de espelhos de três vias), mas, novamente, tenho uma baixa demanda de IOPS, portanto, dependendo do tamanho da sua loja e casos de uso típicos, YMMV. Definitivamente, notei que o tamanho do cache interno por disco é mais importante para os problemas de latência do que a velocidade de rotação do prato nos meus casos de uso.
Em outras palavras, é um envelope com vários parâmetros: custo, taxa de transferência, IOPS, tipo de dados, número de usuários, largura de banda administrativa e casos de uso comuns. Dizer que o SAS é sempre a solução certa é desconsiderar um grande universo de permutações desses fatores.
Mas de qualquer maneira, o ZFS é ótimo.