Linux EXT 4: Como listar arquivos que ocupam um grupo de blocos?

1

Linux EXT 4: Como listar arquivos que ocupam um grupo de blocos? Eu acredito que um arquivo pode abranger vários grupos de blocos. Dado um grupo de blocos, como eu enumero os caminhos de todos os arquivos contidos nele?

    
por Ram 13.09.2013 / 04:15

1 resposta

3

Com muita dificuldade. O pacote e2fsprogs tem os rudimentos de que você precisa, particularmente debugfs , que pode ser usado para percorrer o sistema de arquivos e observar o bloqueio grupos e alocações de arquivos. Aqui estão alguns trechos dos comandos stats e de extensão do debugfs:

debugfs:   stats
 Group  0: block bitmap at 64, inode bitmap at 80, inode table at 96
           28663 free blocks, 5777 free inodes, 3 used directories, 5777 unused inodes
           [Checksum 0xe713]
 Group  1: block bitmap at 65, inode bitmap at 81, inode table at 596
           0 free blocks, 8000 free inodes, 0 used directories, 8000 unused inodes
           [Inode not init, Checksum 0x9416]
 Group  2: block bitmap at 66, inode bitmap at 82, inode table at 1096
           0 free blocks, 8000 free inodes, 0 used directories, 8000 unused inodes
…
debugfs:  extents bigfile
Level Entries       Logical        Physical Length Flags
 0/ 1   1/  1     0 - 62499 120569           62500
 1/ 1   1/  6     0 - 12287 133120 - 145407  12288 
 1/ 1   2/  6 12288 - 12499 131524 - 131735    212 
 1/ 1   3/  6 12500 - 24575 145408 - 157483  12076 
 1/ 1   4/  6 24576 - 24999 131736 - 132159    424 
 1/ 1   5/  6 25000 - 30719 157484 - 163203   5720 
 1/ 1   6/  6 30720 - 62499 165888 - 197667  31780 

Assim, você pode reunir as informações desejadas, embora um roteiro do layout do disco ext4 seja disponibilizado a calhar.

Eu não posso deixar de me perguntar por que você pode querer rastejar por um sistema de arquivos dessa forma se você não precisa, mas talvez eu realmente não queira saber.

adicionado em resposta ao comentário :

Uma grande motivação de design para grupos de bloco é minimizar as penalidades de busca que você está tentando medir. Ou seja, o sistema de arquivos distribui os metadados de listas livres, tabelas de inodes e blocos de dados em grupos de blocos na unidade, de modo que a cabeça não precise pular de ponta a ponta tanto quanto poderia se houvesse apenas uma. grupo de bloco como com sistemas de arquivos FAT. Não sei se o NTFS faz o mesmo estilo FAT ou é mais inteligente como o BSD-FFS e seus descendentes ext.

Uma forma muito mais confiável de fazer a comparação que você procura seria por meio do particionamento de unidade. Se, por exemplo, você particionou uma unidade com partições externas, intermediárias e internas, você poderia forçar a busca copiando da partição externa para a interna. Se você tentar usar grupos de blocos para forçar isso, o sistema de arquivos "lutará" contra seus esforços porque foi desenvolvido para manter o acesso local à unidade.

Mesmo no caso de várias partições, você pode esperar que o cache de bloqueio de todo o sistema conspire com o driver de dispositivo para atrasar gravações em locais distantes usando truques como o algoritmo do elevador . Em suma, você está tentando quebrar uma grande pilha de otimização em todo o sistema, tudo projetado para minimizar o fenômeno exato que você está tentando medir. Você também pode descobrir que a eletrônica do controlador de unidade se envolve no jogo de redução de busca e muito disso ficará completamente oculto para você.

Você poderia abrir um dispositivo bruto e, através dos elementos certos, forçar o disco a fazer o tipo de escrita não otimizada que você está tentando fazer, mas esse experimento teria tão pouco a ver com o desempenho real que seria inútil. Se você está indo para esse problema, você pode apenas ler o tempo máximo de procura do fabricante da especificação do hardware e esquecer os testes. Ou você pode simplesmente executar o DOS.

segunda resposta aos comentários :

Seu teste de fseek provavelmente não mostrou nenhum efeito de busca de cabeça por causa do block-cache, que muitas vezes lerá mais do que você pede, na expectativa de que você irá pedir os seguintes bits em breve.

Para reiterar: vários pedaços do sistema são projetados para lutar contra seus esforços para impor uma penalidade de busca em você. Neste ponto, eu perguntaria se seu interesse é teórico ou prático. Se teórico, acho que você tem sua resposta. Se for prático, você está empacado em criar um teste que, por definição, não seja representativo da carga real.

Qual é a pergunta para a qual você está realmente buscando uma resposta? Por favor, abra uma nova pergunta; isso já ficou superlotado.

    
por 13.09.2013 / 04:58

Tags