Cenário:
No outro dia eu estava tentando "desmontar" alguns volumes lógicos para que eu pudesse fechar a partição LUKS em que estavam. Eu acidentalmente uso lvremove pensando que era o comando certo para usar; depois que eu percebi que não era eu restaurei minha configuração do LVM com o backup que ele criou antes de lvremove .
Configuração:
Eu tenho um único SSD com uma única partição LUKS, dentro disso é uma partição LVM com três volumes lógicos para swap, root e home. Raiz e home são sistemas de arquivos ext4. Então
SSD (LUKS (LVM (swap, raiz (ext4), home (ext4))))
Conclusão:
Eu determinei que os metadados que descrevem meu sistema de arquivos ext4 foram corrompidos. Eu sei disso porque tentei repará-lo usando o
e2fsck -f /dev/ubuntu/home
Eu tentei repará-lo usando superblocos de backup | e2fsck -f -b 12345 /dev/ubuntu-vg/home
Eu usei TestDisk
para tentar repará-lo
Eu tentei usar extundelete
(não é possível encontrar os superblocos)
Eu até examinei o hexadecimal bruto usando xxd -a /dev/ubuntu-vg/home | less
e comparou com um sistema de arquivos ext4 em funcionamento
Perguntas:
É possível recuperar os arquivos usando algum tipo de "varredura profunda"?
Este é um problema conhecido com LVM e SSDs ou é uma anomalia?
Quando o LVM desaloca os blocos de memória no SSD, uma operação TRIM ou "wear leveling" ocorre corrompendo os dados?