The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."
Отправлено Аноним, 06-Дек-23 07:53 
> RH активно продвигал xfs, не слышал, чтобы они отказались.

0) Из RH удрапало дофига блочников и файлушников. Воооон там вокруг btrfs теперь тусят, лол.
1) Btrfs в федору втянули.
2) XFS - такая сова на глобус что там аж майнтайнер удрапал в панике не так давно. Его роботы багами засыпали в хламину, он и промямлил - мол XFSv4 код дидов такой крап что когданить потом пофиксим его, путем дропа, останется только v5. Но впрочем даже это будут пытаться другие.
2.1) И да, они там героически упираются хотя-бы аналог scrub запилить. При том уже несколько лет. Видимо идея делать вот именно fsck, именно при загрузке, вообще легаси пованивает с одной стороны, а проверять состояние данных в рантайм с другой стороны - как-то более актуально, ибо какие-нибудь серваки и что там еще могут ребутать не очень то и часто, да и время этой операции по всей площади - изрядное. Одно дело фоновое чтение с idle приоритетом, другое - что-то там чекать при загрузке и проч.
3) Пойнт вон той камасутры для меня загадка. Сколько это УГ не гальванизируй, btrfs/bcachefs по управлению из ЭТОГО не получится. А все эти сратисы с пыхтонрасом и этажеркой LVM/MD/DM/... - могу себе представить как это будет работать. Особенно если в процессе менеджмент операции питание слетит или там что еще.

Говоря за себя - меня тот блевотный менеджмент который редхат пытался сватать - вообще совсем не устроит после того как я Btrfs попробовал. Вот эти сделали управление файлухой и пространством так как это и должно было быть на самом деле.

> Остаётся разве что Fedora, понаблюдаем.
> Но у меня пока ощущение, что скорее bcachefs допилят до готовности к
> проду в многодисковых конфигах, чем btrfs.

Ну вот в данный момент времени я btrfs использую в вполне "продакшновых" сценариях, а bcachefs - ну я там уже пару багов отхватил. Но его только комитнули и это нормально.

И да, если кто думает что Кент все идеально предусмотрел... вон там уже блаблабла на тему того что надо б инверсные индексы на манер btrfs'ных backrefs, а то скорость операций менеджмента что-то дескать "не очень". При том этого еще нету на уровне структур и проч даже. У него еще есть прикольная штука - erasure coding. Но и это WIP жесточайший.

Btrfs-ники так то тоже свое дело делают. Недавно запилили bg_tree с которым btrfs маунтится аж быстрее ext4 (и bcachefs). На механике, VM или медленных флехах бывает довольно заметно. И какие-то расширения RAID56 пилят в фоне, дабы write hole более радикально заделать. Но у них core дизайна куда стабильнее если RAID56 не надо, имхо. Это уже продакшновый дизайн, видавший ломовые нагрузки уровня FB и проч. И основные самые жирные баги в нем - уже отловлены. В отличие от вон того - там поток багов такой что Kent почти каждый -rc прилично фиксов насыпает. Но это нормально в данный момент времени.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
  Введите код, изображенный на картинке: КОД
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру