Por que esses arquivos em um volume ext4 são fragmentados?

Question

Eu tenho uma partiçãoext4 de 900 GB% em um disco rígido (magnético) que não tem defeitos nem setores defeituosos. A partição está completamente vazia, exceto por um diretório lost+found vazio. A partição foi formatada usando os parâmetros padrão, exceto que eu configurei o número de blocos reservados do sistema de arquivos para 1%.

Eu baixei o arquivo ~ 900MB xubuntu-15.04-desktop-amd64.iso para o diretório do ponto de montagem da partição usando wget . Quando o download foi concluído, descobri que o arquivo foi dividido em quatro fragmentos:

filefrag -v /media/emma/red/xubuntu-15.04-desktop-amd64.iso
Filesystem type is: ef53
File size of /media/emma/red/xubuntu-15.04-desktop-amd64.iso is 1009778688 (246528 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   32767:      34816..     67583:  32768:            
   1:    32768..   63487:      67584..     98303:  30720:            
   2:    63488..   96255:     100352..    133119:  32768:      98304:
   3:    96256..  126975:     133120..    163839:  30720:            
   4:   126976..  159743:     165888..    198655:  32768:     163840:
   5:   159744..  190463:     198656..    229375:  30720:            
   6:   190464..  223231:     231424..    264191:  32768:     229376:
   7:   223232..  246527:     264192..    287487:  23296:             eof
/media/emma/red/xubuntu-15.04-desktop-amd64.iso: 4 extents found

Pensando que isso pode ser relegado a wget de alguma forma, eu removi o arquivo ISO da partição, deixando-o vazio novamente, então copiei o arquivo ~ 700MB v1.mp4 para a partição usando cp . Este arquivo também foi fragmentado. Foi dividido em três fragmentos:

filefrag -v /media/emma/red/v1.mp4
Filesystem type is: ef53
File size of /media/emma/red/v1.mp4 is 737904458 (180153 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   32767:      34816..     67583:  32768:            
   1:    32768..   63487:      67584..     98303:  30720:            
   2:    63488..   96255:     100352..    133119:  32768:      98304:
   3:    96256..  126975:     133120..    163839:  30720:            
   4:   126976..  159743:     165888..    198655:  32768:     163840:
   5:   159744..  180152:     198656..    219064:  20409:             eof
/media/emma/red/v1.mp4: 3 extents found

Por que isso está acontecendo? E existe uma maneira de evitar que isso aconteça? Eu pensei que ext4 deveria ser resistente à fragmentação. Em vez disso, descobri que ele fragmenta imediatamente um arquivo solitário quando todo o restante do volume não é utilizado. Isso parece ser pior do que os dois FAT32 e NTFS .

    

Answer 1

3 ou 4 fragmentos em um arquivo de 900mb é muito bom. A fragmentação se torna um problema quando um arquivo desse tamanho tem mais de 100 fragmentos. Não é incomum que a gordura ou NTFS fragmentem esse arquivo em centenas de pedaços.

Você geralmente não verá melhor do que isso pelo menos em sistemas de arquivos ext4 mais antigos porque o tamanho máximo de um grupo de blocos é de 128 MB e, portanto, a cada 128 MB o espaço contíguo é quebrado por alguns blocos para os bitmaps e inode de alocação tabelas para o próximo grupo de blocos. Um recurso ext4 mais recente chamado flex_bg permite agrupar um número de grupos (geralmente 16) de grupos de blocos, deixando execuções mais longas de blocos alocáveis, mas dependendo de sua distribuição e qual versão de e2fsprogs foi usada para formatá-lo, esta opção pode não ter sido usada.

Você pode usar tune2fs -l para verificar os recursos ativados quando o seu sistema de arquivos foi formatado.

    

Answer 2

Eu não posso responder de verdade, mas acho que isso pode ajudar:

Observe como cada fragmento tem, no máximo, 32768 blocos de tamanho (um poder de 2, que deve levantar uma bandeira de que algo está acontecendo e também dar a você uma dica para procurar algo).

Também vale a pena notar que as compensações físicas entre as extensões são muito próximas uma da outra.

De: Layout de disco Ext4

An ext4 file system is split into a series of block groups. To reduce performance difficulties due to fragmentation, the block allocator tries very hard to keep each file's blocks within the same group, thereby reducing seek times. The size of a block group is specified in sb.s_blocks_per_group blocks, though it can also calculated as 8 * block_size_in_bytes. With the default block size of 4KiB, each group will contain 32,768 blocks, for a length of 128MiB

E mais abaixo:

The first tool that ext4 uses to combat fragmentation is the multi-block allocator. When a file is first created, the block allocator speculatively allocates 8KiB of disk space to the file [...] A second related trick that ext4 uses is delayed allocation. Under this scheme, when a file needs more blocks to absorb file writes, the filesystem defers deciding the exact placement on the disk until all the dirty buffers are being written out to disk. By not committing to a particular placement until it's absolutely necessary (the commit timeout is hit, or sync() is called, or the kernel runs out of memory), the hope is that the filesystem can make better location decisions.

Então eu diria que o alocador só se importa sobre a localidade dos dados dentro do grupo de blocos (aqueles 32K blocos), mas não sobre os grupos de blocos serem contíguos uns aos outros.