ext4 inodes em uso para arquivos que estão faltando

Question

Resumo executivo:

• Toda ferramenta que eu tentei confirma muitos inodes em uso nesta partição ext4
• Toda ferramenta que tentei me mostra que não há arquivos na partição
• Não são arquivos abertos e não é uma montagem de sobreposição

Longa história:

Eu tenho um SSD com uma única partição ext4. Essa unidade estava sendo usada para armazenar vídeo continuamente de câmeras, em clipes curtos, e uma tarefa cron excluiria periodicamente os clipes mais antigos (em um aplicativo C, que os apagava chamando remove() ). Depois de algum tempo, alguém notou que, embora devesse haver cerca de 5 dias de backup de vídeo, quase não existia, mas o disco estava quase cheio.

Eu dei uma olhada e tentei ingenuamente apenas remover lost+found , mas a unidade ainda estava cheia. Então, eu deletei tudo ( rm -rf * ), mas df -i me diz que 91230 inodes estão em uso, mesmo que ls e du não mostrem nada.

e2fsck -fv não encontrou erros para corrigir (além de criar lost+found novamente) e dumpe2fs e tune2fs -l concordam com df -i no número de inodes usados. Eu tentei e2fsck -b com alguns dos super-blocos de backup e não pareceu fazer nenhuma diferença.

baobab mostra o mesmo espaço usado como df na visualização de resumo, mas quando clico na partição para ver onde o espaço é usado, ela mostra apenas os 4,1 kB usados pelo diretório lost+found vazio.

O problema é não que identificadores de arquivos excluídos que ainda estão abertos - nada está aberto. Eu montei e desmontei essa partição várias vezes, e até mesmo tirei a unidade e a coloquei em uma máquina completamente diferente.

Eu sei que eu poderia apenas reformatar a partição e começar de novo, mas eu realmente gostaria de entender o que está acontecendo aqui e se há algum jeito "correto" de consertar isso - eu não ligo se isso traz os arquivos para esses inodes voltar ou isso os torna excluídos corretamente para que eles não ocupem todo o espaço.

Editar: Executar dump cria um arquivo de backup aproximadamente igual em tamanho ao espaço usado relatado por df et al. Em seguida, executar restore para uma unidade diferente criou uma cadeia de diretórios que está claramente errada ( /media/usb0/20150426/10/1_20150426_100125.264/20150426/10/1_20150426_100125.264/ e continua com vários níveis de profundidade, repetindo a mesma estrutura), antes de imprimir várias linhas como:

expected next file 7823361, got 7610674
expected next file 7823361, got 7610675

(segundo incremento de número - vai muito além do buffer do meu terminal) antes de finalmente:

cannot find directory inode 11
abort? [yn]

Escolher n resulta em mais "não é possível encontrar o nó do diretório x", então abortei.

Desistindo e escrevendo isso como uma corrupção freak do sistema de arquivos que, esperamos, não acontecerá novamente.