Classer les fichiers par rôle et par propriétaire
Séparez les entrées nécessaires au traitement, les fichiers intermédiaires et les résultats à conserver. Les entrées peuvent provenir d’un dépôt ou d’une archive ; les fichiers temporaires peuvent être recréés ; les résultats demandent une destination durable. Ajoutez une quatrième famille : les états qui permettent de reprendre une exécution. Un point de reprise ne se confond ni avec les entrées originales ni avec le résultat final.
Pour chaque famille, nommez un propriétaire et une règle de conservation. Qui peut autoriser la suppression d’un cache ? Qui confirme qu’un résultat est exploitable ? Quel fichier manque si le travail s’arrête ? Inscrivez ces réponses dans la fiche projet, avec la destination retenue. Le catalogue décrit le GPU ; les capacités de disque, quotas et modalités de conservation doivent être vérifiés pour le périmètre réellement fourni.
Calculer le pic de stockage, pas seulement l’archive initiale
Évaluez le volume maximal pendant l’exécution. Des images décompressées, des copies de travail ou des versions successives peuvent occuper davantage que l’archive reçue. Le bon calcul additionne les éléments qui coexistent au même instant. Il ne faut ni additionner des phases exclusives, ni oublier qu’un export peut être préparé pendant que le traitement produit encore ses sorties.
Exemple fictif, avec des Go décimaux : une équipe conserve une archive de 180 Go pendant la préparation de 420 Go de fichiers décompressés. Elle prévoit 120 Go de temporaires, 60 Go de sorties et trois points de reprise de 24 Go. Si tout coexiste, le pic vaut 180 + 420 + 120 + 60 + 72 = 852 Go. Une marge interne choisie de 20 % porte le besoin à 1 022,4 Go. Cette hypothèse de projet n’est pas une capacité incluse dans une offre.
| Catégorie | Calcul | Volume |
|---|---|---|
| Archive d’entrée conservée | 1 × 180 Go | 180 Go |
| Entrées décompressées | 1 × 420 Go | 420 Go |
| Temporaires au pic | Hypothèse de travail | 120 Go |
| Sorties en préparation | Hypothèse de travail | 60 Go |
| Points de reprise | 3 × 24 Go | 72 Go |
| Total avant marge | Somme des cinq catégories | 852 Go |
Vérifier l’emplacement utilisable avant de lancer une série
Relevez l’espace disponible sur le système de fichiers qui accueillera réellement le projet, puis vérifiez les permissions d’écriture et la taille maximale attendue des fichiers. Avec de très nombreux petits fichiers, regardez aussi la disponibilité des inodes lorsque le système les utilise. GNU df distingue les blocs disponibles et les inodes : un indicateur de capacité en octets ne résume pas tous les motifs d’échec d’une création de fichier.
Si Linux et les outils GNU sont présents, les commandes ci-dessous permettent un relevé en lecture seule du répertoire courant. Notez l’heure et le chemin examinés. Ces relevés ne mesurent pas la vitesse du stockage et ne constituent pas une réservation d’espace ; des quotas supplémentaires peuvent également s’appliquer. Demandez leur périmètre avant de considérer la préparation terminée.
df -B1 --output=source,size,used,avail,pcent,target .
df -i .Organiser des noms et des états que l’équipe peut relire
Donnez aux sorties un nom qui identifie le lot et la version du traitement. Séparez les fichiers en cours des livrables contrôlés ; le dossier de livraison ne doit pas mélanger un résultat accepté et une copie partielle portant le même nom. Un registre peut associer identifiant du lot, version du code, emplacement et état de validation sans contenir les données elles-mêmes.
Pour les calculs longs, définissez les points de reprise que l’application sait produire et vérifiez leur lecture. Conservez les paramètres nécessaires avec l’état sauvegardé. Si un processus écrit encore dans un fichier pendant sa copie, ne considérez pas cette copie comme un état cohérent sans mécanisme prévu par l’application. Préférez une sauvegarde finalisée et identifiée, puis transmettez son nom à la personne qui prépare la suite.
Contrôler le transfert et l’usage du résultat séparément
Transférez un premier résultat vers sa destination finale avant la dernière journée. Comparez la liste des fichiers attendus et leurs tailles, puis les empreintes lorsque votre procédure en prévoit. Les outils SHA-2 de GNU calculent et vérifient des empreintes de fichiers. Un manifeste doit correspondre à des fichiers finalisés et être conservé avec une provenance connue ; il ne valide pas à lui seul la qualité métier du contenu.
Après le contrôle d’intégrité, ouvrez le résultat depuis sa destination avec l’application qui l’utilisera. Vérifiez le nombre d’éléments, le format et les dépendances externes. Une archive parfaitement copiée peut encore contenir un fichier manquant dès le départ. Le responsable de réception doit donc confirmer deux choses distinctes : la copie correspond au paquet attendu, et ce paquet sert bien à l’étape suivante.
sha256sum --check MANIFEST.sha256Décider de la conservation avant la fin de période
Dans l’exemple des 852 Go, supprimer l’archive de travail après confirmation d’une copie indépendante ferait descendre le besoin à 672 Go avant marge. Ce gain n’est valable que si la restauration de l’archive reste possible et si aucune étape suivante ne l’exige sur place. La décision appartient au propriétaire des données ; elle ne doit pas être improvisée par la personne qui constate un manque d’espace.
Les erreurs fréquentes sont de conserver toutes les versions sans limite, d’attendre la fin pour tester les permissions de destination et de compter une copie située au même endroit comme une solution de sortie. Fixez la liste à conserver, le responsable de l’export et son contrôle final. Sur 3, 7 ou 30 jours, la durée du calcul et celle de la récupération font partie du même planning.
Questions pour décider
Faut-il garder tous les fichiers temporaires ?
Pas nécessairement. Identifiez ceux que l’application peut reconstruire, puis comparez leur volume au coût et au temps de cette reconstruction. Gardez les éléments nécessaires à une reprise validée. La suppression d’un fichier encore utilisé ou d’un état indispensable doit être exclue de la règle de nettoyage.
Une empreinte correcte suffit-elle pour accepter un export ?
Elle vérifie la correspondance avec l’empreinte attendue. Il reste à vérifier que le manifeste couvre les bons fichiers et que le résultat s’ouvre avec ses dépendances. L’acceptation combine donc intégrité du paquet et contrôle fonctionnel depuis la destination.
La mémoire GPU peut-elle remplacer l’espace disque manquant ?
Non : la VRAM accueille les données utilisées par le calcul sur la carte. Elle ne remplace pas la destination des fichiers ni la conservation après la période de location. Décrivez séparément mémoire GPU, mémoire système et stockage dans votre dossier.