LINUX.ORG.RU
ФорумTalks

Когда починят «ускоренное» копирование файлов в Linux?

 ,


10

5

Итак, дано: Ubuntu 16.04.4, Fedora 27.

И там и там есть один баг, которому уже много лет, я даже честно не знаю сколько.

Суть бага: прогресс показывает сначала очень высокую скорость копирования, доходит до отметки примерно в 60% и врубает тормоза. У меня бывало так, что на Ubuntu 2-3 гигабайта копировались на флешку за пару секунд, а потом удовольствие растягивалось еще на 20 минут, при этом объем передаваемых данных равен 8 гб, понятное дело, что это баг, но ему уже сколько лет! Когда починят то? Забавно, но cp при этом показывает равномерную скорость копирования и в серверной Ubuntu я спокойно копирую данные в 500 гигабайт между ЖД без проблем.

Но у меня Linux на десктопе и черт побери, он в 2018 еще не готов для массового пользования, когда такие детские баги вылезают.


Забей, это не исправят. Можно только накрутить костылей разной степени кривизны и универсальности. Тут звезды сошлись, куча слоев, каждый по-своему тупит.

Забавно, но cp при этом показывает равномерную скорость копирования

Действительно забавно, я удивлен.

Deleted
()
Ответ на: комментарий от Quasar

i5-4670, 16 гб озу и SSD диск уже медленно в 2018 году? С вами точно все хорошо?

fman2
() автор топика
Ответ на: комментарий от Quasar

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

Вот в этом и есть проблема. Зачем вообще было свопиться, если при отключенном свопе всё работает (oom killer не запускается)?

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

Sorcerer ★★★★★
()
Ответ на: комментарий от Sorcerer

дисковый кэш системе важнее, чем память процессов

С ЖД да. Я давно swappiness выкрутил в 100.

bodqhrohro_promo
()
Ответ на: комментарий от fman2

При том, что 10 не нужна, а XP рулит. Синк там где-то включается, я давно врубил для всех носителей, кроме C:/D:, и забыл — дёргаю флешки спокойно без отмонтирования.

bodqhrohro_promo
()
Ответ на: комментарий от Deleted

dirty_bytes это лимит в байтах, dirty_ratio — в процентах от доступной ядру памяти. Обе настройки управляют одним и тем же лимитом, поэтому не надо дёргать обе — всё равно сработает только последняя. То же самое и с парой dirty_background_bytes/dirty_background_ratio.

i-rinat ★★★★★
()
Ответ на: комментарий от Black_Shadow

И опять как всегда. Благо, одно я знаю точно — сливную ручку они с винды не слизывали. До этого маразма даже майки не додумались.

bodqhrohro_promo
()
Ответ на: комментарий от bodqhrohro_promo

Вот ты мне скажи. От чего у тебя так подгорает? От того, что венда - говно? Ну говно, и что? Или что-то другое - говно? Ну и пусть. Что с того? KDE говно? Да, говно, но другие DE/WM ещё большее говно.

Black_Shadow ★★★★★
()
Последнее исправление: Black_Shadow (всего исправлений: 2)
Ответ на: комментарий от Black_Shadow

другие DE/WM ещё большее говно

Разумеется. Всё говно, что готовенькое. Либо пилишь под себя сам, либо страдаешь.

bodqhrohro_promo
()
Ответ на: комментарий от spider_russia

Я сегодня слишком трезв, чтобы общаться с дебилами.

Black_Shadow ★★★★★
()
Ответ на: комментарий от sergej

«пап, покажи многозадачность виндовз 95. Сейчас сынок, дискетку доформатирую».

железный флопик (не USB затычка) - это просто пример медленного устройства с дорогим io через прерывания. никаких кешей и прочего там нет.

с тем же успехом можно cd-rom раскрутить в PIO режиме. многозадачность останется, но на каком-нибудь четвертопне, музычка будет затыкаться и идти рывками и всё будет тормозить. тоже пример дорогого io. но устройство уже пошустрее.

n_play
()
Ответ на: комментарий от spider_russia

На главной ещё висит новость о новом релизе Электрона. Глупый вопрос - зачем.

O02eg ★★★★★
()
Ответ на: комментарий от sergej

Я верю, что ты лично проверил все версии NT начиная с 3.1

Первая серийная NT на сколько я помню была 3.0 и ставилась с 12-и дискеток 3,5, а еще было отдельно две или три дискетки с какими-то драйверами. После долгих и мучительных истязаний софта и железа мы все втроем сдались так и не сподобившись подружить её с Новелью. :)

