Gzip est-il atomique?
gzip est-il atomique?
Que se passe-t-il si j'arrête le processus gzip alors qu'il est en train de compresser un fichier?
Si ce n'est pas atomique, et si j'ai déjà appuyé sur Ctrl + C sur un gzip *.txt processus, comment reprendre en toute sécurité?
(Je ne suis pas seulement curieux de savoir comment reprendre, mais aussi si gzip est spécifiquement atomique.)
Gzip est-il atomique?
Non. Il crée un fichier compressé puis supprime l'original non compressé.
Plus précisément, il ne compresse pas un fichier in sit et il y a une période de temps pendant laquelle le fichier est compressé où,
- la cible compressée est incomplète
- le fichier partiellement compressé et sa source existent tous les deux dans le système de fichiers.
Que se passe-t-il si j'arrête le processus gzip alors qu'il est en train de compresser un fichier gzip?
Si vous arrêtez le processus gzip avec un signal capturable (SIGINT de Ctrl C, par exemple), il nettoiera les fichiers partiellement créés. Sinon, selon le point où il est arrêté, vous pouvez vous retrouver avec un fichier partiellement compressé à côté de l'original intact.
Si ce n'est pas atomique, si j'ai déjà appuyé sur Ctrl + C sur un processus gzip * .txt, comment puis-je reprendre en toute sécurité?
Vous supprimez la version partiellement compressée (si elle existe toujours) et redémarrez le gzip.
Ce n'est pas atomique (l'API du système de fichiers Unix ne fournit pas vraiment de moyen d'effectuer des opérations atomiques qui affectent plusieurs fichiers), mais is fail-safe. Le fichier compressé est un nouveau fichier, il n'écrase pas l'original et ne supprime pas le fichier d'origine tant qu'il n'a pas terminé de créer le fichier compressé (cela peut en fait provoquer un problème si vous n'avez pas assez d'espace disque pour les deux fichiers).
S'il obtient une erreur ou si vous interrompez la compression, le fichier d'origine restera inchangé. Le fichier compressé partiel sera généralement supprimé.
Il n'y a aucun moyen de le reprendre au milieu, vous recommencez tout simplement depuis le début.
Vous n'avez pas à vous en préoccuper car gzip crée un nouveau .gz fichier, le remplit avec le contenu compressé, puis supprime le fichier d'origine. Donc, si vous arrêtez le processus au milieu, cela n'affectera pas votre fichier d'origine.
.txt les fichiers déjà traités avec succès par gzip auront été remplacés par .txt.gz fichiers compressés, vous pouvez donc exécuter en toute sécurité gzip *.txt encore - seuls les fichiers qui n'ont pas encore été traités seront compressés.
Le fichier qui était en cours de traitement par gzip au moment où vous avez appuyé sur Ctrl-C ne sera pas modifié - gzip ne le remplacera que après avec succès la compression.
Non, c'est très anatomique. Cela peut vous causer de gros problèmes si vous compressez un fichier qui est parfois ajouté, comme un journal Web.
Gzip lit, crée le fichier .gz (avec l'horodatage actuel), copie l'horodatage du fichier d'origine, puis supprime l'original.
Certaines interruptions peuvent laisser un fichier .txt.gz Errant et inachevé juste à côté du fichier .txt. Cela crée alors un problème d'intégrité des données: quel est le vrai fichier? Est-ce
- un gzip qui a échoué, laissant un
.txt.gzincomplet/corrompu? Ou - un gunzip qui a échoué, laissant un fichier
.txtincomplet/tronqué? Ou - Un fichier compressé avec succès dans
txt.gz, Et un fichier nouvellement créé.txt?
(Ce dernier se produit lorsque vous allez dans votre répertoire de journaux HTTP et que vous allez gzip *).
Je trouve généralement qu'il est prudent de régler cela à la main, à moins que vous ne sachiez exactement ce qui s'est passé parce que vous venez de le faire.
Heureusement, gzip fonctionne généralement en série, vous ne devriez donc avoir ce problème qu'avec un seul fichier. La mise en parallèle de gzip n'est pas une bonne idée - même si elle utilisera le processeur plus complètement, elle écrasera le disque, le forçant à lire plusieurs fichiers à la fois, ralentissant considérablement tous les gzip. SSD ou RAMdisk, d'autre part ...