The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Код Bcachefs принят в основной состав ядра Linux 6.7, opennews (??), 31-Окт-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


152. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +2 +/
Сообщение от пох. (?), 31-Окт-23, 17:00 
угу - уже можно обойти вокруг btree и спеть песенку или рассказать сказочку о виличии хруста.

Как обычно, в общем.

Расслабьтесь, не взлетит, а если и да - япнется недалеко да все больше вниз.

Ответить | Правка | Наверх | Cообщить модератору

175. "Код Bcachefs принят в основной состав ядра Linux 6.7"  –1 +/
Сообщение от Аноним (176), 31-Окт-23, 19:04 
Еще как взлетит. В Btrfs и Bcachefs очень все круто продумано, за ними будущее наравне с мегастабильной и быстрой ext4 для простых сетапов. Ту же ZFS лучше даже не пытаться использовать из-за переусложненной архитектуры, даже кластеризацию не продумали на уровне фс, а понаписали-то 30 лимонов строк кода. Я уж молчу про потерю производительности на волюмах через некоторое время использования, после чего требуется аж пересоздавать тома. В особенности если планируется создавать кластерное решение, то сейчас лучше для нижнего уровня использовать Btrfs или ext4, но никак не ZFS.
Ответить | Правка | Наверх | Cообщить модератору

182. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +1 +/
Сообщение от Аноним (182), 31-Окт-23, 20:13 
Экстенты не вчера придумали, и если разрабы ЗФС решили что они им не нужны, то наверное у них были для этого основания. Я сомневаюсь что они глупее опеннетовского анонима. У той же виндовой НТФС экстенты например есть, только это почему-то не добавило ей ни скорости, ни устойчивости к фрагментации.

> Ту же ZFS лучше даже не пытаться использовать из-за переусложненной архитектуры

Лол, можно подумать что БТРФС и бкэшфс не точно такие же комбайны, с той только разницей, что сделаны какими-то мутными криворукими двоечниками ))

Ответить | Правка | Наверх | Cообщить модератору

194. "Код Bcachefs принят в основной состав ядра Linux 6.7"  –1 +/
Сообщение от Аноним (176), 31-Окт-23, 22:49 
Btrfs, вот это наиболее оптимизированный комбайн, более современный, там всё замечательно работает. На текущем этапе Btrfs очень стабильна, рекомендую под серьезный продакшн, чего не скажешь о ZFS, где за много лет так и не решили проблемы с фрагментированными блоками и потерями производительности на волюмах.
Ответить | Правка | Наверх | Cообщить модератору

280. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +/
Сообщение от t (??), 01-Ноя-23, 15:59 
но у btrfs есть недостаток - на ней нормально образы виртуалок не покрутить.
Ответить | Правка | Наверх | Cообщить модератору

219. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +1 +/
Сообщение от Аноним (-), 01-Ноя-23, 03:52 
> Экстенты не вчера придумали, и если разрабы ЗФС решили что они им
> не нужны, то наверное у них были для этого основания.

Когда ZFSники дизайнили свое нечто, экстенты только-только появлялись и входили в оборот. А основанием может быть и "как проще было". Когда некто делает чуть ли не ПЕРВЫЙ дизайн такого рода это тоже аргумент, иначе можно надорваться.

Но потом если идея была хоть немого дельной придумает как сделать v2/nextgen идеи, с учетом факапов - сделав лучше чем было до. Так и появился btrfs. Цикл повторяется. Кент посмотрел на проблемы btrfs и сделал bcachefs. Это уже стало быть gen3 технологии в каком-то роде.

> Я сомневаюсь что они глупее опеннетовского анонима. У той же виндовой НТФС
> экстенты например есть, только это почему-то не добавило ей ни скорости,
> ни устойчивости к фрагментации.

Но btrfs не требуются гигазы кешей чтобы нормально работать, так что ей реально пользоваться даже на мелочи. А ZFS без гигз на кеш вообще лучше не трогать. Потому что этому месиву без экстентов не с чему быть быстрым "самому по себе". А то что рамдиски быстрые никто и не сомневался, но это не заслуга структур ФС.

