Gzip est-il atomique?

11

Est gzipatomique?

Que se passe-t-il si j'arrête le gzipprocessus 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 *.txtprocessus, comment puis-je reprendre en toute sécurité?

(Je ne suis pas seulement curieux de savoir comment reprendre, mais aussi de savoir s'il gzipest spécifiquement atomique.)

command-line gzip

— Vendetta
source

Copie possible de Comment reprendre une commande tar qui a été tuée

— Anthony Geoghegan

4

"comment puis-je reprendre en toute sécurité?" _... Utilisez à la CTRL+Zplace de CTRL+C, puis tuez ou reprenez le travail interrompu (il répond par un nombre n[- [n]+ Stopped-- gzip ...] puis vous pouvez reprendre avec %nou avec fg, ou avec bg... de la même manière vous pouvez le tuer avec kill %n).

— Hastur

Compressez un gros fichier, Ctrl-C pendant la compression, et voyez ce qui se passe.

— RonJohn

Non. Seul mv est atomique, sauf sur ext4… le sarcasme dégoulinant, mais au moins ils ont corrigé les options de montage par défaut il y a quelque temps.

— mirabilos

28

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 situ 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 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 gzipprocessus avec un signal capturable ( SIGINTde 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.

— roaima
source

5

le 2e se produit lorsque le processus est terminé , pas lorsqu'il est arrêté , et ne se produit que pour les signaux non traités (pas pour ^ C -> SIGINTou SIGTERMpour lesquels gzipinstalle des gestionnaires de signaux qui suppriment le fichier de sortie).

— mosvy

1

@mosvy donc c'est le cas. Je n'avais jamais vu ça auparavant. Merci

— roaima

1

Vous prenez grand soin de vous assurer de ne supprimer aucun fichier compressé pour lequel l'original a été supprimé. Lorsque gzip est tué de manière irrégulière, il s'agit généralement d'un fichier, généralement le dernier.

— Harper - Rétablir Monica du

@Harper oui. Si vous arrêtez le gzipflux moyen, il y a toujours une petite condition de course. Alternativement, vous pouvez gziptoujours indiquer de remplacer les fichiers cibles, ce qui évite la plupart des problèmes de nettoyage.

— roaima

15

Ce n'est pas atomique (l'API du système de fichiers Unix ne fournit vraiment aucun moyen d'effectuer des opérations atomiques qui affectent plusieurs fichiers), mais il est à sécurité intégrée. Le fichier compressé est un nouveau fichier, il n'écrase pas l'original et il 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.

— Barmar
source

Cela me fait penser à la façon dont les opérations multifichiers atomiques pourraient être implémentées. Quelque chose comme les transactions SQL?

— val dit Réintégrer Monica

1

@val Il y a environ 30 ans, je faisais partie d'une équipe qui concevait un nouveau système d'exploitation en tant que suite Multics / GCOS, et un système de fichiers de type base de données faisait partie de l'idée. Le projet n'est cependant jamais allé très loin.

— Barmar

Ils ont supprimé les transactions NTFS, ne semble pas valoir la complication. Renommer est l'opération la plus atomique (tant que vous êtes sur le même système de fichiers et qu'il a une sémantique posix), donc avoir un renommage (après close / fsync) de temp en nom final garantirait que le fichier non compressé est au moins complet. Vous pouvez contourner ces problèmes avec l'utilisation de tuyaux (qui ont leurs propres modes de défaillance partielle)

— eckes

@eckes Tant qu'il supprime l'original après avoir fermé le fichier compressé, vous n'avez pas besoin du renommage atomique. Si l'original a disparu, vous pouvez être sûr que le fichier compressé est complet. Vous avez besoin d'un renommage atomique pour les opérations qui remplacent le fichier d'origine (par exemple sed -i).

— Barmar

@Barmar si vous ne souhaitez déclencher que par l'existence du fichier cible (ce que font de nombreux workflows d'interrogation de répertoire), vous devez être sûr que le fichier est complet. Si vous ne déclenchez pas cela ou pouvez détecter des fichiers incomplets en vérifiant l'existence de la source, alors tout va bien sans le renommage final.

— Eckes

4

Vous n'avez pas à vous en préoccuper car gzipcrée un nouveau .gzfichier, 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.

— dr_
source

3

.txtles fichiers déjà traités avec succès par gzipont été remplacés par .txt.gzdes fichiers compressés, vous pouvez donc réexécuter en toute sécurité gzip *.txt- 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 qu'après une compression réussie.

— cas
source

0

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 .txt.gzfichier inachevé et inachevé juste à côté du .txtfichier. 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 incomplet / corrompu .txt.gz? Ou
un gunzip qui a échoué, laissant un .txtfichier incomplet / tronqué ? Ou
Un fichier compressé avec succès 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 y 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 ...

— Harper - Rétablir Monica
source

1

@roaima. Nous le faisons en effet, je comptais sur un argot signifiant que nous utilisions il y a longtemps à un endroit où je travaillais. Correction de la définition commune.

— Harper - Rétablir Monica

1

Si vous allez voter contre, veuillez laisser un commentaire expliquant pourquoi.

— JBentley