Pourquoi ces fichiers dans un volume ext4 sont-ils fragmentés?

J'ai une ext4partition de 900 Go sur un disque dur (magnétique) qui n'a aucun défaut et aucun mauvais secteur. La partition est complètement vide à l'exception d'un lost+foundrépertoire vide . La partition a été formatée en utilisant les paramètres par défaut, sauf que j'ai défini le nombre de blocs de système de fichiers réservés à 1%.

J'ai téléchargé le fichier ~ 900 Mo xubuntu-15.04-desktop-amd64.isodans le répertoire de point de montage de la partition à l'aide de wget. Une fois le téléchargement terminé, j'ai constaté que le fichier était divisé en quatre fragments:

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

Pensant que cela pourrait être rétabli d'une wgetmanière ou d'une autre, j'ai supprimé le fichier ISO de la partition, le rendant à nouveau vide, puis j'ai copié le fichier ~ 700 Mo v1.mp4sur la partition à l'aide cp. Ce fichier était également fragmenté. Il était divisé en trois fragments:

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

Pourquoi cela arrive-t-il? Et existe-t-il un moyen de l'empêcher de se produire? Je pensais que ext4c'était censé être résistant à la fragmentation. Au lieu de cela, je trouve qu'il fragmente immédiatement un fichier solitaire lorsque tout le reste du volume n'est pas utilisé. Cela semble être pire que les deux FAT32et NTFS.

3 ou 4 fragments dans un fichier de 900 Mo, c'est très bien. La fragmentation devient un problème lorsqu'un fichier de cette taille a plus de 100 fragments ou plus. Il n'est pas rare que fat ou ntfs fragmentent un tel fichier en plusieurs centaines de morceaux.

Vous ne verrez généralement pas mieux que cela au moins sur les anciens systèmes de fichiers ext4 car la taille maximale d'un groupe de blocs est de 128 Mo, et donc tous les 128 Mo, l'espace contigu est divisé par quelques blocs pour les bitmaps d'allocation et les tables d'inode pour le groupe de blocs suivant. Une fonctionnalité ext4 plus récente appelée flex_bg permet de regrouper un certain nombre (généralement 16) groupes de blocs pour ces tables, ce qui laisse des exécutions plus longues de blocs allouables mais en fonction de votre distribution et de la version d'e2fsprogs utilisée pour le formater, cette option peut n'ont pas été utilisés.

Vous pouvez utiliser tune2fs -lpour vérifier les fonctionnalités activées lorsque votre système de fichiers a été formaté.

Je ne peux pas vraiment répondre, mais je pense que cela pourrait aider:

Remarquez comment chaque fragment a une taille maximale de 32 768 blocs (une puissance de 2, ce qui devrait signaler que quelque chose se passe, et vous donner également un indice pour rechercher quelque chose).

Il convient également de noter que ces décalages physiques entre les extensions sont assez proches les uns des autres.

De: Disposition du disque Ext4

Un système de fichiers ext4 est divisé en une série de groupes de blocs. Pour réduire les difficultés de performances dues à la fragmentation, l'allocateur de blocs s'efforce de conserver les blocs de chaque fichier dans le même groupe, réduisant ainsi les temps de recherche. La taille d'un groupe de blocs est spécifiée dans sb.s_blocks_per_group blocks, bien qu'elle puisse également être calculée comme 8 * block_size_in_bytes. Avec la taille de bloc par défaut de 4 Ko, chaque groupe contiendra 32 768 blocs, pour une longueur de 128 Mo

Et plus bas:

Le premier outil qu'ext4 utilise pour lutter contre la fragmentation est l'allocateur multi-blocs. Lorsqu'un fichier est créé pour la première fois, l'allocateur de blocs alloue de façon spéculative 8 Ko d'espace disque au fichier [...] Une deuxième astuce connexe qu'ext4 utilise est l'allocation retardée. Dans ce schéma, lorsqu'un fichier a besoin de plus de blocs pour absorber les écritures de fichier, le système de fichiers diffère de décider de l'emplacement exact sur le disque jusqu'à ce que tous les tampons sales soient écrits sur le disque. En n'engageant pas sur un emplacement particulier jusqu'à ce qu'il soit absolument nécessaire (le délai de validation est atteint, ou sync () est appelé, ou le noyau manque de mémoire), l'espoir est que le système de fichiers puisse prendre de meilleures décisions d'emplacement.

Je dirais donc que l'allocateur ne se soucie que de la localisation des données au sein du groupe de blocs (ces 32K blocs), mais pas des groupes de blocs contigus les uns aux autres.