Que se passe-t-il lorsque je tue 'cp'? Est-ce sûr et a-t-il des conséquences?

Quelles sont les conséquences pour un système de fichiers ext4 lorsque je termine une cpcommande de copie en tapant Ctrl+ Cpendant son exécution?

Le système de fichiers est-il corrompu? L'espace de la partition occupé par le fichier copié incomplet est-il toujours utilisable après sa suppression?

Et, plus important encore, mettre fin à un cpprocessus est-il une chose sûre à faire?

— Seninha
source

Gardez à l'esprit que même si les réponses sont correctes pour ext4, les systèmes de fichiers sans journalisation peuvent ne pas être aussi sûrs.

— Ave

@Ave Journaling n'a rien à voir avec cela. Les appels système sont atomiques quel que soit le système de fichiers que vous utilisez. La journalisation est utile dans les situations où l'alimentation peut être brusquement perdue.

— forêt le

Réponses:

C'est sûr à faire, mais naturellement vous n'avez peut-être pas terminé la copie.

Lorsque la cpcommande est exécutée, elle effectue des appels système qui demandent au noyau de faire des copies du fichier. Un syscall est une fonction qu'une application peut appeler et qui demande un service au noyau, comme lire ou écrire des données sur le disque. Le processus de l'espace utilisateur attend simplement la fin de l'appel système. Si vous deviez suivre les appels, cela ressemblerait à quelque chose comme:

open("/home/user/hello.txt", O_RDONLY)           = 3
open("/mnt/hello.txt", O_CREAT|O_WRONLY, 0644)   = 4
read(3, "Hello, world!\n", 131072)               = 14
write(4, "Hello, world!\n", 14)                  = 14
close(3)                                         = 0
close(4)                                         = 0

Cela se répète pour chaque fichier à copier. Aucune corruption ne se produira en raison du fonctionnement de ces appels système. Lorsque syscalls comme ceux - ci sont entrés, le signal fatal prendra effet qu'après l'syscall a fini , pas en cours d' exécution. Pour cette raison, la suppression forcée du processus entraînera sa fin uniquement après la fin de l'appel système en cours d'exécution. Cela signifie que le noyau, où réside le pilote du système de fichiers, est libre de terminer les opérations qu'il doit effectuer pour mettre le système de fichiers dans un état sain. Aucune E / S de ce type ne se terminera jamais au milieu de l'opération, ce qui en fera des opérations atomiques.

Fait intéressant, c'est pourquoi des commandes comme cppeuvent ne pas se terminer immédiatement lorsqu'elles sont tuées. Si vous copiez un très gros fichier et le tuez, même avec SIGKILL, le processus se poursuivra jusqu'à la fin de l'appel système actuel. Avec un fichier volumineux, cela peut prendre un certain temps, car le processus sera dans un état ininterrompu.

— forêt
source

@qwr C'est probablement une partie de la bibliothèque glibc, pas cpelle-même. Il dispose de diverses fonctions d'accès aux fichiers qui l'utilisent en interne comme valeur.

— forêt le

Très bonne réponse! Je n'avais jamais réalisé qu'il y avait un retard à terminer un cpaprès SIGKILLing, même en traitant de gros fichiers ... peut-être que la durée de ces opérations atomiques ininterrompues d'un processus est trop courte. La même explication fonctionne-t-elle pour la destruction ddet d'autres processus de lecture / écriture sur disque?

— Seninha

@Seninha Les opérations sont assez brèves car les accès sont mis en cache, vous pouvez donc copier beaucoup plus de données par seconde que votre disque ne peut réellement gérer, si elles sont effectuées en rafales. Si le fichier est vraiment volumineux et sur un support lent, le cache peut se remplir et tuer le processus peut prendre un certain temps. Quant à tuer dd, cela dépend de ce que bsvous lui avez fixé. Si ce n'est que 512 (la valeur par défaut), cela devrait se terminer rapidement. S'il est plus grand, cela peut prendre un peu plus de temps.

— forêt le

@qwr 128kb chunks are hardwired default in coreutils lors de la lecture à partir de blockdevices, ceci est fait dans le but de minimiser les appels système. L'analyse est donnée dans la source coreutils: git.savannah.gnu.org/cgit/coreutils.git/tree/src/ioblksize.h

— Fiisch

@AndrewHenle J'aurais peut-être dû dire que ce sont les métadonnées du système de fichiers qui sont atomiques. Vous avez raison de dire qu'une écriture peut être partielle.

— forêt

Étant donné qu'il cps'agit d'une commande de l'espace utilisateur, cela n'affecte pas l'intégrité du système de fichiers.

Vous devez bien sûr être prêt à ce qu'au moins un fichier n'ait pas été copié complètement si vous tuez un runnning cp programme en cours d' .

— schily
source

Pourquoi le downvote? Juste parce que c'est schily?

— Stephen Kitt

Il semble qu'il y ait au moins une personne qui dévalise toutes mes réponses. Connaissez-vous un moyen de savoir qui a fait le downvote?

— schily

Même les modérateurs ne peuvent pas savoir qui a fait des votes spécifiques - ce qui est naturellement limité aux employés de SO. Vous pouvez utiliser le lien "contactez-nous" pour leur demander d'enquêter.

— Philip Kendall

Ce serait assez triste si un programme d'espace utilisateur pouvait compromettre l'intégrité du système de fichiers. Remarque: Bien sûr, il peut y en avoir, il y en a eu et il y aura des bogues dans les implémentations du système de fichiers. Remarque # 2: De plus, bien sûr, les programmes de l'espace utilisateur fonctionnant avec des privilèges élevés (par exemple CAP_SYS_RAWIOsous Linux ou l'équivalent dans d'autres systèmes d'exploitation) qui leur donnent un accès direct au périphérique sous-jacent du système de fichiers (par exemple sudo dd if=/dev/urandom of=/dev/sda1) peuvent causer toutes sortes de ravages.

— Jörg W Mittag

Et si un système de fichiers était suffisamment bogué pour être corrompu après une interruption cp, il serait probablement corrompu à la fin cpaussi ...

— ilkkachu