12309

Btrfs

RAID

Fedora

Почему меня это не удивляет?

примерно 580 ГБ из 662

Может на одном харде бэды на этом участке?

12309 - когда вы сталкивались последний раз? (комментарий)

Same shit.

Fedora 25.

При копировании на флешку в NTFS — жуткие баги и тормоза, система на время копирования файла стала однозадачной. При этом SSD, 16 GB RAM, i7 весь фарш в общем.

P.S. Форматнул флешку в FAT32 — баги чудесным образом прошли.

Да, ntfs-3g это дичь, лучше ext2fsd в венде поставить.

У меня было такое до перехода на blk-mq и внедрения writeback throttling, сейчас вообще красота, никаких фризов, даже самых маленьких.

Рекомендуют следующее:

баг проявляетсяя просто: когда у тебя кол-во dirty pages превышает vm.dirty_ratio или vm.dirty_bytes то ось начинает сброс страниц на диск с принудительной остановкой всех пишущих на диск процессов до полного окончания операции. В этот момент wa, по-моему, высок. Часто в dmesg вылезала хрень о том что task blocked for more than 120s (это если у сервера много оперативы). Вот как раз на бэкап-серверах оно частенько и вылезает. Мы с этим шаманили какими-то самопальными скриптами которые ionice выставляли, пишущие процессы останавливали если диск не справлялся итп. В общем, для бэкап-сервера это не смертельно, а вот для боего писец.

Если это бэкап-сервер то воткните свежую ось с ведром 3.2+, на лоре говорили что это помогает (сам не тестил)

я так понимаю переехать на 3.2+ для тебя не очень актуально. Вот сама тема: Обнаружить 12309

Что-то какое-то оно у тебя сильно специфичное - баловался федоркой на обычном десктопном железе - не заметил этого явления.

RAID же.

Ну может да, я так глубоко не залазил. И БТРФС оно уже из альфы вышло?

По мнению разрабов? Да, поставляют штабельные сборки.

По мнению юзверей? Нет, оно фрагментируется и тормозит. Хотя задумка мне нравится. Но вот этот тред пока что говорит мне оставаться на ext4.

Создайте файл /etc/sysctl.d/60-dirty.conf со следующим содержанием:

vm.dirty_bytes = 66554432
vm.dirty_background_bytes = 33554432

sudo sysctl --system

Фишка именно в 4.10

Про этот метод я слышал, но ведь заявлялось, что в 4.10 12309 опять окончательно пофиксили. Или нет? Сейчас ядро компилится с опцией CONFIG_BLK_WBT_SQ=y. Если не поможет, то сделаю, как Вы говорите.

Так и есть, но для этого действительно ядро должно быть собрано с указанной вами опцией.

Увы, перекомпиляция не помогла. Опять всё зависло, на этот раз на 604 ГБ. Может быть это не 12309?

Способ с файлом попробовали? Мониторьте все через atop.

Да, ntfs-3g это дичь, лучше ext2fsd в венде поставить.

Винду можно вообще не ставить. А вот на телек, читающий флешки только в ntfs, никакой ext2fsd не поставить, приходится мучиться с ntfs-3g.

2017

телек

Тивоизация

Ну ты понял.

Кстати, вроде, перекомпиляция не требуется, достаточно передать

scsi_mod.use_blk_mq=1

Попробую так сделать. Настроил kdump, надеюсь, что sysrq+c будет работать и я смогу потом посмотреть дамп и backtrace.

Не поможет — 12309 никогда в ядре не исправляли. Просто железо более новое стало, и на новом железе этого бага может и не наблюдаться. У меня же везде оно есть. В том числе и на относительно свежем компьютере, купленном всего-то в конце прошлого года!!!

Баг вызван, прежде всего, большими буферами при копировании файлов. Их можно уменьшить, и все станет гораздо лучше. В Linux 4.10 добавили автоматическое управление буферами.

12309 есть в macOS и Win10?

Своп практически не используется (400мб)

Да хоть 1мб, хоть 500кб, это же HDD.

Writeback throttling включен хоть?

Понятия не имею, что это. «Из коробки» все должно работать нормально, без тормозов. А не так, как сейчас: копируешь с диска на флешку или обратно, и можно идти пить кофе — пока не закончит копирование, работать невозможно. А уж когда генту начинаешь обновлять, вообще труба!