A maneira tradicional é copiar todos os arquivos em outro lugar e ver qual aciona um erro de leitura. É claro que isso não responde à pergunta se o erro estiver oculto pela redundância da camada RAID.
Além disso, eu só conheço a abordagem manual. O que é muito incômodo para se levar adiante, e se há uma ferramenta que faz essa mágica para você, ainda não ouvi falar disso, e não tenho certeza se ferramentas mais genéricas (como blktrace
) ajuda nesse sentido.
Para o sistema de arquivos, você pode usar filefrag
ou hdparm --fibmap
para determinar os intervalos de blocos de todos os arquivos. Alguns sistemas de arquivos oferecem ferramentas para fazer a pesquisa em outra direção (por exemplo, debugfs icheck
), mas eu não sei de um syscall que faça o mesmo, então parece não haver uma interface genérica para pesquisas de arquivos em block > p>
Para o LVM, você pode usar lvs -o +devices
para ver onde cada LV está armazenado; você também precisa saber o pvs -o +pe_start,pe_size
. Na verdade, pode ser mais legível no vgcfgbackup
. Isso deve permitir que você traduza os endereços do sistema de arquivos para bloquear endereços em cada PV.
Para LUKS, você pode ver o deslocamento em cryptsetup luksDump
.
Para o mdadm, você pode ver o deslocamento em mdadm --examine
. Se o nível do RAID for diferente de 1, você também precisará fazer algumas contas e, mais especificamente, você precisa conhecer o layout do RAID para entender qual endereço no dispositivo md
pode traduzir para qual bloco do RAID dispositivo de membro.
Por fim, você precisará considerar os deslocamentos de partição, a menos que esteja usando os discos diretamente, sem qualquer particionamento.