12309?

Как вызвать этот баг — забить всю оперативную память приложениями и начать копирование на флешку или другой съемный носитель.

Но зачем? Чтобы побороть этот баг, надо пересобрать ядро с патчами, тут всё зависит от конкретного компьютера, но для чего его нужно вызывать ещё раз? Даже если во второй раз произойдет настоящий 12309, это не значит, что в первый раз это был он.

У меня 27 гб свободной памяти. Нет дисковых операций. В iotop скорость записи была 4 мб/с. И я поймал его :)

Мля. У тебя поди dirty.ratio значения большие, только и делов. Это ты думаешь, что ты поймал баг, а на самом деле у тебя просто криво настроена система.

Ущерб, уже разработчики ядра признали, что во wiriteback коде ядра есть проблема bufferbloat: https://lwn.net/Articles/681763

Бро, бобро бомжаловать в клуб свистетелей ЕГО ЭТ САМОГО!

Да, оно самое.
у меня выскочило при копировании между блинам 2.5" сата.

да, / был на вертексе4, такие дела. [xeon1230/z97/32]

Тогда повара Убунты - кривые настройщики системы.
14.04 на тот момент.

что в ней настраивать?
накатил и забыл.
или ты предлагаешь ведро конпелять?

Нахрен конпелять ядро не надо. Надо просто подправить ratio кешей в сторону уменьшения, тогда ядро не будет жестоко тупить и попёрдывать от охренения. Алгоритмы рассчитаны на более слабые машины, а подправить сейчас либо тяму не хватает у народа, либо никому это не надо особо.

В кратце, это, конечно, похоже на 12309, но по факту трабла возникает из-за слишком больших кэшей, которые система просто начинает сбрасывать на медленное устройство и тупит. Пользуйтесь sysctl. Вообще на 27 игах оперативки 10% dirty data (пусть даже и от кол-ва общей свободной памяти) как-то овердохера. И вот когда эти 2 гектара начинают сбрасыаться на тупую флэху со скоростью в 10 метров в секунду - наступает оверзвездец, пока не сбросятся. Дело в том, что буфер пытается наполниться быстрее. А из-за особенностей алгоритма система еще и в своп может уйти. Проще всего в такой момент приостановить копирование, дождаться окончания сброса dirty на диск и продолжить операцию, или держать побольше памяти занятой (/me вспоминает сброс кэша в 16 гиг на медленный девайс на большой машинке и нервно хихикает).

А ты кукарекал бы еще больше. Эта проблема by design большей частью. И сказанное мной не отрицает того факта, что системе всё равно надо урезать объем dirty на большом количестве ОЗУ.

Что на самом деле системе надо делать по ссылке разработчики ядра тоже написали.

гугли на тему лаги+ntfs+linux. Старая хрень...

вот норм статья https://habrahabr.ru/post/116601/

Вот анонимус выше описал вроде толково появление сего лаго-глюка.
Но и от нтфс никуда не убежать. Даже если венды нет, то ФС вполне может быть нужна.

насколько статья релевантна?
прошло уже 5 лет с момента публикации 1апр2011.

т.е. кто-то же должен был запостить репорт по профилю.

scsi_mod.blk_mq=1 и все.

Херь это полная, ничего уменьшение dirty.ratio не помогает.

Ага, если бы.

Так ты не пробовал.

ну пусть ТС отпишется, у меня нет НТФС )))

Правда штоле?

# cat /proc/cmdline
BOOT_IMAGE=../vmlinuz-4.5-x86_64 root=/dev/sda2 rootflags=subvol=root/manjaro-embryo,compress=lzo rw scsi_mod.use_blk_mq=1 zswap.enabled=1 quiet nosplash initrd=../initramfs-4.5-x86_64.img

спуфинг-моде:

хипстота, понакупает ядер с гектарами, а потом плачется... со своими кремний-проблемами.

мониторы, мониторы покупать надо!!!

То, что там написали - моим словам никак не противоречит на данный момент. В новых ядрах фиксится.

dd, без фс

