Система зависает/не отвечает/невозможно использовать при копировании большого файла на USB.

Вчера я копировал один файл объемом 8 ГБ на USB с медленной скоростью записи, равной 7 МБ/с, при этом у меня 3 ГБ ОЗУ. Во время копирования система зависла, до такой степени, что я не мог даже двигать курсором.

Мне удалось войти в текстовую консоль и запустить iotop, он показал, что процесс с названием kswapd0 занимал 99,99% ввода/вывода.

Есть ли способы обойти это, чтобы копирование большого файла не делало мою систему неработоспособной?

Согласно этому отчету об ошибке, я решил проблему добавлением следующих строк

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

в файл /etc/sysctl.conf

и запустив

sudo sysctl -p

Я столкнулся с аналогичной проблемой. У меня 64-битный Ubuntu 14.04. После долгих попыток я нашел ответ, который решил мою проблему. Для удобства я добавил команды ниже, использованные в вышеупомянутом ответе. Проверьте ответ для подробного объяснения.

echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes
echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes

После использования вышеуказанных команд система начала нормально работать при копировании файлов.

Благодарю @Rmano.

Я испытываю аналогичную проблему с зависанием системы при копировании на флешку. Я подал отчет об ошибке по этому поводу: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1267648

В качестве обходного пути я обнаружил, что отключение свопа полностью устраняет проблему.

Да, есть настройки ядра, которые вы можете настроить, указывая, сколько данных должно быть отмечено как записанные, прежде чем они фактически будут записаны на диск. Смотрите здесь для довольно полного описания этих настроек. В частности, вам нужно найти значение dirty_ratio, которое хорошо работает для вас (по умолчанию оно обычно слишком высоко для настольных ПК/ноутбуков, но нет одного магического числа, которое подходит всем).

У меня была точно такая же проблема (в 2019 году) на Ubuntu 19.10 при копировании большого количества файлов с USB-диска на SATA-диск. Оба файловых системы – ext4. Когда я отключил своп, проблема исчезла. Похоже на какую-то ошибку в выделении памяти для дисковых буферов – по всей видимости, ядро пытается выделить как можно больше памяти для дисковых буферов в такой ситуации, что не имеет смысла (выделять дисковые буферы в своп…), или оно просто неправильно рассчитывает объем памяти, который может быть использован для кэширования…

Как кто-то заметил, установка swappiness на 1 не решает проблему, что логично, если файлы, которые вы копируете, имеют общий размер больше, чем размер ОЗУ…

Кстати, может кто-то объяснить, ПОЧЕМУ отключение свопа не рекомендуется? Если у меня 32 ГБ ОЗУ, какое значение имеет добавление еще 4 ГБ свопа? Я могу только подумать о каких-то неясных приложениях, которые на самом деле ожидают наличия свопа. Но я просто перестану использовать такое приложение, поскольку правильно написанное не должно заботиться о свопе. Своп должен управляться только на уровне ОС…

На Ubuntu 19.10 эта проблема возникает из-за проблем с управлением свопом. Настройки dirty_background сломали мой файловый менеджер nautilus.
Помимо зависания при копировании больших файлов, я столкнулся с несколькими проблемами с производительностью из-за плохого управления свопом в 19.10. Поскольку полное отключение свопа не рекомендуется, мы можем контролировать степень записи в раздел своп, устанавливая swappiness.

swappiness=0 говорит ядру избегать выгрузки процессов из физической памяти как можно дольше.
swappiness=100 говорит ядру агрессивно выгружать процессы из физической памяти и перемещать их в своп-кэш.

Поэтому мы установим swappiness=1.

Чтобы изменить значение swappiness, вы можете временно изменить его (данные будут потеряны после перезагрузки) на swappiness равное 1, выполнив

sudo sysctl vm.swappiness=1

Чтобы сделать изменение постоянным, отредактируйте конфигурационный файл с помощью вашего любимого редактора:

sudo gedit /etc/sysctl.conf

Найдите vm.swappiness и измените его значение в соответствии с вашими потребностями. Если vm.swappiness не существует, добавьте его в конец файла следующим образом:

vm.swappiness=1

Сохраните файл и перезагрузите.

Это помогло мне улучшить общие проблемы с производительностью в Ubuntu 19.10, хотя отключение свопа полностью устранило все проблемы с производительностью, которые у меня были с 19.10, но я все равно не рекомендую этого делать в обычных ситуациях.

В качестве эксперимента я установил sysctl.conf на:

vm.dirty_background_ratio=1
vm.dirty_ratio=2

и это решило проблему. Предыдущие значения 5/10 не помогли. Похоже, что всем следует поэкспериментировать с этими параметрами, чтобы найти оптимальный. Копирование 12 ГБ файла с SSD на флешку заняло около 15 минут без зависаний системы (USB 2.0). Вероятно, я проверю значения 2/4 и т. д. после нескольких дней тестирования.

Система: Ubuntu 19.10, i7, 8 ГБ ОЗУ, SSD.

Отключение свап-файла во время копирования сработало для меня.

sudo swapoff -a

После завершения копирования я включаю своп

sudo swapon

Редактирование: Обратите внимание, как упоминает Robby1212 в комментарии, отключение свопа опасно и должно быть выполнено после того, как вы попробовали другие решения. Мне повезло, что со мной ничего не произошло, когда я отключил своп. Я отключаю своп только при копировании больших файлов.

У меня были аналогичные проблемы при копировании файлов на диск exfat. У меня было меньше проблем при использовании файловой системы ext4 на моем USB жестком диске.

В моем случае, как пользователя Linux Mint, проблемы с передачей файлов были вызваны пакетом ntfs3; отключение этого пакета решило мою проблему. Пост altair4 в этой теме содержит больше информации, но вот копия оригинальной команды, которую он/она порекомендовал:

echo 'blacklist ntfs3' | sudo tee /etc/modprobe.d/disable-ntfs3.conf

Мне также понадобилось предпринять дополнительные шаги для успешного монтирования моего внешнего диска; смотрите эту тему для списка этих шагов.