LINUX.ORG.RU

12309 в 4.10.14?

 , , , ,


1

5

Делаю бэкап с Btrfs RAID-1 (4 HDD разного размера) на ext4 USB-HDD rsync'ом. И когда копируется примерно 580 ГБ из 662, вся система виснет намертво. По ssh не зайти, даже SysRq не всегда работает (или я с ума сошёл?). Своп практически не используется (400мб), память (12 ГБ) полностью уходит под кэш и буферы. Пытался делать ionice -c2 -n3, делать rsync --bwlimit=30000. Не помогает.

Самое смешное, что это первый раз, когда я столкнулся с 12309. Это точно оно? В какую сторону копать? Как дела сейчас с планировщиками?

Fedora 25.
4.10.14-200.fc25.x86_64

UPD. Сейчас посмотрю, включен ли в федоровском ядре Writeback throttling.

UPD2. Действительно, не вполне включен:

CONFIG_BLK_WBT=y
# CONFIG_BLK_WBT_SQ is not set
CONFIG_BLK_WBT_MQ=y
Надеюсь, что проблема в этом. Завтра пересоберу ядро.

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



Последнее исправление: SIvan32 (всего исправлений: 5)

12309

Btrfs

RAID

Fedora

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

r3lgar ★★★★★
()

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

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

gasinvein ★★★
()

Same shit.

Fedora 25.

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

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

EXL ★★★★★
()

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

Deleted
()

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

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

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

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

dada ★★★★★
()

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

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

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

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

narkoman228
()

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

vm.dirty_bytes = 66554432
vm.dirty_background_bytes = 33554432
И выполните:
sudo sysctl --system

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

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

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

SIvan32
() автор топика
Ответ на: комментарий от SIvan32

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

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

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

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

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

2017

телек

Тивоизация

Ну ты понял.

anonymous
()
Ответ на: комментарий от SIvan32

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

scsi_mod.use_blk_mq=1
в качестве параметра ядра.

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

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

SIvan32
() автор топика
Ответ на: комментарий от ValdikSS

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

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

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

ValdikSS ★★★★★
()

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

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

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.