Recentemente tive problemas com um sistema de arquivos btrfs em um kernel 4.10.0 atualizado. O sistema de arquivos foi destruído em uma VM virtualbox porque o TRIM não parece estar corretamente implementado em algum lugar, e o AFAIK tem algo a ver com números de índice de sub volumes. Depois de mudar para o VMware, o sistema de arquivos ainda estava corrompido e, surpreendentemente, btrfs check não conseguiu localizar e corrigir o erro. Finalmente voltei para o ext4.
A coisa boa: eu não perdi dados. O btrfs parece ser sempre consistente, pelo menos para leitura, mas me mostrou que ainda está longe da preparação da produção.
De qualquer forma, em um servidor, ainda estou usando-o como volume de backup, porque preciso do recurso de cópia de dados para deduplicação (exatamente o seu caso de uso). Os dados são muito grandes para um sistema de arquivos tradicional.
Atualizar
Eu ainda tenho o sistema de arquivos no meu servidor (veja acima), mas ele quebrou logo depois que postei isso aqui. Agora, eu tenho um grande volume de backup somente leitura de 700G que expande para ~ 7TB no ext4 se eu tentar copiar tudo usando tar|tar . Devido à falta de tempo, eu ainda não verifiquei se versões mais novas do kernel podem lidar com isso. O problema real é uma "anulação de transação", que ocorre ~ 2 segundos após a montagem gravável e que remonta o volume somente leitura. A causa original é provavelmente uma versão quebrada de btrfs-convert , que usei anos atrás quando criei este volume, e ainda um conjunto limitado de recursos do atual btrfs check , que deveria pelo menos encontrar todos os danos em um volume que reprodutivelmente levem a uma transação abortar ou quaisquer outros problemas, em vez de apenas dizer que meu sistema de arquivos é saudável.