LINUX.ORG.RU

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

 ,


5

5

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

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

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

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


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

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

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

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

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

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

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

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

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

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

Ну я и не сомневался, чо кедорасты с винды слижут всё, что криво лежит. Когда акрил ждать?

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

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

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

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

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

bodqhrohro_promo ()
vm.dirty_bytes = 66554432
vm.dirty_background_bytes = 33554432
vm.dirty_ratio=10
vm.dirty_background_ratio=5
bdfy ★★★★ ()
Ответ на: комментарий от bdfy

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 ()
Ответ на: комментарий от Black_Shadow

Головастик, расскажи, зачем нужен своп на десктопе с например 16 гигами оперативы ?

spider_russia ()
Ответ на: комментарий от 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)

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

Победа

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

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

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

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

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

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

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

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

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

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

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

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

qula ()

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

torvn77 ★★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)