Вы находитесь в удаче. У меня есть пользовательские 3.6.2 ядер на P8ZZ77-V, и все работает (Wi-Fi, Ethernet, acpi, интегрированное видео, звук). Это могло бы самая бесперебойная система Linux я когда-либо иметь.
Я бросил .config на pastebin, так как это - 3K + строки. Большая часть связанного с материнской платой материала встроена кроме atheros драйверов Wi-Fi, которые являются модулями. Процессор является i5 - в любом случае можно скопировать это прямо в src/.config
и затем внесите любые изменения, которые Вы хотите.
Вам не придется использовать точно 3.6.2 также; когда я обновляю ядро, я обычно просто копирую в своем старом .config и имею беглый взгляд с make menuconfig
. Фундаментальный материал не изменяется очень часто. Вы могли использовать make oldconfig
вместо этого (menuconfig делает это неявно).
[обновление] Там является проблемой с драйвером беспроводного устройства, хотя это, кажется, не влияет на нормальное функционирование. См. мой отчет здесь.
Вы можете дросселировать трубу с помощью pv -qL
(или cstream -t
обеспечивает аналогичную функциональность)
tar -cf - . | pv -q -L 8192 | tar -C /your/usb -xvf -
-q
удаляет отчет о ходе выполнения stderr.
Ограничение -L
в байтах.
Подробнее о флаге --rate-limit/-L
из man pv
:
-L RATE, --rate-limit RATE
Limit the transfer to a maximum of RATE bytes per second.
A suffix of "k", "m", "g", or "t" can be added to denote
kilobytes (*1024), megabytes, and so on.
Этот ответ первоначально указывал на throttle
, но этот проект больше не доступен, поэтому он исчез из некоторых пакетных систем.
Я полагаю, вы пытаетесь не мешать другим действиям. Последние версии Linux включают ionice
, который позволяет вам управлять планированием ввода-вывода.
Помимо разрешения различных приоритетов, есть дополнительная возможность ограничить ввод-вывод периодами, когда диск в противном случае бездействует. Команда man ionice
отобразит документацию.
Попробуйте скопировать файл с помощью такой команды:
ionice -c 3 cp largefile /new/directory
Если два каталога находятся на одном устройстве, вы можете обнаружить, что связывание файла делает то, что вы хотите. Если вы копируете в целях резервного копирования, не используйте эту опцию. ln
работает очень быстро, поскольку сам файл не копируется. Попробуйте:
ln largefile /new/directory
Или, если вы просто хотите получить к нему доступ из каталога на другом устройстве, попробуйте:
ln -s largefile /new/directory
Если решения ionice
недостаточно (почему бы то ни было) и вы действительно хотите ограничить ввод/вывод абсолютным значением, есть несколько возможностей:
самая простая: ssh
. Он имеет встроенный лимит пропускной способности. Вы можете использовать, например, tar
(вместо cp
) или scp
(если это достаточно хорошо; я не знаю, как он обрабатывает симлинки и жесткие ссылки) или rsync
. Эти команды могут передавать свои данные по ssh
. В случае tar
вы пишете на /dev/stdout
(или -
) и передаете это клиенту ssh
, который выполняет другой tar
на "удаленной" стороне.
элегантно, но не в ванильном ядре (AFAIK): Цель отображения устройств ioband
. Это, конечно, работает, только если вы можете размонтировать исходный или целевой том.
немного самописной забавы: grep "^write_bytes: " /proc/$PID/io
дает вам количество данных, записанных процессом. Можно написать сценарий, который запускает cp
в фоновом режиме, спит, например, 1/10 секунды, останавливает фоновый cp
процесс (kill -STOP $PID
), проверяет количество записанных (и прочитанных? примерно одинаковое значение в данном случае), вычисляет, сколько времени cp
должен сделать паузу, чтобы средняя скорость передачи данных снизилась до заданного значения, спит это время, будит cp
(kill -CONT $PID
), и так далее.
Вместо cp -a / foo / bar
вы также можете использовать rsync
и ограничить полосу пропускания по мере необходимости.
Из руководства rsync
:
- bwlimit = KBPS
ограничить пропускную способность ввода / вывода; КБайт в секунду
Итак, команда actall, также показывающая прогресс, будет выглядеть так:
rsync -av --bwlimit=100 --progress /foo /bar
Проблема в том, что копия заполняет вашу память блоками «в полете», «вытесняясь» полезные "данные". Известная (и очень трудно исправить) ошибка в ядре Linux, обрабатывающая ввод-вывод на медленные устройства (в данном случае USB).
Возможно, вы можете попробовать разложить копии, например с помощью сценария, подобного следующему (набросок проверки концепции, полностью непроверенный!):
while true do
dd if=infile of=outfile bs=4096 count=... seek=... skip=...
sleep 5
done
настройка seek
и пропустить
на count
каждый раунд. Необходимо настроить счетчик
, чтобы он не заполнял (слишком много) память, и 5
, чтобы позволить ей опустошить.
Ваша проблема, вероятно, не в вашем компьютере, как таковом, он, вероятно, в порядке. Но этот переходный слой USB-флэш имеет свой собственный процессор, который должен составить карту всех ваших записей, чтобы компенсировать то, что может быть на 90% неисправным чипом флэш-памяти, кто знает? Вы зальете ее, затем зальете свои буферы, затем зальете всю шину, и тогда вы застрянете - ведь именно там находится все ваше содержимое. Это может показаться неинтуитивным, но на самом деле вам нужна блокировка ввода-вывода - вам нужно позволить сверхсветовым скоростям задавать темп, а затем просто идти в ногу".
(О взломе микроконтроллеров FTL: http://www.bunniestudios.com/blog/?p=3554)
Все вышеперечисленные ответы должны работать, так что это скорее "я тоже!", чем что-либо еще: я был там, чувак. Я решил свои проблемы с помощью --bwlimit arg в rsync (2.5 Мб показались мне оптимальным вариантом для одного запуска без ошибок - если больше, я получал ошибки защиты от записи). rsync особенно подходил для моей цели, потому что я работал с целыми файловыми системами - то есть было много файлов - и простой запуск rsync во второй раз устранял все проблемы первого запуска (что было необходимо, когда я становился нетерпеливым и пытался разогнаться до 2,5 Мб).
Тем не менее, я полагаю, что это не совсем практично для одного файла. В вашем случае вы могли бы просто передать dd в режиме raw-write - таким образом вы можете обрабатывать любой вход, но только один целевой файл за раз (хотя этот единственный файл может быть целым блочным устройством, конечно).
## OBTAIN OPTIMAL IO VALUE FOR TARGET HOST DEV ##
## IT'S IMPORTANT THAT YOUR "bs" VALUE IS A MULTIPLE ##
## OF YOUR TARGET DEV'S SECTOR SIZE (USUALLY 512b) ##
% bs=$(blockdev --getoptio /local/target/dev)
## START LISTENING; PIPE OUT ON INPUT ##
% nc -l -p $PORT | lz4 |\
## PIPE THROUGH DECOMPRESSOR TO DD ##
> dd bs=$bs of=/mnt/local/target.file \
## AND BE SURE DD'S FLAGS DECLARE RAW IO ##
> conv=fsync oflag=direct,sync,nocache
## OUR RECEIVER'S WAITING; DIAL REMOTE TO BEGIN ##
% ssh user@remote.host <<-REMOTECMD
## JUST REVERSED; NO RAW IO FLAGS NEEDED HERE, THOUGH ##
> dd if=/remote/source.file bs=$bs |\
> lz4 -9 | nc local.target.domain $PORT
> REMOTECMD
Вы можете обнаружить, что netcat немного быстрее, чем ssh для передачи данных, если попробуете. В любом случае, другие идеи уже были приняты, так почему бы и нет?
[EDIT]: Я заметил упоминания lftp, scp и ssh в другом сообщении и подумал, что мы говорим об удаленной копии. Локальная намного проще:
% bs=$(blockdev --getoptio /local/target/dev)
% dd if=/src/fi.le bs=$bs iflag=fullblock of=/tgt/fi.le \
> conv=fsync oflag=direct,sync,nocache
[EDIT2]: Отдаю должное: только что заметил, что ptman опередил меня на пять часов в комментариях.
Определенно, вы можете настроить $bs на производительность здесь с помощью множителя - но некоторые файловые системы могут потребовать, чтобы он был кратен размеру секторов целевого фс, так что имейте это в виду.
Уменьшите предел грязных страниц. Предел по умолчанию безумный.
Создайте /etc/sysctl.d/99-sysctl.conf с помощью:
vm.dirty_background_ratio = 3
vm.dirty_ratio = 10
Затем запустите sysctl -p или перезагрузитесь.
Что происходит, так это то, что данные читаются быстрее, чем они могут быть записаны на целевой диск. Когда linux копирует файлы, он считывает их в ОЗУ, а затем отмечает страницы как грязные для записи в место назначения. Грязные страницы не могут быть заменены. Таким образом, если исходный диск работает быстрее, чем целевой диск, и вы копируете больше данных, чем у вас есть свободной ОЗУ, операция копирования съест всю доступную ОЗУ (или, по крайней мере, какой бы ни был предел грязных страниц, который может быть больше, чем доступной оперативной памяти) и вызывают голодание, поскольку грязные страницы не могут быть заменены, а чистые страницы используются и помечаются как грязные по мере освобождения.
Обратите внимание, что это не решит проблему полностью ... что действительно нужно Linux, так это какой-то способ разрешить создание грязных страниц, чтобы выполняемая большая передача не занимала всю доступную RAM / все разрешенные грязные страницы.
У меня была такая же проблема с двумя внутренними дисками, т.е. серьезные зависания системы при копировании больших файлов.
vm.dirty _Соотношение устанавливает для уменьшения максимального объема памяти, выделяемой для грязных страниц.
Попытка (на основе расчетов скоростей чтения/записи )установить различные значения для-
vm.dirty_ratio = 20
vm.dirty_background_ratio = 10
vm.dirty_background_bytes = 0
vm.dirty_bytes = 0
vm.swappiness=1
vm.dirty_background_ratio = 1
vm.dirty_ratio = 2
Не удалось получить удовлетворительное решение для предотвращения зависаний во время копирования файлов (, особенно файлов размером более 3 ГБ ).
В Ubuntu 19 с помощью утилиты gnome -disk -3.34.0 (Disks )Я заметил утилиту с графическим интерфейсом в разделе «Настройки диска» под названием «Write Cache». Включение «Включить кэш записи» устранило задержку копирования между двумя внутренними дисками. Скорость копирования снижена на 50%, но, по крайней мере, устранены зависания.
Для обоих дисков установлено значение «Включить кэш записи».
Тем не менее, система по-прежнему неудовлетворительна для копирования на внешний USB-накопитель или с него.