AfterWork
()
Ответ на: комментарий от redgremlin

Рассказывай. Вот буквально несколько месяцев назад на USB-дисковод писал с XP — мгновенно показывает, что файл скопировался, потом добрую минуту скрипит.

А у меня почему не скрипит ?

vasya_pupkin ★★★★★
()
Последнее исправление: vasya_pupkin (всего исправлений: 1)
Ответ на: комментарий от sergej

Но не хочешь не верь, я не заставляю. Я верю, что ты лично проверил все версии NT начиная с 3.1

Да, но с 3.51

vasya_pupkin ★★★★★
()
Ответ на: комментарий от redgremlin

Рассказывай. Вот буквально несколько месяцев назад на USB-дисковод писал с XP — мгновенно показывает, что файл скопировался, потом добрую минуту скрипит.

А можешь ещё заскринить и выложить на какой нибудь YouTube.

vasya_pupkin ★★★★★
()
Ответ на: комментарий от i-rinat

А лучше еще добавить vm.dirty_expire_centisecs = 500.

Также можно включить новый механизм Dynamic writeback throttling, если он не включен в дистрибутиве, но для него нужно использовать нестандартный I/O Scheduler. Я предпочитаю kyber.

Чтобы понять, включен ли Dynamic writeback throttling, можно проверить, задана ли опция сборки CONFIG_BLK_WBT и CONFIG_BLK_WBT_SQ:

$ zgrep CONFIG_BLK_WBT /proc/config.gz

или

$ grep CONFIG_BLK_WBT /boot/config-*

Если вы видите:

CONFIG_BLK_WBT=y
CONFIG_BLK_WBT_SQ=y

То ничего дополнительно делать не нужно, Dynamic writeback throttling уже работает (но лучше все же поменять I/O Scheduler с cfq на kyber).

Если видите:

CONFIG_BLK_WBT=y
CONFIG_BLK_WBT_MQ=y
# CONFIG_BLK_WBT_SQ is not set

То Dynamic writeback throttling не включен. Чтобы его включить, нужно активировать mq на конкретных дисках. Самый простой способ сделать это глобально — добавить следующие параметры к строку параметров ядра:

scsi_mod.use_blk_mq=1 dm_mod.use_blk_mq=y

Для этого, скорее всего, нужно отредактировать /etc/default/grub, и переконфигурировать grub (зависит от дистрибутива).

Сменить I/O Scheduler по умолчанию можно параметром ядра elevator:

elevator=kyber
ValdikSS ★★★★★
()
Ответ на: комментарий от ValdikSS

А лучше еще добавить vm.dirty_expire_centisecs = 500.

При копировании с SSD на флешку за пять секунд в кеш гига два ухнет. А потом снова то же ожидание.

Dynamic writeback throttling

С флешками чуда не случилось. С HDD я тоже разницы не заметил. Но с HDD не было проблем, они достаточно быстрые.

kyber

Не пробовал. Судя по описанию, он должен помочь с отзывчивостью? Тут тема немного не про то. Тут хочется, чтобы при копировании на флешку было видно, сколько на самом деле записано на флешку. Сейчас проблема в том, что копирование доходит до 100%, а потом кеш потихоньку сбрасывается на флешку, и непонятно, сколько именно сбросилось в каждый конкретный момент.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

При копировании с SSD на флешку за пять секунд в кеш гига два ухнет. А потом снова то же ожидание.

У меня ограничение не только по времени, но и по максимальному буферу, он не может превышать 64 мегабайт:

vm.dirty_bytes = 67108864
vm.dirty_background_bytes = 16777216
vm.dirty_expire_centisecs = 500

Не пробовал. Судя по описанию, он должен помочь с отзывчивостью?

Нет, все просто: cfq не работает с writeback throttling нормально, поэтому подойдет любой другой, который работает (хоть стандартный deadline-mq).

ValdikSS ★★★★★
()
Ответ на: комментарий от ValdikSS

нужно активировать mq на конкретных дисках.

Вот только недавно задумывался — а одновременно (в одной системе, на разных устройствах) mq и sq могут существовать?

greenman ★★★★★
()
Ответ на: комментарий от ValdikSS

Сменить I/O Scheduler по умолчанию можно параметром ядра elevator

На mq это не работает. Можно только через /sys/block/sd*/queue/scheduler.

