Сделайте диск/дисковую копию медленнее

Вы находитесь в удаче. У меня есть пользовательские 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 делает это неявно).

[обновление] Там является проблемой с драйвером беспроводного устройства, хотя это, кажется, не влияет на нормальное функционирование. См. мой отчет здесь.

29
09.08.2017, 02:51
9 ответов

Вы можете дросселировать трубу с помощью 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, но этот проект больше не доступен, поэтому он исчез из некоторых пакетных систем.

23
27.01.2020, 19:38
[1120819] Эта проблема не имеет ничего общего с ошибками или сбоями в аппаратном или программном обеспечении, просто ваше ядро пытается быть с вами любезным и возвращать подсказки и копировать в фоновом режиме (оно использует встроенный кэш ядра: больше оперативной памяти, больше кэша, но вы можете ограничить его, написав где-нибудь в /proc - хотя и не рецензируемый). Флеш-накопители слишком медленные, и пока ядро записывает на них, другие операции ввода-вывода не могут быть выполнены достаточно быстро. Ионика [1121169] [1121170], упомянутая несколько раз в других ответах, является нормальной. Но пытались ли вы просто смонтировать диск с помощью [1121171]-o sync[1121172], чтобы избежать буферизации операционной системы? Наверное, это самое простое решение.[1120820].
0
27.01.2020, 19:38

Я полагаю, вы пытаетесь не мешать другим действиям. Последние версии Linux включают ionice , который позволяет вам управлять планированием ввода-вывода.

Помимо разрешения различных приоритетов, есть дополнительная возможность ограничить ввод-вывод периодами, когда диск в противном случае бездействует. Команда man ionice отобразит документацию.

Попробуйте скопировать файл с помощью такой команды:

ionice -c 3 cp largefile /new/directory

Если два каталога находятся на одном устройстве, вы можете обнаружить, что связывание файла делает то, что вы хотите. Если вы копируете в целях резервного копирования, не используйте эту опцию. ln работает очень быстро, поскольку сам файл не копируется. Попробуйте:

ln largefile /new/directory

Или, если вы просто хотите получить к нему доступ из каталога на другом устройстве, попробуйте:

ln -s largefile /new/directory
13
27.01.2020, 19:38

Если решения ionice недостаточно (почему бы то ни было) и вы действительно хотите ограничить ввод/вывод абсолютным значением, есть несколько возможностей:

  1. самая простая: ssh. Он имеет встроенный лимит пропускной способности. Вы можете использовать, например, tar (вместо cp) или scp (если это достаточно хорошо; я не знаю, как он обрабатывает симлинки и жесткие ссылки) или rsync. Эти команды могут передавать свои данные по ssh. В случае tar вы пишете на /dev/stdout (или -) и передаете это клиенту ssh, который выполняет другой tar на "удаленной" стороне.

  2. элегантно, но не в ванильном ядре (AFAIK): Цель отображения устройств ioband. Это, конечно, работает, только если вы можете размонтировать исходный или целевой том.

  3. немного самописной забавы: grep "^write_bytes: " /proc/$PID/io дает вам количество данных, записанных процессом. Можно написать сценарий, который запускает cp в фоновом режиме, спит, например, 1/10 секунды, останавливает фоновый cp процесс (kill -STOP $PID), проверяет количество записанных (и прочитанных? примерно одинаковое значение в данном случае), вычисляет, сколько времени cp должен сделать паузу, чтобы средняя скорость передачи данных снизилась до заданного значения, спит это время, будит cp (kill -CONT $PID), и так далее.

7
27.01.2020, 19:38

Вместо cp -a / foo / bar вы также можете использовать rsync и ограничить полосу пропускания по мере необходимости.

Из руководства rsync :

 - bwlimit = KBPS 
 

ограничить пропускную способность ввода / вывода; КБайт в секунду

Итак, команда actall, также показывающая прогресс, будет выглядеть так:

rsync -av --bwlimit=100 --progress /foo /bar
24
27.01.2020, 19:38

Проблема в том, что копия заполняет вашу память блоками «в полете», «вытесняясь» полезные "данные". Известная (и очень трудно исправить) ошибка в ядре Linux, обрабатывающая ввод-вывод на медленные устройства (в данном случае USB).

Возможно, вы можете попробовать разложить копии, например с помощью сценария, подобного следующему (набросок проверки концепции, полностью непроверенный!):

while true do
  dd if=infile of=outfile bs=4096 count=... seek=... skip=...
  sleep 5
done

настройка seek и пропустить на count каждый раунд. Необходимо настроить счетчик , чтобы он не заполнял (слишком много) память, и 5 , чтобы позволить ей опустошить.

2
27.01.2020, 19:38

Ваша проблема, вероятно, не в вашем компьютере, как таковом, он, вероятно, в порядке. Но этот переходный слой 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 на производительность здесь с помощью множителя - но некоторые файловые системы могут потребовать, чтобы он был кратен размеру секторов целевого фс, так что имейте это в виду.

5
27.01.2020, 19:38

Уменьшите предел грязных страниц. Предел по умолчанию безумный.

Создайте /etc/sysctl.d/99-sysctl.conf с помощью:

vm.dirty_background_ratio = 3
vm.dirty_ratio = 10

Затем запустите sysctl -p или перезагрузитесь.

Что происходит, так это то, что данные читаются быстрее, чем они могут быть записаны на целевой диск. Когда linux копирует файлы, он считывает их в ОЗУ, а затем отмечает страницы как грязные для записи в место назначения. Грязные страницы не могут быть заменены. Таким образом, если исходный диск работает быстрее, чем целевой диск, и вы копируете больше данных, чем у вас есть свободной ОЗУ, операция копирования съест всю доступную ОЗУ (или, по крайней мере, какой бы ни был предел грязных страниц, который может быть больше, чем доступной оперативной памяти) и вызывают голодание, поскольку грязные страницы не могут быть заменены, а чистые страницы используются и помечаются как грязные по мере освобождения.

Обратите внимание, что это не решит проблему полностью ... что действительно нужно Linux, так это какой-то способ разрешить создание грязных страниц, чтобы выполняемая большая передача не занимала всю доступную RAM / все разрешенные грязные страницы.

2
27.01.2020, 19:38

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

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-накопитель или с него.

0
15.04.2020, 08:08

Теги

Похожие вопросы