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

52

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

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

Существуют ли обходные пути, поэтому копирование большого файла не делает мою систему непригодной для использования?

usb freeze

— sashoalm
источник

14

Эта ошибка настолько нелепа ...

— king_julien

Да, это происходит не только с Ubuntu, но и с другими версиями Debian. Я также видел ту же проблему в Kali Linux и Parrot OS. Кали имеет худший сценарий, в то время как попугай делает это гладко, но даже при том, что зависает для очень больших размеров. Я думаю, что это проблема в ядре Linux и как она написана. Это и останется худшим кошмаром Linux за все время.

— Mohith7548

34

В соответствии с этим сообщением об ошибке я решил, добавив следующие строки

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

в /etc/sysctl.conf

и работает

sudo sysctl -p

— Филипп Гачу
источник

12

Хотите объяснить, что делают вышеприведенные строки?

— nsane

3

@ nisargshah95 извините, но понятия не имею,

— поищите

4

@ nisargshah95 Подробности проблемы объясняются в двух статьях LWN, ссылки на которые приведены

— Rmano,

1

Спасибо, я только что обнаружил, что моя Ubuntu 16.04 не может записать два файла по 1,4 ГБ на USB без этих двух строк, я зависал на несколько часов, это решенная проблема, кому какое дело, иногда вы просто хотите скопировать файлы и переместить на.

— Майк

1

У меня были значения 5 и 60. Они контролируют процент памяти, используемой для операций, dirty_background_bytesа также dirty_bytesиспользуют абсолютные байтовые значения. Я исправил эту проблему с помощью второго ответа, но чтобы сделать его постоянным, добавьте его sysctl.conf, посмотрите этот ответ . Поэтому при использовании процентных значений настраивайте их при обновлении памяти.

— PeterM

20

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

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

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

Спасибо @Rmano .

— Махендран Саккарай
источник

2

Настройки отношения не помогли в моей системе 12.04 с медленным общим ресурсом NAS. Но после установки байтов напрямую, как предлагается здесь, моя система снова может использоваться при копировании в NAS.

— MIVK

6

Этому вопросу уже 3 года, и он все еще необходим, чтобы избежать использования непригодной системы при копировании в pendrive. Немного информации: если pendrive отформатирован с использованием Linux fs вроде ext4, этого не произойдет. Когда я сказал «непригодная система», я действительно имел в виду это, указатель мыши перестает отвечать на запросы, и вам приходится настаивать, чтобы перемещать его по экрану, вы смотрите на системный монитор, и нет никакого ненормального использования ресурсов. Все ли пользователи ядра используют процессоры Intel 6-го поколения и SSD-накопители? Почему они не замечают этого во время тестирования.

— Hatoru Hansou

3

@HatoruHansou Я чувствую то же самое, я только что установил свежий Debian Stretch, и эта ошибка также присутствует здесь. Я знаю, что это зависит не от дистрибутива, а от исходников ядра, но мужчин, почему же это все еще не исправлено?

— Марецкий

1

@Marecky После некоторого прочтения кажется, что dirty_bytes - это не только USB. Они влияют на все операции ввода-вывода, поэтому после выполнения эха вы меняете их глобально, а не только для pendrive. Только для текущей сессии, я думаю. Похоже, что текущие значения ядра подстроены под новые устройства хранения. Медленные pendrives страдают как побочный эффект. Извините, нет ссылки, но это должно быть легко найти путем поиска в Google.

— Hatoru Hansou

3

Смотрите этот ответ, чтобы сделать его постоянным

— PeterM

5

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

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

— Владимир Руцкий
источник

1

К сожалению, это не сработало для меня в Ubuntu 16.04.

— Программист

У меня не работало и на Ubuntu 16.04.3 LTS - на ноутбуке Alienware 17 R2.

— AnthonyK

4

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

— Bandrami
источник

2

Эй, не могли бы вы предложить мне, какие цифры мне нужно установить на основе характеристик моего ноутбука? см askubuntu.com/questions/713723/...

3

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

— Чакер
источник

Работало ли какое-либо из решений здесь для вас? Я тоже начал страдать от этой проблемы после обновления до 19.10 и в процессе обновления ядра тоже. В моем случае это происходит, когда я копирую большой файл из раздела A в B того же SSD. Отключение SWAP "исправляет" проблему.

— Pileofrocks

1

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

— булава
источник

1

Был ли этот вопрос на ext4 тоже

— PeterM

Копирование Fedora 27 (ядро 4.17.5-100) с вращающейся ржавчины с USB-подключением на флешку с USB-подключением. Похоже, это заходит так далеко, как замораживание блокировщика экрана в середине затухания. :-( ~~~

— Дэвид Тонхофер