> Это не 12309. Это кривая реализация планировщиков ввода- вывода. Причем любого, перепробовал
> все, нет ни одного нормального.

Жжошь! Эксперт системный, my a$$! Если смена планировщика не помогает - возможно, было дело не в нем?! Как минимум в старых ядрах был весьма специфичный прикол с page cache vs mem alloc.

Идея примерно такая: юзер пишет 100500 гигз на тормозной носитель типа флехи с скоростью записи мег в секунду. Ядро выделяет огромный дисковый буфер почти на всю оперативу для ускорения операции. Софт радостно отваливает т.к. буферизованая запись типа-закончилась (для операции записи у софта). Это неспешно спихивается на тормозную флешку, которая быстро не умеет. А тут приходит прога и требует дать ей гигаз рамы. Он как бы в теории есть, только занят вон тем добром. Ядро начинает чистить page cache пытыясь обеспечить проге аллокацию. Но поскольку флеха медленная, это занимает чертову тучу времени. Прога при этом висит на попытке аллокации памяти. А какие у кернела варианты? Либо дать память, либо обломать аллокацию, на что большинство прог довольно плохо реагирует.

В новых ядрах это пролечили - запретили тормозным носителям слишком большие буфера отращивать, оно так и разучилось прикалываться. Но наверняка возможно придумать более 9000 других способов сделать что-то странное. Поэтому 12309 - починен. А тупари думающие что у них вон тот баг могут еще 20 лет фикса ждать. Потому что про их баг (который другой) тупо никто не в курсе. А опеннет - не багтрекер и не мыллист кернела.

> И что самое интересное, если записывать любую загрузочную флешку, то ничего не тупит.

Используя dd чтоли? Там буферизация заметно иначе будет происходить нежели на уровне ФС. Однако некомфортный буфер vs тормозную флеху и так можно огрести. Но это тормозит только то IO.

> Данные пишутся и там и там, но там тормозит при записи, а здесь нет.

Логично - кэширование ФС при этом не у дел.