Кстати bfq кардинально улучшает отзывчивость системы запущенной с флэшки при записи на эту же флэшку.

qula
()
Ответ на: комментарий от ValdikSS

У меня ограничение не только по времени, но и по максимальному буферу, он не может превышать 64 мегабайт

Для флешки неплохо бы и 8 поставить. А для остальной системы — можно и побольше. Но ручка для регулирования только одна. Точнее, не одна, есть ещё возможность указать доли через max_ratio в /sys. Но эти настройки не работают для всех ФС.

cfq не работает с writeback throttling нормально, поэтому подойдет любой другой, который работает (хоть стандартный deadline-mq).

У меня выбран планировщик под названием mq-deadline. Он сам выбирается, когда mq включаешь. Но это не помогает ограничивать скорости записи на флешку, так как vfat не просит bdi установить жёсткий лимит.

i-rinat ★★★★★
()
Ответ на: комментарий от ValdikSS

В общем, я реализовал ограничение на размер несинхронизированных данных в секундах, в юзерспейсе через LD_PRELOAD: https://github.com/i-rinat/autofsync

Принцип работы состоит в запуске fdatasync() после того, как очередной write() запишет данных больше определённого лимита. Длительность fdatasync() замеряется, и лимит на ходу изменяется так, чтобы длительность была в заданных пределах. Так при записи на быстрый диск принудительных синхронизаций почти нет, зато при записи на USB-флешку они вызываются достаточно часто.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Идея отличная. Но для меня не работает. Может я недопонял. Решил применить по-тупому. Есть файл 123.bundle полгига, есть тормозная флешка на 1ГБ. Поведение неотличимо с\без autofsync.so

$ LD_PRELOAD=./autofsync.so rsync -a --stats --progress ./123.bundle /run/media/test/8BE2-1CBC/
sending incremental file list
123.bundle
    460,744,533 100%  318.85MB/s    0:00:01 (xfr#1, to-chk=0/1)
Killed

Т.е. происходит моментальное наполнение буфера со скоростью 318.85MB/s, далее процесс в состоянии D пишет полчаса на флешку.

$ ps ax | grep rsync
10903 pts/5    D      0:01 /usr/bin/rsync -a --stats --progress ./123.bundle /run/media/test/8BE2-1CBC/

Может я забыл чего-нибудь сконфигурировать, тогда буду перемерять. Спасибо

(Допускаю, что rsync не использует write() call)

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Победа

Midnight Commander работает, LD_PRELOAD=./autofsync.so mc

Такой плавности индикатора копирования я не видел с хорошо настроенного (буферы и задание принадлежности разделов разным шпинделям) total commander-а :)

(значит rsync мудрёный)

Deleted
()
Последнее исправление: Deleted (всего исправлений: 2)
Ответ на: комментарий от i-rinat

Блин, это гениально.

Спасибо тебе, добрый человек!

Deleted
()
Ответ на: комментарий от Deleted

(Допускаю, что rsync не использует write() call)

Вообще есть ещё функции, которые записывают данные, но rsync всё-таки использует write(). Дело было в том, что он сначала пишет во временный файл, который создаёт вызовом mkstemp(), а эту функцию я не перехватывал. Только разные варианты open().

Добавил перехват mkstemp(), теперь rsync тоже ограничивается.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Осталось невзначай запостить в lkml, autogroup же пихнули в ядро.

qula
()
18 ноября 2018 г.

Это не баг, это исчерпание кеша в ОЗУ, который последующие 20мин переносится на флешку.

torvn77 ★★★★★
()
Ответ на: комментарий от ValdikSS

Если я правильно понял «under memory pressure before OOM-killer triggers» (а так же «So, with the patch, it takes less than 1 second(with a spike of 4M/sec read during that time, seen by sudo iotop on dom0) to trigger OOM-killer instead of minutes of disk thrashing.» отсюда) это совсем о другой проблеме, когда OOM уже неизбежен. В моей же ситуации до OOM ещё пара гигабайт свободной памяти (в свопе, конечно, но в любом случае - до OOM ещё очень далеко).

В данный момент, насколько я помню мои последние тесты по данной теме, проблема в том, что частичное применение workaround-ов, например только vm.swappiness=100 и vm.min_free_kbytes=6144 без чистки автозагрузки, приведут к thrashing при попытке одновременного запуска мессенджера и браузера. Закономерно, даже применение всех workaround-ов, включая чистку автозагрузки, в итоге не избавляет от thrashing, а лишь делает его менее вероятным. И этого, к сожалению, оказывается недостаточным для уверенного использования устройства, без шансов получить зависшую из-за thrashing оболочку.

