Obtendo arquivos do XFS com tamanho de bloco de 64kb

Eu tenho a missão de recuperar arquivos de uma das minhas 2 unidades NAS perfeitamente funcionais, não corrompidas e não criptografadas que costumavam estar no RAID 1. O NAS era o Patriot Javelin S4, que (como descobri na minha pesquisa ) usa o controlador de invasão falso Promise Fasttrack.

As informações são muito escassas sobre isso; portanto, para os googlers na mesma situação, aqui estão alguns fatos sobre esse NAS:

• Controlador RAID: Promise FastTrack (FakeRaid)
• Sistema de volume: LVM2
• Sistema de arquivos: XFS com tamanho de bloco de 64kb (65536 bytes)
• Arco: Processador AMCC PowerPC de 800 MHz, 256 MB de RAM (graças à pesquisa de Matthew)

Eu só tinha computador com Windows 10 e MacOS ao fazer isso e não encontrei nenhum software capaz de montar o XFS no volume LVM2 (com uma exceção, mais sobre isso abaixo). Eu tive que pegar meu netbook antigo Acer Aspire One e instalar o linux puppy (especificamente o sabor lxpup).

No puppy linux, consegui montar este sistema de arquivos usando uma ferramenta chamada dmraid. Essa ferramenta possui uma maneira de montar um volume pdc, que é seu ID para o Promise FastTrack. Depois que consegui pular alguns bastidores para montá-lo, obtive acesso ao sistema de arquivos XFS real e, para minha consternação, o tamanho do bloco era de 64kb.

Foi aqui que comecei a pesquisar no Google coisas como "leia o tamanho do bloco xfs 64kb" e a chegar a lugar nenhum. Apenas algumas respostas que dizem: "o linux não pode ler tamanhos de bloco maiores que 4kb, a menos que você faça o patch do kernel". Eu não tenho idéia de como consertar o kernel, e estou desconcertado por não haver nenhum tipo de emulação para permitir isso.

Mencionei 1 exceção entre aplicativos que não conseguem ler esta partição no Win / Mac. Essa exceção foi ufsexplorer. É um aplicativo de US $ 100, que foi capaz de me mostrar perfeitamente os arquivos. Copiei alguns arquivos para provar que funciona, mas a versão de teste permite apenas copiar arquivos pequenos.

Recuso-me a acreditar que não existe uma ferramenta gratuita de código aberto disponível para qualquer nível de complexidade que não possa me ajudar a ler xfs de 64kb.

Minha pergunta é: alguém conhece alguma dessas ferramentas? Todas as instruções específicas sobre como obter os dados usando uma ou mais ferramentas, ou correção de kernel ou outra coisa (gratuita) são muito apreciadas.

Mais um ponto: eu preferiria não ter que criar imagens locais dessas unidades (a menos que seja a única maneira). Afinal, são 2 TB de dados, talvez eu não tenha tanto espaço.

PS Se houver um linux conhecido que eu possa instalar no meu Acer que possa ler 64kb xfs, essa também é uma solução viável.

Atualização 1 : Acabei de aprender sobre https://www.cgsecurity.org/wiki/TestDisk . Pode valer a pena tentar. Irá relatar uma vez que tive tempo de experimentá-lo.

Atualização 2 : O TestDisk parece reconhecer a presença da partição XFS, mas não tenho certeza de como proceder nesse formulário. Não vejo uma maneira de extrair um arquivo, então apenas o abandonei por enquanto, e tentando a abordagem do qemu na resposta de Matthew.

Pesquisei um pouco seu problema. Não é fácil, mas parece viável.

A área de quebra de código é essa (bem, nos kernels mais recentes): fs/xfs/libxfs/xfs_sb.c

271         /*
272          * Until this is fixed only page-sized or smaller data blocks work.
273          */
274         if (unlikely(sbp->sb_blocksize > PAGE_SIZE)) {
275                 xfs_warn(mp,
276                 "File system with blocksize %d bytes. "
277                 "Only pagesize (%ld) or less will currently work.",
278                                 sbp->sb_blocksize, PAGE_SIZE);
279                 return -ENOSYS;
280         }

Basicamente, requer que o tamanho do bloco XFS seja pelo menos igual ao tamanho da página do sistema.

Isso significa duas coisas.

1. Esta é uma solução alternativa para um bug anteriormente desconhecido.
2. O tamanho da página dos sistemas originalmente era de 64k.

Fui e verifiquei um kernel realmente antigo (EL4) e essa restrição acima ainda estava lá. Isso significa que é fundamentalmente inviável fazer o que você quer fazer na sua arquitetura (x86).

Como você forneceu o nome do NAS, pesquisei no Google e descobri isso: http://www.techwarelabs.com/patriot-javelin-s4-network-attached-storage/2/

O que implica que ele usa uma CPU PPC.

O hardware do Javelin é mais do que capaz de lidar com funções adicionais. É essencialmente um sistema Linux incorporado com um processador PowerPC AMCC de 800 MHz e 256 MB de RAM.

De fato, no PowerPC os kernels podem ser construídos para usar 64k ou 4k. Isso explicaria por que o bloco é de 64k e também por que você não pode executar o sistema de arquivos em sua máquina, onde ele trabalhou anteriormente em seu próprio NAS.

Se você deseja tentar abrir o sistema de arquivos - acho que sua melhor opção é executar uma instância de máquina virtual em um hipervisor usando PPC64LE (acho que essa é a arquitetura real dessa CPU), o Fedora constrói seu PPC64LE com 64k páginas.

https://alt.fedoraproject.org/alt/

Você pode usar o qemu para fazer isso. Esse cara parece dar algumas instruções (não testadas) sobre como você faria isso.

https://rwmj.wordpress.com/tag/ppc64le/

A partir daí, exponha diretamente o (s) disco (s) na VM e faça seu dmraid / lvm / mount normal para obter acesso à unidade.