Покажи(дождись окончания записи, естественно):

time (dd параметры && sync)

И посчитай сам среднюю скорость(на скорость, которую вернет dd внимания не обращай)

скорость плавает между 100kb и 10mb, лью dd образ, он сначала разгоняется до 10mb, затем падает до 100kb, затем опять поднимается до 10mb и далее по кругу

если вы знаете фикс, то поделитесь пожалуйста

Никто в мире не знает фикс. Это известная проблема Linux.

Есть несколько костылей, вроде vm.dirty_bytes=16M/vm.background_dirty_bytes=8M или синхронной записи, но это не фикс.

Дело вообще не в этом. А в том, что writeback-кэш трешится и скорость плавает.

нет у этой флешки никакого writeback кэша (

не было сил ждать, прервал:

[root@PC01 ~]# time dd bs=32768 if=/mnt/raid/USB_FLASH_4GB.img | pv  | dd of=/dev/sdd
^C40791+0 записей получено] [                                          <=>                                                                                  ]
40790+0 записей отправлено
1336606720 байт (1,3 GB, 1,2 GiB) скопирован, 317,238 s, 4,2 MB/s

2610361+0 записей получено
2610361+0 записей отправлено
1336504832 байт (1,3 GB, 1,2 GiB) скопирован, 333,026 s, 4,0 MB/s

windows
arch

Гентушников зачем скастовал?

vm.dirty_bytes=16M/vm.background_dirty_bytes=8M

Синдром утенка как он есть.

Есть несколько костылей ...

У меня арч весь в костылях ... Может тебе известно , когда это закончится ?

у меня «замороженная» gentoo живёт в 4-ом разделе, правда года полтора не обновлял, но ей уже там лет 5

Я не спорю с тем, что это костыль.

Кэш в ОС.

Костыль это или нет, он предназначен для решения другой проблемы.

Только bs, наверное, для девайса, а не для образа.

bs побольше накрутить, можно пару метров. Проще использовать суффиксы K, M или G чтобы самому не считать. А ещё есть status=progress

Какой? Назови.

И охота каждый раз новую тему делать

Запись на флешку: скачок и подвисание.

Выноса страничного кэша при записи на медленное устройство. А ТС спрашивает о том, почему у него запись на устройство медленная.

Протестил эту флешку на другом компе с дуалбутом (арч/винда), в винде запись ~12mb в секунду, в линуксе dd ускорился почти вдвое с oflag=dsync

[root@PC01 ~]# time (dd bs=32K count=25000 if=/mnt/install/TEST.img of=/dev/sdb && sync)
25000+0 записей получено
25000+0 записей отправлено
819200000 байт (819 MB, 781 MiB) скопирован, 114,79 s, 7,1 MB/s

real	1m55,005s

[root@PC01 ~]# time (dd bs=32K count=25000 oflag=dsync if=/mnt/install/TEST.img of=/dev/sdb && sync)
25000+0 записей получено
25000+0 записей отправлено
819200000 байт (819 MB, 781 MiB) скопирован, 65,2515 s, 12,6 MB/s

real	1m5,345s

это тоже помогло, так даже лучше стало и без oflag=dsync

[root@PC01 ~]# time (dd bs=32K count=25000 if=/mnt/install/TEST.img of=/dev/sdb && sync)
25000+0 записей получено
25000+0 записей отправлено
819200000 байт (819 MB, 781 MiB) скопирован, 62,7218 s, 13,1 MB/s

real	1m3,947s

спасибо

А ТС спрашивает о том, почему у него запись на устройство медленная.

ТС спрашивает о том, почему у него скорость плавает. Это именно проблема трешинга кэша. Сначала ты читаешь в оперативную память, забиваешь её, потом достигаешь dirty_ratio и скорость падает до околонуля, потому что система одновременно сбрасывает старый кэш и пытается писать новые данные.

да, скорость плавала и была низкой из-за системного кэша записи, плюс сама флешка трешак лютый - на записи мелких блоков, виндовые тесты показывают 2 iops'а

я на неё установил арч, забэкапил, потом с неё же стал закачивать в хроме ядро с kernel.org, система стала колом и слетела, а при восстановлении образа через dd увидел непонятки со скоростью

теперь, когда стало ясно в чём причина, я изменил параметры ядра и монтирования rootfs на ней, тупняки с зависонами ушли

vm.dirty_background_bytes = 4194304
vm.dirty_bytes = 4194304

rw,noatime,thread_pool=3,compress=zstd,ssd_spread,flushoncommit,nospace_cache,commit=1

Вопрос решён, благодарю Pinkbyte, intelfx и onlybugs(за status=progress) - счастья вам, добра, процветания!

4 МБ/с - нормальная скорость для большинства юсб2.0 затычек. особенно - дешманских, с одноканальной TLC.

юсб3.0 - как повезет, на запись могут быть такими же тупыми, но хоть читаются веселее.

Сначала ты читаешь в оперативную память,

Ok.

забиваешь её

Никаких причин предполагать это нет, объем данных - 819М.

потом достигаешь dirty_ratio

Нерелевантно.

и скорость падает до околонуля

Только «трешинг кэша» не имеет к этому отношения. К этому моменту в памяти много данных, предназначенных для записи на устройство - это идеальные условия для быстрой записи.

потому что система одновременно сбрасывает старый кэш и пытается писать новые данные.

Если она «сбрасывает» и «пишет» на одно устройство, т.е. флешку - наверное, наблюдаемая в dd скорость снизится. Но я как-то сомневаюсь, что у ТС на флешке живет что-то кроме целевого файла.

Если речь о флешке с FAT, то просто переформатируй в ext2, разница будет заметна.

Никаких причин предполагать это нет, объем данных - 819М.

В исходном посте размер образа 4G, дефолт dirty_ratio = 40.

Нерелевантно.

Релевантно.

Только «трешинг кэша» не имеет к этому отношения. К этому моменту в памяти много данных, предназначенных для записи на устройство - это идеальные условия для быстрой записи.

Ок, я снова не совсем корректно выразился. Но мы в любом случае говорим об одном и том же явлении. К тому же, как ещё назвать явление, когда любая попытка буферизованной записи сколь угодно малого объёма приводит к блокировке на синхронный сброс кэша?

Если она «сбрасывает» и «пишет» на одно устройство, т.е. флешку - наверное, наблюдаемая в dd скорость снизится. Но я как-то сомневаюсь, что у ТС на флешке живет что-то кроме целевого файла.

Не вижу, как второе исключает первое. Наблюдаемая в dd скорость падает, именно в этом и состоит вопрос ТС.