Тем не менее, не смотря на то, что похоже патч решает другую проблему, ваш комментарий в gist (на который я ответил) вселяет в меня осторожный оптимизм - возможно, что агрессивное выталкивание в своп это как раз то, что нужно с 1 ГБ ОЗУ (и возможно это то, что делает Windows 10, как минимум при таком количестве ОЗУ) потому что ранее именно движение в направлении освобождения памяти для выполнения запущенных программ дало наилучший, хоть и далекий от идеала, результат. В итоге, пожалуй патч действительно стоит проверить, не смотря на то, что он нацелен на решение другой проблемы.

RussianNeuroMancer ★★★★★
()

раньше вообще не догонял о чем речь - пока не стал использовать ssd... на hdd, а тем более ide hdd такой проблемы не было! этот косяк связан с твердотельными накопителями - при копировании с них врубаются тормоза

amd_amd ★★★★★
()
Ответ на: комментарий от RussianNeuroMancer

На всякий случай отмечу, что у меня ноутбук с 8 ГБ RAM и SSD, и при запуске виртуальной машины и браузера часто получаю нулевой отклик на несколько минут, приходится вызывать OOM с помощью sysrq+f.

Тесты проводил на этом же ноутбуке, с mem=2G, чтобы заметнее было.

ValdikSS ★★★★★
()
Ответ на: комментарий от amd_amd

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

nvidia
()
Ответ на: комментарий от ValdikSS

Проверил этот же патч, и тоже получил сверх-агрессивное выталкивание в своп (по-видимому гораздо более агрессивное, чем vm.swappiness = 100) что закономерно сделало систему неюзабельной, и почему-то привело к убийству Gnome Shell и aptitude OOM при достаточном количестве свободной памяти. Есть ли ещё какие-нибудь варианты для 1 ГБ ОЗУ, помимо vm.swappiness=100, vm.min_free_kbytes=6144 и чистки автозагрузки?

Кстати, сейчас по ходу повторного тестирования всего этого дела, но чисто с почищенной автозагрузкой и vm.min_free_kbytes=6144, без vm.swappiness=100 (оставлены дефолтные 60) обнаружил что в-принципе система тоже достаточно юзабельна, хотя сразу же после загрузки менее отзывчива, так как выталкивание неиспользуемых служб в своп ещё не произошло, и по-факту происходит по мере запуска используемого пользователем софта.

RussianNeuroMancer ★★★★★
()
Ответ на: комментарий от RussianNeuroMancer

чистки автозагрузки

Кстати. Что ты под этим подразумеваешь? Просто, не запускать лишнего?

Deleted
()
Ответ на: комментарий от RussianNeuroMancer

У вас ядро какой версии? Если новее 4.10, можете попробовать 4.9, 4.4? Есть подозрения, что в 4.10 что-то с подсистемой виртуальной памяти сделали.

ValdikSS ★★★★★
()
Последнее исправление: ValdikSS (всего исправлений: 1)
Ответ на: комментарий от Deleted

Подразумеваю отключение автозапуска ненужных на планшете с 1 ГБ ОЗУ сервисов, таких как Gnome Software, Gnome Tracker, Evolution Data Server.

RussianNeuroMancer ★★★★★
()
Ответ на: комментарий от ValdikSS

Завтра постараюсь проверить, но может помешать аховая ситуация с поддержкой Intel BayTrail в те времена. 4.4 заведомо не вариант, а вот 4.9 еще может сработать.

RussianNeuroMancer ★★★★★
()
Ответ на: комментарий от RussianNeuroMancer

Скомпилировал 4.9.147 ­— видеоподсистема зависает при запуске X, а с ней и ядро, по какой-то причине.

Dec 24 22:40:38 val kernel: NMI watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [Xorg:2590]

ValdikSS ★★★★★
()
Ответ на: комментарий от RussianNeuroMancer

Скомпилировал 4.9.140, видео заработало (нужно баг завести), и, внезапно, ОС нормально работает! Ничего не зависает, немного подтормаживает, но никаких фризов: программы продолжают откликаться, музыка играет и не заикается. Компьютером можно полноценно пользоваться, хоть и в свопе больше 2 ГБ уже. Пишу этот комментарий из такого состояния:

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           7866        7186          89         172         590         431
Swap:          7990        2244        5746

ValdikSS ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.