Pourquoi le stockage des miniatures et du ML d’Immich augmente-t-il lors d’importations volumineuses depuis un mobile ?

Les importations volumineuses augmentent généralement l’espace de stockage d’Immich, car chaque élément génère des dérivés et des enregistrements dans la base de données, tandis que les modèles téléchargés occupent un cache distinct.

Une famille transfère des années de photos de téléphone vers un NAS domestique, puis constate que l’espace libre continue de diminuer une fois le compteur d’importation terminé. Cela peut refléter un traitement en arrière-plan légitime plutôt qu’une copie supplémentaire de chaque original. Il est utile de distinguer les fichiers générés pour chaque élément, les fichiers de modèles partagés et la croissance qui se poursuit sans augmentation correspondante du travail terminé.

Un téléversement crée plusieurs types d’état

L’original téléversé ne constitue qu’une partie de la bibliothèque obtenue. Immich prépare également des représentations plus petites pour la navigation et stocke les informations qui relient l’élément à son propriétaire, à ses dates, à ses albums et aux fonctions de recherche. Ces sorties répondent à des requêtes différentes : la fin du transfert réseau ne signifie donc pas que toutes les écritures en aval sont déjà terminées.

La distinction entre les fichiers multimédias et les enregistrements de la base de données est importante ici : les métadonnées de l’application et les représentations vectorielles de recherche résident dans PostgreSQL, plutôt que de constituer des photographies supplémentaires en pleine résolution. Le service d’apprentissage automatique calcule les résultats utilisés par l’application. Considérer tous les octets supplémentaires comme des originaux dupliqués donne donc une explication erronée de la croissance normale d’une importation.

Imaginons qu’un téléphone termine son transfert alors que le serveur traite encore le lot accepté. Les originaux peuvent déjà être stables sur le disque, tandis que les aperçus et les enregistrements interrogeables continuent d’apparaître. Comparez les mesures de stockage au même stade de traitement : un groupe immédiatement téléversé et un groupe entièrement traité ne sont pas des échantillons équivalents.

Le nombre d’éléments explique davantage que les gigaoctets d’originaux

Pour planifier les miniatures, le nombre et le type d’éléments expliquent souvent davantage que le volume total des originaux en gigaoctets. Un millier de petites photographies et quelques longues vidéos peuvent occuper une capacité source similaire, tout en nécessitant un nombre très différent de dérivés d’image. Les dimensions des aperçus, les paramètres de compression et le contenu des images modifient également le volume généré.

Des mesures de miniatures publiées illustrent cette variation : un propriétaire a indiqué 6,3 Go pour une bibliothèque de 70 Go, tandis qu’un autre a signalé environ 370 Go pour 2 To de photos et de vidéos. Il s’agit de configurations individuelles, et non de résultats comparables issus d’essais contrôlés. Elles montrent pourquoi l’adoption d’un pourcentage unique trouvé sur un forum peut donner une représentation trompeuse d’un autre foyer.

À titre d’exemple, 100 000 éléments produisant en moyenne 250 ko de dérivés d’image mesurés nécessitent environ 25 Go en unités décimales. À 500 ko par élément, le même nombre nécessite environ 50 Go. Aucun de ces chiffres n’inclut les originaux, les vidéos encodées, la croissance de la base de données ou les sauvegardes ; l’exemple isole la relation par élément plutôt que de recommander une provision universelle.

Les fichiers de modèles et les enregistrements de recherche évoluent différemment

Le cache de modèles contient des fichiers de modèles réutilisables, tandis que les vecteurs de recherche représentent des éléments individuels. Avec un ensemble fixe de modèles téléchargés, l’ajout de nouvelles photos ne nécessite pas de télécharger un modèle complet pour chaque image. L’ajout ou la modification de modèles peut en revanche augmenter le stockage du cache par paliers, indépendamment du nombre de photographies téléversées.

Un déploiement portable réel conserve la bibliothèque, le cache de modèles et les données PostgreSQL dans des répertoires persistants distincts. Cette séparation permet d’observer chaque rôle de stockage sans supposer qu’une taille Docker combinée représente la sortie de l’apprentissage automatique. Il s’agit d’un exemple de disposition issu d’une version ancienne, et non d’une procédure d’installation actuelle ni d’un ensemble recommandé d’étiquettes de conteneurs.

Distinguez également l’utilisation du disque de la mémoire chargée. Un modèle peut rester sur le disque alors que sa copie en mémoire est déchargée, et la mise en cache du système de fichiers peut augmenter la mémoire signalée sans créer davantage de fichiers persistants. Pour expliquer une hausse, identifiez le répertoire propriétaire et le paramètre modifié avant de tirer des conclusions à partir du nom d’un conteneur.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Quand la croissance normale cesse d’être une explication

La croissance normale des dérivés possède une entrée bornée : un groupe fixe d’originaux traité avec des paramètres fixes. Elle ne devrait pas créer une population infiniment croissante de nouveaux éléments sources. Si le nombre d’éléments continue d’augmenter après l’arrêt de toutes les importations prévues, l’explication doit inclure les chemins de découverte, une ingestion répétée ou une autre source de nouveau travail.

Un cas confirmé de balayage récursif incluait l’emplacement de téléversement d’Immich dans une bibliothèque externe. Les miniatures générées étaient alors considérées comme de nouvelles images, créant davantage de dérivés de dérivés. Il s’agit d’un mécanisme causal différent de celui d’une importation mobile volumineuse, et il ne faut pas s’en servir pour prouver que toute bibliothèque importante se multiplie naturellement sans limite.

Une croissance inhabituelle dans la couche inscriptible d’un conteneur constitue une autre catégorie distincte. Un rapport de 2026 décrivait l’accumulation de centaines de gigaoctets à cet endroit ; la discussion n’établissait pas de cause première universelle. Ne supprimez pas les fichiers de base de données, les médias ou les éléments internes de Docker pour rendre un graphique normal. Commencez par déterminer quel rôle croît et si le travail terminé l’explique.

Mesurez l’importation par rôle de stockage

Avant une importation représentative, relevez le nombre et le volume des éléments originaux, le volume des miniatures et des aperçus, le volume des vidéos encodées, la taille de la base de données, la taille du cache de modèles ainsi que toute croissance temporaire ou liée aux journaux. Répétez la mesure une fois que ce même groupe a terminé les tâches de traitement activées. Ne modifiez pas les paramètres multimédias afin que les différences puissent être attribuées à l’importation plutôt qu’à un changement de configuration simultané.

La comptabilisation du stockage ne remplace pas un plan de sauvegarde familial. Un service photo utilisable a besoin d’originaux protégés et de l’état de l’application nécessaire pour reconstruire la bibliothèque ; un simple répertoire de miniatures ne peut pas préserver la collection familiale. Gardez cette tâche de protection distincte de la mesure des surcoûts régénérables afin qu’une expérience d’économie d’espace ne devienne pas l’unique copie d’un souvenir.

Considérez le résultat comme cohérent lorsque les totaux mesurés par rôle expliquent les octets ajoutés et qu’aucun nouvel élément source inattendu ne continue d’apparaître. Recherchez un autre mécanisme lorsque l’inventaire des modèles reste inchangé mais que la croissance du cache ou de la couche inscriptible persiste, ou lorsque des fichiers dérivés réintègrent la découverte. Ce test explique pourquoi le stockage a augmenté sans transformer cette explication en procédure de nettoyage destructrice.