Les fichiers sont-ils enregistrés sur le disque de manière séquentielle?

22

Si j'ai bien compris, «fichier clairsemé» signifie que le fichier peut avoir des «lacunes», de sorte que les données réellement utilisées peuvent être plus petites que la taille du fichier logique.

Comment les systèmes de fichiers Linux enregistrent-ils les fichiers sur le disque? Je suis principalement intéressé par ext4. Mais:

Un fichier peut-il être enregistré non séquentiellement sur le disque? Par cela, je veux dire qu'une partie du fichier est située à l'adresse physique X et la partie suivante à l'adresse physique Y qui n'est pas proche de X + offset).
Puis-je en quelque sorte contrôler la séquentialité du fichier?
Je veux allouer un fichier de 10 Go. Je veux qu'il soit séquentiel sur le disque et non divisé entre différents décalages.
Agit-il différemment entre les différents types?

— hudac
source

Vous voudrez peut-être lire ext4.wiki.kernel.org/index.php/Main_Page

— roaima

1

Peut-être, si je comprends bien votre intention, vous seriez plus intéressé par l'API de niveau inférieur, où vous travaillez avec des périphériques de stockage sans avoir à passer par la couche système de fichiers. Votre point d'entrée pourrait alors être le dmsetupprogramme, une interface pour le mappeur de périphériques. Cela peut être un bon choix si vous prévoyez un stockage de type base de données.

— wvxvw

4

Il s'agit d'un détail d'implémentation du système de fichiers. Presque tous les systèmes de fichiers font fichiers fragment par défaut; seulement iso9660et romfssont incapables de le faire et nécessitent un stockage continu (parmi ceux-ci, je peux les énumérer séparément).

— mirabilos

2

que le fichier soit contigu sur le disque ou non, la lecture / écriture des données sera toujours contiguë à moins que vous ne cherchiez une autre partie du fichier. Alors pourquoi vous souciez-vous de cela? Sauf si la fragmentation est un problème grave qui affecte les performances

— phuclv

3

@hudac une chose à garder à l'esprit est que contiguë n'est pas si utile dans la pratique. Le plus simple est le flash où la fragmentation n'est pas un gros problème, mais sur un plateau tournant, vous ne pourrez toujours pas bénéficier de données contiguës. Sur un plateau tournant, vous devez réfléchir à vos modèles d'accès et à l'emplacement des données. Si vous avez besoin du secteur qui vient de passer sous la tête, vous devez attendre qu'il revienne complètement. Pour obtenir les meilleurs résultats, vous souhaitez échelonner les données afin qu'elles soient "proches" lorsqu'elles doivent être lues. Augmenter la taille du cache est plus facile ;-)

— Ukko

41

Un fichier peut-il être enregistré non séquentiellement sur le disque? Je veux dire, une partie du fichier est située sous l'adresse physique X et l'autre partie sous l'adresse physique Y qui n'est pas proche de X + offset).

