Como alterar o tamanho da extensão no sistema de arquivos ext4?

5

Como você pode ler aqui , o sistema de arquivos ext4 possui um recurso de extensão que agrupa blocos em extensões. Cada um deles pode ter até 128 MB de espaço contíguo. Em e4defrag , existem linhas semelhantes às seguintes:

[325842/327069]/file:  100%  extents: 100 -> 10   [ OK ]

O tamanho do arquivo é de cerca de 150 MiB. Então, de acordo com a página wiki, deve haver 2 extensões em vez de 10.

  1. Alguém sabe por que as extensões são 15MiB em vez de 128MiB?
  2. Existe uma ferramenta que pode verificar o tamanho exato da extensão?
  3. Como posso alterar o tamanho para que possa ser de 128 MB?
por Mikhail Morfikov 09.07.2015 / 15:29

2 respostas

1

Eu acho que sei como funciona.

Eu conectei outro disco à minha máquina porque ele tem uma grande partição quase vazia ~ 458G. Eu verifiquei seu espaço livre via e2freefrag :

HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range :  Free extents   Free Blocks  Percent
   64M...  128M-  :             6        146233    0.12%
  128M...  256M-  :             5        322555    0.27%
  256M...  512M-  :             3        263897    0.22%
  512M... 1024M-  :             6       1159100    0.98%
    1G...    2G-  :           228     116312183   98.40%

São apenas blocos livres contíguos. Então, como a partição está quase vazia, há muito espaço livre e você tem 228 blocos de 1-2G.

Eu coloquei um grande arquivo 2,5G dentro da partição, e a tabela acima mudou um pouco:

HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range :  Free extents   Free Blocks  Percent
    2M...    4M-  :             5          5114    0.00%
   64M...  128M-  :             7        170777    0.14%
  128M...  256M-  :             1         64511    0.05%
  256M...  512M-  :             4        361579    0.31%
  512M... 1024M-  :             5        930749    0.79%
    1G...    2G-  :           227     116025495   98.16%

Isso não diz nada sobre as extensões do bloco alocado, mas me deu algumas idéias. Quando eu olhei para o arquivo em e4defrag , havia algo assim:

# e4defrag -cv file
<File>
[ext 1]:        start 34816:    logical 0:      len 32768
[ext 2]:        start 67584:    logical 32768:  len 30720
[ext 3]:        start 100352:   logical 63488:  len 32768
[ext 4]:        start 133120:   logical 96256:  len 30720
[ext 5]:        start 165888:   logical 126976: len 32768
[ext 6]:        start 198656:   logical 159744: len 30720
[ext 7]:        start 231424:   logical 190464: len 32768
[ext 8]:        start 264192:   logical 223232: len 30720
[ext 9]:        start 296960:   logical 253952: len 32768
[ext 10]:       start 329728:   logical 286720: len 32768
[ext 11]:       start 362496:   logical 319488: len 32768
[ext 12]:       start 395264:   logical 352256: len 32768
[ext 13]:       start 428032:   logical 385024: len 32768
[ext 14]:       start 460800:   logical 417792: len 32768
[ext 15]:       start 493568:   logical 450560: len 30720
[ext 16]:       start 557056:   logical 481280: len 32768
[ext 17]:       start 589824:   logical 514048: len 32768
[ext 18]:       start 622592:   logical 546816: len 32768
[ext 19]:       start 655360:   logical 579584: len 32768
[ext 20]:       start 688128:   logical 612352: len 32768
[ext 21]:       start 720896:   logical 645120: len 622

O número 32768 significa blocos (4K), o que equivale a 128 MiB. Alguns deles têm menos blocos e eu não sei porque o sistema de arquivos está vazio e acho que todas as extensões devem ter 32768 blocos.

De qualquer forma, verifiquei a partição principal para ver seu espaço livre e havia algo assim:

HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range :  Free extents   Free Blocks  Percent
    4K...    8K-  :          3955          3955    0.06%
    8K...   16K-  :          3495          8194    0.13%
   16K...   32K-  :          2601         13165    0.20%
   32K...   64K-  :          2622         28991    0.45%
   64K...  128K-  :          2565         58267    0.90%
  128K...  256K-  :          1576         71371    1.11%
  256K...  512K-  :          1331        118346    1.83%
  512K... 1024K-  :          1058        190532    2.95%
    1M...    2M-  :          1202        444210    6.89%
    2M...    4M-  :          1211        884489   13.71%
    4M...    8M-  :          1249       1803998   27.97%
    8M...   16M-  :           622       1643226   25.48%
   16M...   32M-  :           198       1024999   15.89%
   32M...   64M-  :            16        163082    2.53%

Como você pode ver, não há blocos contíguos livres que possam fornecer 128 MB (e mais) de espaço, e é por isso que eles escreveram no wiki que você pode ter extensões de "até 128M".

Não sei por que o arquivo em questão tem 10 extensões porque ainda há 16 blocos com pelo menos 32 milhões.

    
por 10.07.2015 / 11:14
0

Acho que sua pergunta é baseada em uma premissa incorreta.

Basicamente ... suas extensões são 128 MB de tamanho, no entanto o e4defrag pegou o arquivo, copiou seus dados, descobriu que a cópia tinha 5 extensões ao invés de 10 extensões e assim chamou isso de " sucesso "e apontou o inode nos dados copiados e liberou os dados originais. Se isso acontecer, imprime "10 - > 5".

(Agora, também é possível que os dados copiados possam ter mais extensões, caso em que exclui a cópia e deixa as coisas como estão, e imprime "10 - > 10 ".)

Quanto mais cheio for o seu disco, menos provável é que o e4defrag reduza um arquivo para o número "mínimo" de extensões que pode ser calculado com base em seu tamanho.

Mas não espere que o e4defrag desfragmente seu disco com perfeição - ele meio que faz uma tentativa preguiçosa, uma tentativa por arquivo (por arquivo que tenha mais de uma extensão, isto é - se já tiver apenas um extensão (ou o mínimo possível eu acho) ele rapidamente pula) e se essa tentativa não resultar em algum tipo de melhoria, ela simplesmente deixa as coisas como estão, e mesmo que haja melhorias, não é garantido que seja o número mínimo de extensões possíveis. Re-running e4defrag pode acabar com alguma melhoria após a primeira execução, especialmente se algum espaço a mais tiver sido liberado desde a execução anterior, mas execuções subseqüentes após a primeira provavelmente correrão muito rapidamente em retornos decrescentes.

    
por 26.02.2018 / 23:49