Если у тебя _очень_ медленные устройства - тебе поможет только специальный патч. Есть в составе pf. Можешь еще увеличить таймауты сброса грязных данных на диск. Чтобы одновременно писалось только в один поток. Тогда увеличивай dirty ratio. Проблема заключается в том, что устройство, на которое идёт запись получает тонну одновременных запросов, а ядро тупит из-за особенностей этого алгоритма. Всё, что можно сделать - наложить патч соответствующий или попытаться минимизировать проблему за счет установки адекватных параметров через sysctl.

У меня даже при активной работе с ssd фризы начинаются.

zswap.enabled=1

Поражаюсь. А эта дрянь может и еще больше усугубить баг (почему - предлагаю догадаться самому). Ну так, к сведению. Кроме того, смысл в ней вообще сомнителен без большого кол-ва RAM (от 8 Гб и выше). То же относится и к zram.

У меня даже при активной работе с ssd фризы начинаются.

И будут, пока noop вместо планировщика не поставишь.

Ставил, только ещё хуже было. Сейчас вообще без планировщика. Стало получше, но всё равно.

Не может.

Ставил, только ещё хуже было. Сейчас вообще без планировщика. Стало получше, но всё равно.

Вообще-то noop - это и есть отсутствие планировщика. Скорее, у тебя SSD работает с особенностями и жёстко снижает скорость записи время от время от времени. Тогда интересны юзкейсы.

Со скоростью самого ssd всё нормально. Это система фризится.

Может. Это еще один буфер в ОЗУ. С которыми у линуха и так не очень в отдельные моменты времени. Понимаешь, проблема в ядре, которое не умеет нормально приоритеты сброса на блочное устройство. Можешь ядрышко и посвежее собрать, скажем так.

it basically won't start before the buffered writeback is done

Собственно, запись в своп - тоже еще один поток, если у тебя пространство в оперативке под zswap закончилось - лови 12309.

сушайте, я тут уже проникся идеей быстрофикса.

втулить 2 планки по 4ГБ и все само собой заработает.

Zswap просто сжимает страницы перед сбросом в своп. Он не помещает своп в оперативки.

Если у него проседает скорость записи перед скоростью чтения (а такое возможно, когда trim еще не успел отработать, а запись идёт в блоки, которые нужно очистить - SSD вместо операции записи выполняет чтение -> стирание -> запись), тогда при переполнении буферов происходит как раз оно же самое. Ну и плюс ко всему, запись в общем-то медленнее. Можно вместо ratio (оно, кстати, считается не от объема всей памяти) установить вменяемое vm.dirty_background_bytes = 0 - ну, метров 100 скажем.Тогда тупить будет много меньше, т.к. writeback будет завершаться до того, как система словит тупняк.

Zswap is a lightweight compressed cache for swap pages.

https://www.kernel.org/doc/Documentation/vm/zswap.txt

Да, прямо таки не помещает в оперативку. Ну-ну.

Чем больше оперативки - тем больше вероятности словить эту хрень.

Тем временем, https://github.com/pfactum/pf-kernel/commit/d37efc32606a2009f2d288499965cafa2...

Да-да. Вот именно об этом я и говорю.

Добавлю:

я писал с помощью dd — т.е. никаких фс не использовал на накопителе:

dd if=myiso.iso of=/dev/sdX

Это не на уровне ФС баг. Совсем не на уровне ФС. Можешь глядеть atop к примеру, в этот момент и увидеть, после какого момента у тебя dirty data достигает максимального значения и запись начинает идти не в один поток, а в несколько.

Можно vm.dirty_background сделать _больше чем vm.dirty - это решает проблему несколько другим способом.

Неа, он как zram работает, только менее костыльно и с испралением недочётов.

Да, так и должно быть (на самом деле нет, но сиправлять, кажется, никто не собирается), ставь другой приоритет dd, пониже.

А вообще есть патч.

http://lwn.net/Articles/681763/

И вот ещё статья с объяснением и комментами: https://lwn.net/Articles/682582/

Позже сниму скринкаст с поведением системы при копировании большого файла с HDD на SSD и обратно.

Странно, проблем на рабочей машине не обнаружил

с HDD на SSD и обратно.

А еще cat /proc/meminfo sysctl -a | grep swap sysctl -a | grep dirty

и размер копируемых файлов.

В любом случае, пища к размышлению здесь: https://lwn.net/Articles/682582/