Como posso descobrir onde um arquivo está fisicamente localizado no disco (números de bloco)?

10

Esta é uma pergunta obscura, eu sei. Estou tentando fazer alguns testes de desempenho de alguns discos em uma caixa Linux. Estou obtendo resultados inconsistentes, executando o mesmo teste no mesmo disco. Eu sei que os discos têm desempenho diferente dependendo da parte do disco que está sendo acessada. Em particular, as leituras e gravações na parte externa do disco têm uma taxa de transferência muito maior do que as leituras e gravações na parte interna do disco, devido à densidade de dados quase constante e à velocidade de rotação constante.

Gostaria de ver se minhas inconsistências podem ser atribuídas a essa variação na taxa de transferência induzida pela geometria. É possível, usando as ferramentas existentes, descobrir onde o arquivo foi colocado no disco?

Caso contrário, suponho que posso escrever algo para buscar, ler e gravar diretamente no próprio arquivo do dispositivo, ignorando (e destruindo) o sistema de arquivos, mas espero evitar isso. Atualmente, estou usando o ext4 em um kernel 3.0 (Arch Linux, se for o caso), mas também estou interessado em técnicas para outros sistemas de arquivos.

— Rick Koshi
fonte

1

quem disse que os arquivos estão em um só lugar? Se ficarem fragmentados (o que geralmente fazem), podem acabar por todo o lado.

— Sirex

Absolutamente. Mas eles ainda estão em algum lugar :-) E, no meu caso particular, ao gravar arquivos em um sistema de arquivos recém-criado, é bem provável que eles sejam (principalmente) não fragmentados.

— Rick Koshi

Você não pode fazer isso. O melhor que você pode obter é o número de blocos LBA dos arquivos, que não correspondem necessariamente aos locais físicos especificados (pelo menos não da maneira que você pode determinar, pois as unidades não publicam esse mapeamento). Também há outras coisas, por exemplo, os blocos 3-5 podem ser numerados consecutivamente, mas 4 podem ter sido realocados para um local completamente diferente na unidade porque o setor original em 4 foi fisicamente danificado etc. Você não pode obter as informações você está procurando, a menos que o fabricante da unidade esteja disposto a fornecer especificações detalhadas de endereço.

— Jason C

7

Você pode usar debugfspara isso:

debugfs -R "stat ~/myfile" /dev/hda1

Altere a unidade de disco rígido / partição adequadamente e verifique se a unidade está desmontada. Você receberá uma lista com todos os blocos usados:

BLOCKS:
(0):1643532
TOTAL: 1

— Bart De Vos
fonte

1

Isso é perfeito, obrigado. Não sei por que você disse para garantir que a unidade esteja desmontada. De acordo com a página do manual, o debugfs é aberto no modo somente leitura por padrão, portanto, este comando deve ser completamente seguro, mesmo em um sistema de arquivos ativo. Pode fornecer resultados questionáveis se o arquivo consultado estiver sendo alterado ativamente no momento, é claro, mas nenhum outro problema deve resultar. Perdi alguma coisa?

— Rick Koshi

Não, você está certo. É mais uma "melhor prática" do que uma obrigação. Se você está fazendo isso em um sistema de arquivos ativo, os arquivos podem mudar etc.

— Bart De Vos

1

O número do bloco LBA não informa onde o arquivo está fisicamente localizado no disco. Atualmente, a conversão do LBA para a localização física geralmente não é possível, devido à complexidade da geometria física das unidades modernas, realocações do setor nos bastidores, etc. Em geral, geralmente é uma aposta segura que, para a mídia baseada em disco, os LBAs mais baixos estão voltados para fora da unidade, mas isso é apenas porque esse layout era típico no passado, nos dias de endereçamento do CHS. Os drives modernos nem publicam mais a geometria CHS real, porque não podem.

— Jason C

e quanto aos sistemas de gordura?

— dashesy

10

Você pode usar o FIBMAP ioctl , como exemplificado aqui , ou usando hdparm :

/ $ sudo /sbin/hdparm --fibmap /etc/X11/xorg.conf

/etc/X11/xorg.conf:
 filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0    1579088    1579095          8

— Francois G
fonte

Infelizmente, nada produzido pelo stat é a informação que eu preciso. Tamanho em bytes e blocos, número do inode, permissões ... Nenhum deles reflete quais blocos contêm os dados do arquivo. Como exemplo, meus arquivos de teste (todos do mesmo tamanho) mostram exatamente os mesmos dados, exceto o número do inode e os tempos de acesso / modificação.

— Rick Koshi

Sim, você está certo, desculpe, não li direito. Mudei minha resposta para stg mais apropriado.

— Francois G

O hdparm realmente me fornece o que eu preciso e em um formato um pouco mais legível que o debugfs. Eu tive que ir encontrá-lo, no entanto, uma vez que não está instalado (no Arch Linux) por padrão. debugfs faz parte do e2fsprogs (o mesmo pacote que nos fornece mkfs e fsck), portanto é instalado por padrão.

— Rick Koshi

O LBA não informa onde o arquivo está localizado fisicamente na unidade. Não é possível obter informações sobre o mapeamento físico real dos LBAs.

— Jason C

Eu recebo isso em gordura:HDIO_GETGEO failed: Inappropriate ioctl for device

— traço

5

Este tópico pode fornecer algumas dicas sobre o algoritmo de posicionamento de arquivos ext4.

debugfstem uma bmapfunção, que parece fornecer os dados que você deseja. Você deve conseguir blocos consecutivos de um arquivo e obter os números físicos dos blocos.

— Paweł Brodacki
fonte

1

Obrigado pelo ponteiro do tópico sobre o posicionamento do arquivo ext4. Isso foi esclarecedor. :-)

— Rick Koshi

O LBA não informa onde o arquivo está localizado fisicamente na unidade. Não é possível obter informações sobre o mapeamento físico real dos LBAs.

— Jason C

2

A pergunta é bastante antiga, mas há outra resposta que pode ser útil para quem encontra isso no Google: filefrag(no Debian está dentro do pacote e2fsprogs).

# filefrag -eX /usr/bin/aptitude
Filesystem type is: ef53
File size of /usr/bin/aptitude is 4261400 (1041 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..     1fa:    15bd805..   15bd9ff:    1fb:            
   1:      1fb..     3f2:    15c6608..   15c67ff:    1f8:    15bda00:
   2:      3f3..     410:    15c8680..   15c869d:     1e:    15c6800: last,eof
/usr/bin/aptitude: 3 extents found

Tem a vantagem de funcionar também para outros sistemas de arquivos (eu o usei para UDF), que não parecem ser suportados por outras ferramentas descritas aqui.

O deslocamento apresentado na saída deve ser múltiplo do tamanho do bloco escrito na segunda linha (4096 aqui). Cuidado: os desvios lógicos podem não ser contíguos, pois um arquivo pode ter falhas (quando suportado pelo sistema de arquivos).

— Giovanni Mascellani
fonte