Oui; ceci est connu sous le nom de fragmentation de fichiers et n'est pas rare, en particulier avec des fichiers plus volumineux. La plupart des systèmes de fichiers allouent l'espace selon les besoins, plus ou moins séquentiellement, mais ils ne peuvent pas deviner le comportement futur - donc si vous écrivez 200 Mo dans un fichier, puis ajoutez 100 Mo supplémentaires, il y a une chance non nulle que les deux ensembles de données être stocké dans différentes zones du disque (fondamentalement, toute autre écriture nécessitant plus d'espace sur le disque, survenant après la première écriture et avant la seconde, pourrait se trouver entre les deux). Si un système de fichiers est presque plein, la situation sera généralement pire: il peut ne pas y avoir de zone contiguë d'espace libre suffisamment grande pour contenir un nouveau fichier, il devra donc être fragmenté.

Puis-je en quelque sorte contrôler la séquence du fichier? Je veux allouer un gros fichier de 10 Go. Je veux qu'il soit séquentiel sur le disque et non divisé entre différents décalages.

Vous pouvez indiquer au système de fichiers la taille cible de votre fichier lors de sa création; cela aidera le système de fichiers à le stocker de manière optimale. De nombreux systèmes de fichiers modernes utilisent une technique connue sous le nom d'allocation différée, dans laquelle la disposition sur disque d'un nouveau fichier est calculée le plus tard possible, afin de maximiser les informations disponibles lorsque le calcul est effectué. Vous pouvez aider ce processus en utilisant la posix_fallocate(3)fonction pour indiquer au système de fichiers combien d'espace disque doit être alloué au total. Les systèmes de fichiers modernes essaieront d'effectuer cette allocation séquentiellement.

Agit-il différemment entre les différents types?

Les différents systèmes de fichiers se comportent différemment, oui. Les systèmes de fichiers basés sur les journaux tels que NILFS2 n'allouent pas de stockage de la même manière que les systèmes de fichiers basés sur les extensions tels que Ext4, et ce n'est qu'un exemple de variation.

— Stephen Kitt
source

1

Est-ce que l'utilisation fallocate(3)garantira la séquence des fichiers? ou fera simplement allusion au système de fichiers? Je ne peux pas le comprendre complètement à partir des pages de manuel.

— hudac

6

Il ne peut pas garantir une allocation séquentielle, c'est juste un indice. Mais vous devez absolument l'utiliser si vous écrivez des fichiers 10GiB!

— Stephen Kitt

6

Essentiellement, tous les systèmes de fichiers plus sophistiqués que FAT - cela remonte au Berkeley UFS d'origine - scindent intentionnellement les gros fichiers et les répartissent sur plusieurs "groupes d'allocation"; cela les aide à minimiser la fragmentation globale du disque. Il peut y avoir un moyen d'ajuster la façon dont cela fonctionne, mais il y a de bonnes chances que vous deviez recréer le système de fichiers à partir de zéro pour le faire, et il n'y a probablement pas de moyen de le désactiver complètement.

— zwol

2

@hudac Il est impossible de garantir la séquentialité dans tous les cas (voir le cas avec un lecteur qui est presque plein), et pour être honnête avec la montée en puissance des SSD, cela importe moins qu'auparavant (pour ceux qui peuvent se le permettre au moins ).

— Muzer

1

Notez également qu'il existe des situations, comme les systèmes RAID, où avoir des fichiers contigus est moins efficace, si c'est même possible. Je pense que c'est vraiment le but d'un contrôleur de sous-système de disque / stockage: décharger tout le travail de stockage des fichiers de manière optimale comme on peut raisonnablement s'y attendre.

— jamesqf

17

La commande filefragvous indiquera comment votre fichier est physiquement stocké sur votre appareil:

# filefrag -v /var/log/messages.1 
Filesystem type is: ef53
File size of /var/log/messages.1 is 41733 (11 blocks, blocksize 4096)
 ext logical physical expected length flags
   0       0  2130567               1 
   1       1 15907576  2130568      1 
   2       2 15910400 15907577      1 
   3       3 15902720 15910401      7 
   4      10  2838546 15902727      1 eof
/var/log/messages.1: 5 extents found

Si vous écrivez votre fichier en un seul passage, je suppose que votre fichier ne sera pas fragmenté.

La page de manuel de fallocate(1) est assez claire:

fallocate est utilisé pour préallouer des blocs à un fichier. Pour les systèmes de fichiers qui prennent en charge l' fallocateappel système, cela se fait rapidement en allouant des blocs et en les marquant comme non initialisés, ne nécessitant pas d'E / S sur les blocs de données. C'est beaucoup plus rapide que de créer un fichier en le remplissant de zéros.

Depuis Linux Kernel v2.6.31, l' fallocateappel système est pris en charge par les systèmes de fichiers btrfs, ext4, ocfs2 et xfs.

Est-ce séquentiel? Le système essaiera d'abord d'allouer les blocs de manière séquentielle. Si ce n'est pas le cas, cela ne vous avertira pas.

— Vouze
source

Quel est le type «ef53». Je l'ai également vu sur mes fichiers. Mais mon type FS est ext4.

— hudac

2

EF53 est le numéro "SUPER_MAGIC" d'ext2, d'ext3 et d'ext4. Regardez dans "include / uapi / linux / magic.h" dans les sources du noyau pour tous les nombres magiques de chaque système de fichiers.

— Vouze

Sur Debian, filefragest caché dans /usr/sbin. Mais cela semble fonctionner pour les utilisateurs ordinaires (sur ext4, au moins). Il peut être instructif pour straceson fonctionnement de voir comment mesurer la fragmentation par vous-même, si le manque d'avertissement vous gêne.

— Toby Speight

6

Vous mentionnez des fichiers rares et aucune des autres réponses ne les a mentionnés.

La plupart des fichiers ne sont pas rares. La façon la plus courante de créer un fichier est de tout écrire en une seule fois, du début à la fin. Pas de trous là-bas.

Cependant, vous êtes autorisé à dire «passer à la position 1 000 000 000 000 et y écrire un octet». Cela va créer un fichier qui ressemble à un gros etaoctet, mais qui n'utilise (probablement) que 4k sur le disque. Il s'agit d'un fichier clairsemé.

Vous pouvez le faire plusieurs fois pour le même fichier, laissant de petites quantités de données dispersées dans le vaste vide.

Bien que cela puisse être utile, il y a deux inconvénients.

La première est que le fichier sera fragmenté, ce qui vous inquiète.

La seconde est que tous les programmes ne gèrent pas bien ces fichiers. Par exemple, certains logiciels de sauvegarde essaieront de sauvegarder le vide et créeront ainsi une sauvegarde beaucoup plus importante que nécessaire, peut-être trop grande pour le support de sauvegarde.

— Stig Hemmer
source

Mais même un fichier non clairsemé ne sera souvent pas contigu sur le disque.

— Barmar

2

Puis-je en quelque sorte contrôler la séquentialité du fichier? Je veux allouer un fichier de 10 Go. Je veux qu'il soit séquentiel sur le disque et non divisé entre différents décalages.

Il existe au moins deux façons d'y parvenir.

Utilisez un système de fichiers avec beaucoup d'espace libre et préallouez l'espace (par exemple, utilisez un marqueur de fin de données spécifique à l'application et ajoutez des données aléatoires jusqu'à ce que la taille du fichier atteigne 10 Go). Cela ne garantit pas la création de données non fragmentées.
Utilisez un système de fichiers brut (non cuit) au lieu d'ext4 etc. Les SGBD le font parfois pour des raisons de performances. Le compromis est que vous devez faire votre propre mise en cache / journalisation / récupération, etc. si nécessaire.

Les cas où vous gagnez beaucoup en faisant cela sont relativement rares - je chercherais d'abord ailleurs pour optimiser les performances.

Voir également

Est-il vrai que les systèmes de gestion de bases de données contournent généralement les systèmes de fichiers?

— RedGrittyBrick
source

-1

Si ce n'est qu'une chose unique et que la façon dont le fichier est stocké à l'origine n'est pas importante, seul le résultat compte, alors vous pouvez simplement enregistrer le fichier normalement, puis exécuter le défragmenteur de votre système d'exploitation. Ensuite, vous pouvez vérifier avec cette réponse si votre fichier est en un seul morceau, sinon, répétez. C'est la façon la plus simple de le faire, sans utiliser de commandes ou de programmes externes, mais ce n'est certainement pas la méthode la plus rapide, car elle défragmente votre disque entier.

— Fabian Röling
source

1

"Exécutez le défragmenteur"? Existe-t-il un tel programme? La seule chose trouvée lors de ma recherche avec aptitude search ~ddefragétaient ddrescueviewet la nidsbibliothèque de réassemblage de segments TCP. Votre réponse n'est pas très utile si vous ne dites pas comment le programme est appelé ou quels arguments doivent être transmis.

— Toby Speight

1

@TobySpeight - oui, il y a un défragmenteur; e4defrag.

— ravery