Штуке кента тоже гигазы не потребуются. И вообще почему-то ZFS на цитаты никто расхватывать не хочет. Потому что проблемный и кривой дизайн, с которым только героические многолетние мучения костыляторов хоть немного это вытянули.

>> Ту же ZFS лучше даже не пытаться использовать из-за переусложненной архитектуры
> Лол, можно подумать что БТРФС и бкэшфс не точно такие же комбайны,
> с той только разницей, что сделаны какими-то мутными криворукими двоечниками ))

Почему-то они однако гибче и больше современных возможностей. А ZFS потребовалось цать лет чтобы рефлинки несчастные накодить. Которые в btrfs к тому моменту уже лет 10 были. Или даже больше, я со счета сбился. Да даже в XFS сову на глобус натянули быстрее, хоть он и не cow изначально. Это вообще уж позор, господа, ZFS-а сделали на его же поле некромансеры с классикой?! КапецЪ!

Ответить | Правка | К родителю #182 | Наверх | Cообщить модератору

243. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +/
Сообщение от Аноним (243), 01-Ноя-23, 08:12 
Все эти "фичи" ничто по сравнению с проблемой "write hole".
А она решена только(!!!) в ZFS.
Альтернатива лишь одна - дорогие HW RAID контроллеры с батарейкой.

Новомодные FS созданы пока лишь для потери данных.
Да, вероятно, очень быстрой и с рефлинками.

Ответить | Правка | Наверх | Cообщить модератору

256. "Код Bcachefs принят в основной состав ядра Linux 6.7"  –1 +/
Сообщение от Аноним (244), 01-Ноя-23, 09:50 
> Все эти "фичи" ничто по сравнению с проблемой "write hole".

Вам не приходило в голову что сценарии использования, а потому и проблемы и приоритеты у разных людей могут быть разные?

> А она решена только(!!!) в ZFS.

Простите, у btrfs например нет никаких особых проблем в RAID1 на эту тему. А еще есть нормальный менеджмент, когда можно подоткнуть девайс, вынуть, изменить схему хранения, и все это на ходу, шустро и относительно безопасно. А всякие RAID5/6/etc - это довольно нишевые развлечения by design.

> Альтернатива лишь одна - дорогие HW RAID контроллеры с батарейкой.

Бла-бла-бла. Теперь сделайте мне так чтобы мой ноут не подыхал от одного бэда. А, не можете? Ну тогда идите в пень, сапожники бессапожные. Нафиг мне технология которая даже мою задницу обслужить не может? Чтобы сидя с голым задом рассуждать что где и чего бороздит?

> Новомодные FS созданы пока лишь для потери данных.
> Да, вероятно, очень быстрой и с рефлинками.

Что-то пока ничего не потерялось. Сколько уже лет мне это обещают - я и забыл.

Ответить | Правка | Наверх | Cообщить модератору

269. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +1 +/
Сообщение от Аноним (269), 01-Ноя-23, 13:24 
> А еще есть нормальный менеджмент, когда можно подоткнуть девайс, вынуть, изменить схему хранения, и все это на ходу, шустро и относительно безопасно

Всё это хорошо когда оно работает в жизни, а не только во влажных фантазиях создателей ФС. Потому что если говорить о BTRFS, то оно даже дисковое пространство не даёт нормально освободить, требуя для этой операции наличия свободного (!) места на диске. Это просто абсурд какой-то... Как при таком дизайне у них работают остальные функции -- даже проверять не хочется. Да и я вот совсем не уверен, что возможность менять наживо тип рейда является хорошей идеей: гипотетические удобства не оправдывают рисков и лишнего усложнения системы. Делать такое перестроение без подстраховки в виде бэкапа никто не станет, а если всё равно надо делать бэкап, то зачем тогда вообще нужна такая функциональность? Выглядит как усложнение ради усложнения.

