Inconvénients de la création / suppression de nombreux liens physiques?

Question

J'ai besoin de créer des centaines à des milliers de liens physiques ou symboliques temporaires qui seront supprimés peu de temps après leur création. Pour mes besoins, les deux types de liens fonctionneront (c'est-à-dire que la cible n'est pas un répertoire et qu'elle existe toujours sur le même système de fichiers)

Si je comprends bien, les liens symboliques créent un petit fichier contenant le chemin d'accès au fichier d'origine. Alors qu'un lien physique crée une référence aux données dans le même inode. Alors peut-être que si je vais créer / supprimer des milliers de ces liens, est-il préférable de créer et de supprimer des milliers de petits fichiers (liens symboliques) ou des milliers de ces références (liens physiques)? Il semble que l'un taxe le disque dur (peut-être la fragmentation) tandis que l'autre pourrait taxer le système de fichiers lui-même? Où sont stockées les références d'inœuds. Est-ce que je risque de corrompre le système de fichiers en créant autant de liens physiques? Et la vitesse?

Merci pour votre expertise!

C'est une solution pour pouvoir utiliser ffmpeg pour encoder un film à partir d'un sous-ensemble arbitraire d'images d'un répertoire. Puisque ffmpeg nécessite que les fichiers soient nommés correctement (par exemple frame% 04d.jpg), j'ai réalisé que je pouvais simplement créer des liens physiques / symétriques vers le sous-ensemble de fichiers et nommer les liens de manière appropriée. Cela évite de renommer les fichiers d'origine et d'avoir à copier réellement les données. Cela fonctionne très bien, mais cela nécessite la création et la suppression de plusieurs milliers de liens, à plusieurs reprises.

Une sorte de solution à ce problème aussi, je crois: convertir une séquence d'images à l'aide de ffmpeg

Answer 1

Si cette activité casse votre système de fichiers, c'est que votre système de fichiers est en faute, pas vous.Les systèmes de fichiers sont généralement assez fiables, alors ne vous inquiétez pas pour cela.

Les deux options nécessitent l'ajout d'une entrée dans le répertoire.Le lien symbolique nécessite également la création d'un fichier.Lorsque vous accédez au fichier, le lien physique passe directement au contenu, tandis que l'accès à un lien symbolique nécessite de trouver le fichier de lien symbolique, de le lire, de trouver le répertoire avec le contenu, de trouver où se trouve le contenu, puis d'y accéder.Par conséquent, les liens symboliques sont plus de travail pour le système de fichiers tout autour.

Mais la différence est infime par rapport au travail de lecture des données dans les fichiers.Par conséquent, je ne m'inquiéterais pas à ce sujet, et je choisirais simplement celui qui vous donne le mieux la sémantique que vous voulez.

Answer 2

Puisque vous n'essayez pas de créer des centaines de milliers dans le même fichier, les liens physiques sont légèrement plus performants.

Cependant, les liens symboliques dans / tmp si / tmp est tmpfs sont encore plus performants.

Oh, et les liens symboliques sont trop petits pour causer des problèmes de fragmentation.

Answer 3

Les deux options nécessitent l'ajout d'une entrée de fichier dans l'inode du répertoire, la structure du répertoire peut s'agrandir en allouant de nouveaux blocs.

Mais un lien symbolique nécessite l'allocation d'un inode et le système de fichiers a une limite pour les inodes. Vos liens symboliques centaines de milliers peuvent atteindre cette limite et vous pouvez recevoir le message d'erreur Espace insuffisant pour le fichier même avec des gigaoctets libres.

Par défaut, l'outil de création de système de fichiers choisit le nombre maximum d'inodes en fonction de la taille de la partition physique. Par exemple pour Linux ext2 / 3/4, mkfs.ext3 utilise un ratio bytes-per-inode que vous pouvez trouver dans votre /etc/mke2fs.conf.

Pour un système de fichiers existant, voici une commande pour obtenir des informations sur les inodes:

# dumpe2fs /dev/sda1 | grep -i inode | less

Inode count:              979200
Free inodes:              742304
Inodes per group:         16320
Inode blocks per group:   510
First inode:              11
Inode size:               128
Journal inode:            8
First orphan inode:       441066
Journal backup:           inode blocks

En conclusion, vous devriez préférer les liens durs principalement pour la consommation de ressources sur disque et en mémoire (structures VFS dans les caches).

Autre conseil: ne créez pas trop de fichiers dans le même répertoire, 2'000 fichiers est une limite raisonnable pour éviter les problèmes de performances.