Sim, é provavelmente um problema relacionado ao BTRFS.
Como regra geral, o du clássico não é confiável com o BTRFS, e muitas vezes pode dar resultados aparentemente absurdos como esse. Em última análise, isso decorre do fato de que stat() (a chamada do sistema que du usa para ver quanto espaço cada arquivo está usando no disco) não sabe ou se importa com reflexos, instantâneos, compactação transparente ou praticamente nada outra coisa que o BTRFS fornece além da semântica POSIX padrão.
O impacto disso é que du contará todos os blocos compartilhados entre arquivos por meio de reflinks (que incluem todos os blocos que foram desduplicados, blocos compartilhados por causa dos arquivos sendo copiados usando o clone ioctl e qualquer um que faça parte dos instantâneos ) uma vez cada arquivo que contém uma referência a esse bloco e, portanto, du pode mostrar o uso de disco aparente muito maior do que o uso de espaço real.
Sugiro usar btrfs filesystem du em vez de du , pois ele contará corretamente todo o uso de espaço compartilhado.
Note também que o GNOME Disk Utility e df também não são totalmente confiáveis quando lidam com BTRFS, mas por razões diferentes (eles respondem corretamente pelos reflinks, mas não entendem o alocador de dois estágios que o BTRFS usa, então eles podem realmente relatar o disco como quase vazio mesmo se você não puder escrever nada nele). Como resultado disso, eles freqüentemente mostrarão valores de uso diferentes daqueles que você obteria executando du na raiz do sistema de arquivos. (e fica ainda pior se você usar du -x , porque isso não cruzará os limites de subvolume, pois eles se parecem com pontos de montagem).