Система зависає / не реагує / непридатна для копіювання великого файлу на USB

51

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

Мені вдалося увійти в текстову консоль, і запустивши iotop, це показало, що названий процес kswapd0займає 99,99% IO.

Чи є обхідні шляхи, тому копіювання великого файлу не робить мою систему непридатною?

usb freeze

— сашоалм
джерело

12

Ця помилка настільки смішна ...

— king_julien

Так, це відбувається не тільки з Ubuntu, але і з іншими ароматами Debian. Я також бачив ту саму проблему в Kali Linux та Parrot OS. У Калі є найгірший сценарій, тоді як папуга робить це гладким, але хоч і висить для дуже великих розмірів. Я думаю, що це проблема в Linux Kernel і як це написано. Це і залишиться найгіршим кошмаром Linux усіх часів.

— Mohith7548

33

Відповідно до цього звіту про помилку, я вирішив його, додавши наступні рядки

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

в /etc/sysctl.conf

і біг

sudo sysctl -p

— Філіп Гачуд
джерело

12

Хочете пояснити, що роблять вищезазначені рядки?

— nsane

3

@ nisargshah95 Вибачте, але не майте підказки, шукайте себе ;-)

— Philippe Gachoud

4

@ nisargshah95 Деталі проблеми пояснюються у двох статтях LWN, зв'язаних у unix.stackexchange.com/a/107722/52205

— 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 та SSD шести поколінь? Чому вони не помічають цього під час тестування.

— Hatoru Hansou

3

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

— Марекі

1

@Marecky Після деякого читання здається, що dirty_bytes - це не одна штука usb. Вони впливають на всі введення-виведення, тому зробивши ехо, ви змінюєте їх глобальну систему, а не лише для маятників. Я думаю лише для поточної сесії. Здається, що поточні значення ядра налаштовані на нові пристрої зберігання даних. Побічні маятники страждають як побічний ефект. На жаль, немає посилання, але це потрібно легко знайти, погугливши його.

— Хатору Хансу

3

Дивіться цю відповідь, щоб зробити її стійкою

— PeterM

5

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

Як вирішення проблеми я виявив, що відключення swap повністю усуває проблему.

— Володимир Руцький
джерело

1

На жаль, це не спрацювало для мене на Ubuntu 16.04.

— Programster

Не працював для мене ні на Ubuntu 16.04.3 LTS - це на ноутбуці Alienware 17 R2.

— AnthonyK

4

Так, є параметри ядра, за допомогою яких можна налаштувати, вказуючи, скільки даних потрібно позначати, як написано, перш ніж вони фактично записуються на диск. Подивіться тут для досить вичерпного їх опису. Зокрема, ви захочете знайти значення dirty_ratio, яке добре працює для вас (воно за замовчуванням занадто високе для робочого столу / ноутбука, але немає жодного магічного числа, яке працює для всіх).

— Бандрамі
джерело

2

Привіт, підкажете, будь ласка, які цифри мені потрібно встановити, виходячи зі специфікацій мого ноутбука? зверніться до askubuntu.com/questions/713723/…

1

У мене були подібні проблеми при копіюванні файлів на exfatдиск. У мене було менше проблем із використанням ext4файлової системи на жорсткому диску USB.

— булава
джерело

1

Ця проблема була і у ext4

— PeterM

Копіювання Fedora 27 (ядро 4.17.5-100) з підключеного до USB закрученого іржі на флешку, підключену USB. Це, здається, заходить в заморожуванні екранізатора в середині завмирання. :-( ~~~

— Девід Тонхофер

1

У мене якраз була така ж проблема (у 2019 році), на ubuntu 19.10, при цьому копіюється велика кількість файлів з USB-диска на диск SATA. Обидві файлові системи є ext4. Коли я вимкнув своп, проблема зникла. Це схоже на певну помилку в розподілі пам'яті для дискових буферів - мабуть, ядро намагається виділити якомога більше пам’яті для дискових буферів, наскільки це можливо в такій ситуації, що не має сенсу (робити дискові буфери в свопі ...) або він просто неправильно обчислює розмір пам'яті, ніж може бути використаний для кешування ...

— чакер
джерело