Чому мій комп'ютер замерзає, коли я копіюю файл в маятник?

У мене тут справді дивна ситуація. Мій ПК працює добре, принаймні в більшості випадків, але є одне, з чим я не можу впоратися. Коли я намагаюся скопіювати файл з мого pendrive, все нормально - у мене 16-19M / s, він працює досить добре. Але коли я намагаюсь скопіювати щось у той самий мандрівник, мій ПК замерзає. Вказівник миші перестає рухатися на секунду чи дві, потім трохи рухається і знову зупиняється. Коли щось грає, наприклад, в Amarok, звук діє як кулемет. Швидкість стрибає з 500К / с до 15М / с, середня 8М / с. Це відбувається лише тоді, коли я щось копіюю в мандрівник. Коли процес копіювання закінчений, все повертається до норми.

Я спробував усе - інший pendrive, інший порт USB на передній панелі або ті порти ззаду, я навіть змінив USB-штифти на материнській платі (передній панелі), але незалежно від того, куди я поставив USB-накопичувач, це завжди те саме. Я спробував іншу файлову систему , - fat32, ext4. У мене немає проблем із пристроєм у Windows, на моєму ноутбуці. Це повинен бути мій ПК або щось у моїй системі. Я поняття не маю, що шукати. Я використовую тестування Debian за допомогою окремого Openbox. Мій ПК такий собі старий - Pentium D 3 ГГц, 1 Гбіт оперативної пам’яті, 1,5 ТБ WD Зелений диск. Якщо у вас є щось, що допомогло б мені вирішити це питання, я би радий це почути.

Я не знаю, яку ще інформацію я повинен надати, але якщо вам щось потрібно, просто запитайте, я якнайшвидше оновлю цю посаду.

Я спробував відтворити цю проблему на ubuntu 13.04 live CD. Я змонтував свій зашифрований розділ + зашифрований своп і підключив свій pendrive до порту usb. Далі я спробував запустити деякі програми, і тепер у мене є ~ 820MiB оперативної пам’яті та близько 400MiB в SWAP. З копіюванням немає проблем, взагалі немає заморожування, все як належить. Так, схоже, це несправність системи, але де саме? Що б викликало таку дивну поведінку?

Ви використовуєте 64-бітну версію Linux з великою кількістю пам'яті? У цьому випадку проблема може полягати в тому, що Linux може заблокувати хвилини на великих записах на повільних пристроях, наприклад, SD-картах або USB-накопичувачах. Це відома помилка, яку слід виправити в нових ядрах.

Дивіться http://lwn.net/Articles/572911/

Вирішення: як головна проблема:

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

Я додав його до свого /etc/rc.localфайлу у своїх 64-бітових машинах.

TANSTAAFL ; ця зміна може (і, ймовірно, зменшить пропускну здатність до цих пристроїв) - це компроміс між затримкою та швидкістю. Повернутися до попередньої поведінки ви можете

echo 0 > /proc/sys/vm/dirty_background_bytes
echo 0 > /proc/sys/vm/dirty_bytes

... які є типовими значеннями, це означає, що поведінка запису буде контролюватися параметрами dirty_ratioта dirty_background_ratio.

Зверніть увагу на людей, не дуже досвідчених з Linux, файли - /proc це псевдофайли - це просто канали зв'язку між ядром та користувальним простором. Ніколи не використовуйте редактор для їх зміни або перегляду; отримайте замість підказки оболонки --- наприклад, з sudo -i(аромати Ubuntu) або su rootі використовуйте echoта cat).

Оновити 2016/04/18, здається, що врешті-решт проблема все ще є. Ви можете подивитися на LWN.net , у цій статті про черги на повернення .

Причиною може бути посилення запису, оскільки система намагається писати шматками, меншими, ніж блок стерти (робить читання / мод / запис) + нерівність блоку.

Щоб перевірити свій поточний параметр, виконайте:

cat /sys/block/sd**X**/device/max_sectors

Ви можете налаштувати правила залу для цих пристроїв:

Змініть значення USB "max_sectors" для цілого сімейства пристроїв

У цьому випадку я замінив max_sectors для всіх пристроїв, які використовували за замовчуванням 240 (USB-накопичувач) на 32K або 2K-сектори.

У моїй системі (Mageia 4, 3.14.24 core i7) мені довелося це зробити через жахливо повільні швидкості запису (2 МБ / сек) на Kingston DT101 G2 16 Гб:

vi /usr/lib/udev/rules.d/81-udisks_maxsect.rules

і додати:

SUBSYSTEMS=="scsi", ATTR{max_sectors}=="240", ATTR{max_sectors}="32678"

А ddшвидкість запису зросла в 3 рази. mc cpймовірно, 10-20 разів вгору (після того, як я запустив перший розділ @ 8192'-й сектор і переформатувався з 64-кратними вирівняними кластерами):

fdisk -u /dev/sdh # make DOS compat off if on
mkfs.vfat /dev/sdh1 -n KINGSTON16G -s 128 **-R 4592*** and use *fsck.vfat -v /dev/sdh1

перевірити вирівнювання (перевірка [сектор запуску даних] має бути кратною 128 (розмір кластера)). За необхідності відрегулюйте кількість зарезервованих секторів (-R).

За замовчуванням max_sectors (240), схоже, викликає високе посилення запису на деяких дешевих нових дисках. Але будьте дуже обережні при такому високому налаштуванні, подібний ефект досягається в 2048 секторах (можливо, 1 М стирає блоки:

SUBSYSTEMS=="scsi", ATTR{max_sectors}=="240", ATTR{max_sectors}="2048"

Перевірте всі свої старі USB-пристрої, щоб вони все ще працювали добре. Використовуйте атрибути постачальника / моделі у файлах правил, щоб бути більш конкретними.

апаратне та програмне забезпечення

У мене виникли дивні проблеми, подібні до цієї, з USB-накопичувачами, і в моєму дослідженні це майже завжди або проблема з драйвером, або конкретне обладнання всередині ПК / материнської плати.

Я знаю це, тому що у мене є кілька систем, що мають однакове обладнання, і на одній я можу виконувати цю операцію без проблем, тоді як на іншій проблема з’являється.

Що робити?

Ваші варіанти тут дійсно обмежені. Про єдине, що ви можете зробити - переконайтеся, що у вас встановлена ​​остання BIOS / прошивка, встановлена ​​у вашій системі, і переконайтеся, що у вас є останні версії пакунків disto.

Крім того, все, що я можу запропонувати, - це переконатися, що ви уникнете подібної ситуації, не намагаючись копіювати файли, коли інша копія виконується.

Якщо у вас є тип особистості, де такі речі вас дратують, ви можете спробувати інший дистрибутив Linux і повторити кроки, які призводять до вашої проблеми. Це дозволить просто усунути, чи це проблема, пов'язана з дистрибутивом, або проблема з обладнанням, як я описав вище. Це було б невеликим розрадою, але мені завжди подобається знати речі, а не закопувати голову в пісок, а ні.

Ще щось?

Якщо ви справді нав’язливі, ви можете спробувати запустити програму, з якою ви робите копію, з straceнадією зловити систему в будь-якому випадку системного дзвінка. Ви також можете це зробити з командного рядка.

Приклад

$ strace -o cp1.log cp -r /path/to/dir1 /path/to/usb/. 

Потім, поки це працює, запустіть ще один.

$ strace -o cp2.log cp -r /path/to/dir2 /path/to/usb/. 

Система, сподіваємось, замерзне під час цієї операції, і, можливо, вам пощастить і знайдете дим у будь-якому з цих файлів журналу.