Ответить | Правка | Наверх | Cообщить модератору

281. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +/
Сообщение от t (??), 01-Ноя-23, 16:04 
менял тип рейда наживую на пулах с данными в несколько ТБ, проблем с этим не ловил.
Ответить | Правка | Наверх | Cообщить модератору

286. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +/
Сообщение от Аноним (269), 01-Ноя-23, 16:26 
Повезло. Я бы на такое не осмелился, учитывая что разрабы btrfs даже raid5/raid6 не осилили.
Ответить | Правка | Наверх | Cообщить модератору

416. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +/
Сообщение от Аноним (-), 03-Ноя-23, 14:14 
> менял тип рейда наживую на пулах с данными в несколько ТБ, проблем
> с этим не ловил.

Я даже крешил пару раз такие операции. И таки ничего за это нет. Ну остается оно с смесью блочных групп, указатели оно ж еще не перевесило и GC блокам в прошлом формате не сделало.

Там вообще можно запросить "новую дефолтную схему хранения" а старая останется какой была и конверсия случится по мере перезаписи - все новые записи будут в новой схеме, но старые блоки специально никто ворошить не будет. Такая вот "фоновая конверсия".

Ответить | Правка | К родителю #281 | Наверх | Cообщить модератору

309. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +/
Сообщение от пох. (?), 01-Ноя-23, 20:37 
>> Все эти "фичи" ничто по сравнению с проблемой "write hole".
> Вам не приходило в голову что сценарии использования, а потому и проблемы и приоритеты у разных
> людей могут быть разные?

"данные ети ваши нам и даром не нужны"!

(ну да, что еще ждать от фс разра... поддержание вялого барахтания которой спонсирует теперь мордокнига? Ей и правда не так уж и нужны твои котики. Новых поназапостишь. Сам. Добровольно и с песней. А твой relation graph раскидан по двум десяткам локэйшнов и переживет даже ядерную войну, а не то что отказ дисков или рассыпавшуюся от своих девичьих проблем фс.)

Ответить | Правка | К родителю #256 | Наверх | Cообщить модератору

417. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +/
Сообщение от Аноним (-), 03-Ноя-23, 14:30 
> "данные ети ваши нам и даром не нужны"!

Да где как. Я вот напротив разогнал надежность одноплатников с SD/eMMC раскладывая там btrfs с схемой DUP, так что единичный бэд в дохрена лет более не киляет всю железку с системой как в вашим гребаным EXT4 или какой там у вас FAT в моде. Более того оно само чинит такое, заметив по чексуме где битое а где нормальное. Если такая фигня чаще чем ~раз в год это ессно повод озадачиться починкой/заменой девайса начинающего осыпаться, ДО того как удастся срубить джекпот у теорвера.

> (ну да, что еще ждать от фс разра... поддержание вялого барахтания которой
> спонсирует теперь мордокнига?

У мордокниги разные данные есть. И врядлли они мечтают какую-нить базу на 30ТБ из бэкапов вынимать. И это у них тоже на btrfs, коли баги "на 20-м терабайте может случиться фигня" чинят. Как тебе такие логические цепочки, мистер эксперт? :)

> Ей и правда не так уж и нужны твои котики. Новых поназапостишь. Сам. Добровольно
> и с песней. А твой relation graph раскидан по двум десяткам локэйшнов и переживет
> даже ядерную войну, а не то что отказ дисков или рассыпавшуюся от своих
> девичьих проблем фс.)

Но таки ресторить базу на 30 тер долго, кастомно и канительно. И это то что любой корп будет активно избегать. В общем нафиг эти сказки и этих сказочников. Мне вы уже который там год то обещаете кончину моих данных? А я вас уже столько лет в гробу и вижу с вашими энтерпрайзными переростками и прочими требованиями хранить на складе запасные девайсы энной модели. И обоими руками за то чтобы всех этих тараканов #$%нуть тапкой с железной подошвой.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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