> написаны и для более старых версий ядра и даже исправлялись уже многократно,

Где-то примерно в 3.18 и ранних RC 3.19 было много факапов с "гонками". Не только в btrfs но и вообще. Это всех задолбало и после 2 или 3 rc 3.19 всему этому безобразию разработчики дали бой. Поводом послужили странности в работе одной из машин у разработчиков. И хотя этот баг не нашли, под горячую руку загасили все что хоть отдаленно его напоминало.

К релизу 3.19 разработчики вроде как победили и замахали все что я видел. И заскоки btrfs-ных воркеров при сжатии, и странные гонки в ядре и чего там еще. Ну и 3.19 у меня работает на ура. На данный момент некоторые машины с 3.19 и btrfs обладают аптаймом порядка месяца, что как бы намекает.

> а все еще есть в этих модулях и до сих пор эти модули признаны зоопарком багов.

У вас есть проблема: сторонний модуль ядра от виртуалбокса. Отвечать за такое ядро имхо мало кто подпишется. Разве что оракл, который умеет в основном копипастить у редхата патчи.

> По btrfs я сейчас юзаю ядро 3.19, вчера оно зависло когда virtualbox
> стал на разделе с btrfs ставить в виртуалку офтопик

А откуда вывод что завис именно btrfs? Есть какой-то бэктрэйс где засветился именно он? А то virtualbox еще и свой модуль ядра в систему прет и что там этот модуль делает... ну лично я по этой причине KVM предпочитаю. Там нет левых побочных модулей ядра.

> btrfs как с виртуалкой не дружил, так и не дружит. Пришлось nodatacow врубать,

Оно как бы да - CoW-based диски виртуалок не очень хорошо дружат с CoW файловыми системами. Но кой-как работать - должно. Хоть и фиговенько. Если совсем виснет - это баг.

> хотя фc давно можно было научить хотя бы самостоятельно это обнаруживать

Не, спасибо, искусственный интеллект и бизнес-аналитику в файловую систему встраивать все-таки не надо, имхо. Виртуалки и БД - два отдельных частных случая, которые по любому требуют от пользователя некие базовые навыки администрирования и изучение некоторых базовых вещей, e.g. особенности работы CoW и снапшотов.

> были откровенные баги и хоть их поправили, я с 3.17 переехал
> на 3.19. Да, кстати пользую сжатие.

Ну вот в ядрах начиная с чего-то типа 3.17 и до 3.19-RC-что-то-там btrfs мог словить клин при использовании сжатия, поскольку его переводили с самописной реализации фоновых работ на штатные возможности ядра, которые с некоторых пор там появились. Как и полагается по законам жанра, большие перетряски не прошли без пары факапов, которые случаются редко, но метко и потому не попались при тестировании, но стали иногда покусывать пользователей при долговременной эксплуатации на большом количестве машин, что позволило заметить некие корреляции и вычислить проблему :)

> как я баг отправлю если зависон ядра в логах оставляет чистый лист?

А что, виснет настолько что даже Alt-SysRq-R-E-I-S-U-B не работает? Btrfs в 3.17-18 только проц начинал грузить, но система оставалась живой и можно было в top увидеть что проц трескает ядерный воркер, а не что-нибудь еще.

> "ядро 3.19 виснет по непонятным причинам!".

Как ни странно, такое тоже бывает и не всегда просто локализовать причину.

Одна из самых назойливых статей зависонов и проблем - сторонние модули, особенно проприетарные. Они как-то исторически очень бажные. Впрочем, даже открытый модуль, если он не в майнлайне - это уже заявка на проблемы. В майнлайн что попало не берут и на это у них есть причины. В виде набитых шишек. Поэтому если какой модуль вне ядра или даже в ядре но в staging - это потенциал для проблем.

> не знаю какие. SW-IOMMU и переполнение буфера началось еще в 3.18
> и оно давно в багтрекере есть.

Это что за баг? У меня на некоторых машинах есть IOMMU, но он железячный.