CRYPTO SANS KYCLocation GPU · 3, 7 ou 30 jours
CapordiaEspace client
Menu
Exploitation / Données

Prévoir les données qui restent.

Une période de calcul commence par des données disponibles et se termine par des résultats récupérables. Préparez ces deux mouvements avec autant de soin que le choix du GPU : volume maximal, emplacements, contrôles et responsabilité de la récupération doivent être connus avant la campagne.

01

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.

02

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.

Budget fictif au moment où toutes les catégories coexistent
CatégorieCalculVolume
Archive d’entrée conservée1 × 180 Go180 Go
Entrées décompressées1 × 420 Go420 Go
Temporaires au picHypothèse de travail120 Go
Sorties en préparationHypothèse de travail60 Go
Points de reprise3 × 24 Go72 Go
Total avant margeSomme des cinq catégories852 Go
03

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.

Exemple de relevé GNU en lecture seule, à adapter au répertoire de travail
df -B1 --output=source,size,used,avail,pcent,target .
df -i .
04

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.

05

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.

Exemple : vérifier un manifeste SHA-256 déjà préparé pour les fichiers reçus
sha256sum --check MANIFEST.sha256
06

Dé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.

POURSUIVRE LE DOSSIERExaminer les configurationsConsulter les questions fréquentes