Что происходит, когда я убиваю 'cp'? Это безопасно и имеет ли это какие-либо последствия?

Каковы последствия для файловой системы ext4, когда я завершаю cpкоманду копирования , нажимая Ctrl+ Cво время ее работы?

Файловая система повреждена? Пространство раздела, занятое неполным скопированным файлом, все еще используется после его удаления?

И, самое главное, cpбезопасное ли завершение процесса?

— Seninha
источник

Имейте в виду, что хотя ответы верны для ext4, файловые системы без ведения журнала могут быть не такими безопасными.

— Авен

@ Ave Journaling не имеет к этому никакого отношения. Системные вызовы являются атомарными независимо от того, какую файловую систему вы используете. Ведение журнала полезно в ситуациях, когда власть может быть внезапно потеряна.

— лес

Ответы:

Это безопасно, но, естественно, вы не закончили копирование.

Когда cpкоманда запускается, она делает системные вызовы, которые инструктируют ядро создавать копии файла. Системный вызов - это функция, которую может вызывать приложение, которое запрашивает у ядра службу, такую как чтение или запись данных на диск. Процесс пользовательского пространства просто ожидает завершения системного вызова. Если бы вы отслеживали вызовы, это выглядело бы примерно так:

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

Это повторяется для каждого файла, который нужно скопировать. Никакой коррупции не произойдет из-за того, как работают эти системные вызовы. Когда системные вызовы , как они вводятся, фатальный сигнал будет принимать только силу после того , системный вызов был закончен , не в то время как он работает. Из-за этого принудительное завершение процесса приведет к его завершению только после завершения текущего запущенного системного вызова. Это означает, что ядро, в котором находится драйвер файловой системы, может свободно завершать операции, которые ему необходимо выполнить, чтобы перевести файловую систему в нормальное состояние. Любой ввод-вывод такого рода никогда не будет завершен в середине операции, что делает их атомарными операциями.

Интересно, что именно поэтому такие команды cpмогут не завершаться сразу после их уничтожения. Если вы копируете очень большой файл и уничтожаете его, даже с помощью SIGKILL, процесс все равно будет выполняться до завершения текущего системного вызова. С большим файлом это может занять некоторое время, так как процесс будет в непрерывном состоянии.

— лес
источник

@qwr Это скорее всего часть библиотеки glibc, а не она cpсама. Он имеет различные функции доступа к файлам, которые используют его как значение.

— лес

Отличный ответ! Я никогда не осознавал, что есть задержка в завершении cpпосле SIGKILL, даже при работе с большими файлами ... возможно, продолжительность этих непрерывных атомарных операций процесса слишком мала. Работает ли то же самое объяснение для убийства ddи других процессов чтения / записи на диск?

— Сенинья

@Seninha Операции довольно короткие, потому что доступы кэшируются, поэтому вы можете копировать намного больше данных в секунду, чем ваш диск может обработать, если это делается пакетами. Если файл действительно большой и медленный, то кеш может заполниться, и процесс может занять некоторое время. Что касается убийства dd, это зависит от того, что bsвы установите для него. Если это только 512 (по умолчанию), то оно должно быстро завершиться. Если он больше, то это может занять немного больше времени.

— лес

@qwr 128-килобайтные блоки по умолчанию используются в coreutils при чтении с блочных устройств, это делается для того, чтобы минимизировать системные вызовы. Анализ приведен в источнике coreutils: git.savannah.gnu.org/cgit/coreutils.git/tree/src/ioblksize.h

— Fiisch

@AndrewHenle Возможно, я должен был сказать, что это метаданные файловой системы, которые являются атомарными. Вы правы, что запись может быть частичной.

— лес

Поскольку cpэто команда пользователя, это не влияет на целостность файловой системы.

Вы, конечно, должны быть готовы к тому, что по крайней мере один файл не будет скопирован полностью, если вы убьете работающую cpпрограмму.

— Шили
источник

Почему отрицательный голос? Просто потому, что это глупо?

— Стивен Китт

Похоже, что хотя бы один человек отрицает все мои ответы. Знаете ли вы, как выяснить, кто сделал понижательное голосование?

— Шили

Даже модераторы не могут узнать, кто сделал конкретные голоса - это понятно только для сотрудников SO. Вы можете использовать ссылку «связаться с нами», чтобы попросить их провести расследование.

— Филип Кендалл

Было бы очень грустно, если бы пользовательская программа могла нарушить целостность файловой системы. Примечание. Конечно, могут быть, были и будут ошибки в реализациях файловой системы. Примечание № 2: Конечно, программы пользовательского пространства, работающие с повышенными привилегиями (например, CAP_SYS_RAWIOв Linux или аналогичных в других ОС), которые предоставляют им прямой доступ к базовому устройству файловой системы (например sudo dd if=/dev/urandom of=/dev/sda1), могут нанести всевозможные разрушения.

— Йорг Миттаг

И если бы файловая система была достаточно глючной, чтобы ее можно было испортить после прерывания cp, она, вероятно, cpтоже была бы повреждена из-за завершения ...

— ilkkachu