>[оверквотинг удален]
> и в процессе использования в самых разных условиях. Даже обнаружил, что
> существуют странные баги, которые почему-то осознанно игнорируются десятилетиями. Но
> потери данных вещь достаточно невероятная (хотя и реалистичная), в основном, из-за
> новых багов ядра можно ожидать. Самое страшное -- это повреждение журнала,
> при этом структуры окажутся повреждены совершенно непредсказуемо, и проверка fsck займёт
> достаточно много времени (ещё и несколько раз перезапустится в процессе). А
> вот с xfs у меня терялись данные, например, хотя большинство её
> поклонников будут уверять, что это невозможно (несмотря на официально регулярно повторяющиеся
> ситуации с потерями файлов). Правда, файловые системы без fsck… Нет, не
> стоит.Уф. Оценить "репрезентативность выборки" и "релевантность условий" на основании собственного опыта примерно "нельзя". Как соотносятся "надежность ФС" на физическом сервере в кладовке под нагрузкой "аждымицца!" и надежность той же самой ФС на виртуалке в ЦОДе в составе LB-кластера с автомасштабированием? Да никак не соотносится - в одном случае может регулярно сыпаться с последствиями, в другом - стабильно работать годами.
В общем случае - "надежность работы ФС" оказывает не то, чтобы большое влияние на надежность хорошо спроектированной _системы_. Ну вот заглючил на СХД два месяца назад FC-порт - расфигачило SQL-сервер с 10 Тб данных - повлияло это на работу системы? Да нет, автоматом переключилось на другую геореплику, пересоздали виртуалку, залили бэкап, догнали лог - и даже не уверен, переключили ли нагрузку обратно. Чем\как бы тут помогла btrfs, fsck или другая абэвэгэдэ?
Не то, чтобы мне было "совсем пофиг" на "надежность ФС" при проектировании ИС - но "примерно пофиг", да. Даже в отдельную строчку модели угроз не выделяем идет в составе "вероятность выхода из строя узла" или как-то так.
|
