Кент Оверстрит (Kent Overstreet), автор входящей в состав ядра Linux...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59314
Пусть этот поц сначала нормальное название своей ФС даст. Да и зачем нужна эта поделка, если уже есть Btrfs?
>уже естьчто закапывать
https://lore.kernel.org/linux-bcachefs/Yph4vK0KAjokd1UL@.../Если кратко, то значительно более высокая производительность, поддержка кэширвоания на быстрых SSD и нормально работающие снапшоты.
А если btrfs это все пофиксят в новых релизах зачем нужен bcachefs?
> А еслиВот ты сам ответил на свой вопрос.
Если сильно большой оптимист - можно еще задать вопрос "когда пофиксят?".
ASAP
btrfs существует 14 лет, этот проект 10. У них все работает. Вопросы?
всё работает? посмешил
Написано "все", а не "всё".
Работает то работает, но вот только в btrfs снапшот делается фиксацией содержимого файла и дозаписью изменений отдельно, что не требует создания отдельного архива, то в btrfs надо отправлять в буфер архив и хранить его отдельно, что что не только неудобно, но и приводит к избыточной пересылке информации.
В btrfs не пофиксят "поддержку кеширования на быстрых SSD", потому что там такого нет, надо использовать BCache.
>Если кратко, то значительно более высокая производительность, поддержка кэширвоания на быстрых SSD и нормально работающие снапшоты.Это все есть в btrfs и снапшоты там работают отлично. Bcachefs (ппц, ну и название, назвал бы свою поделку BFS) - не нужна.
> Это все есть в btrfs и снапшоты там работают отлично.Там есть 1 трабла: если на 1 экстент дофига референсов (например куча похожих снапшотов) - перфоманс может просесть. Это конечно специфичный случай но он есть. Дизайн bcachefs лучше адаптирован к такому случаю, "по итогам". Кент не будучи связан compat формата т.к. еще не в майнлайне - учел некоторые моменты. И по части перфоманса подрасперся конкретно.
Эта проблема решается банальной оптимизиацией кода и переписыванием некоторого функционала без изменения формата Btrfs. Для этого не нужно создавать новую ФС, у которой найдутся свои проблемы и подводные камни, как только она станет популярной, как Btrfs.
> Я готов решить эту проблему,
> банально оптимизирую код
> и перепишу некоторый функционал
> без изменения формата Btrfs.Вот это здорово, все бы так. ;)
> Эта проблема решается банальной оптимизиацией кода и переписыванием некоторого функционала
> без изменения формата Btrfs.Не все известные проблемы решаются так. По итогам эксплуатации и выявленных проблем некоторые структуры сами разработчики btrfs'а делая это сегодня сделали бы уже иначе.
В частности, если интересно, см их идеи на тему "extent tree v2" (нечто типа формата хранения v2). Оно даже где-то в работе, но поскольку там могут сменить формат несовместимо (в том смысле что "v1" драйвер на старых ядрах не сможет такое читать) - пользуясь случаем, вероятно, попробуют и еще ряд вещей починить. Так что это тоже не быстро будет наверное. А почему это надо? Оказалось что при массовой параллельной нагрузке и быстрых сторажах extent tree имеет недетскими проблемы с lock contention. Это убивает параллелизм операций и тормозит. Там, кстати, сбежаввший из редхата Басик как раз и зажигает :)
При том как вы понимаете, никто не будет выбрасывать всю инфраструктуру драйвера и РАДИКАЛЬНО перепахивать формат. Заткнут очевидные проблемы наиболее простыми (по кодингу) способами. Что логично, не стоит сильно ломать активно эксплуатируемую кодовую базу.
Кент же глядя на это все и будучи еще не замайнлайнен разумеется мог позволить себе редизайн некоторых вещей, даже если это и ломает совместимость - ему не с кем совместимость еще держать, так что может сделать "как лучше технически" раз 1 черт кодить от и до. В этом у него как у более позднего дизайна, совсем без требований совместимости, и ожиданий что это немедленно годно к эксплуатации - определенная фора. Пока еще может позволить себе достаточно резкие маневры если удачная идея пришла.
> Для этого не нужно создавать новую ФС, у которой найдутся свои проблемы и
> подводные камни, как только она станет популярной, как Btrfs.Несомненно при эксплуатации bcachefs вылезут какие-нибудь еще проблемы, которые сейчас тематические лица не предусмотрели, а тестирование новой кодовой базы с такими фичами и вышибание багов займет нехилое время. И возможно по итогам его эксплуатации кому-то захочется сделать другой дизайн, next gen next gen'а. Где устранят какие-то еще слабые места. Даже те о которых мы сейчас еще и не знаем.
Это у шишкина все просто - развел теорий, практикой не проверял, и так то все ЗБС. А в реальном мире с реальными хотелками юзерей и реальными заскоками железа получается совсем не так как теоретические CSники себе это воображали, ну их барахло и работает совсем иначе чем они себе мнили в дофига случаев. По факту приходится делать странные костыли для затыкания порблем, пересматривать приоритеты, узнавать много нового об устройствах, их свойствах и отказах, и вообще сталкиваться с неидеальностью мира во весь рост. И без всего этого файлухи не особо нужны. Скажем "а что файлуха сделает на 1 бэд секторе". Или "а вот кернел ресетит девайс 2 минуты, это развал райда или нет? И если девайс вернется, то что?"
> назвал бы свою поделку BFSНазвание уже занято: https://en.wikipedia.org/wiki/Brain_Fuck_Scheduler
BCFS
Учитывая что та же красншляпа на БТРФС забила есть определенные сомнения что там что-то будут фиксить.
Красношляпа стала панацеей? Может просто нежелание вкладываться в чужое достижение?
> Учитывая что та же красншляпа на БТРФС забила есть определенные сомнения что
> там что-то будут фиксить.На саму шляпу забили практически все известные по фс и блочному уровню ядерщики. Они и маются чем-то непонятным с пыхтонрасией в сратисе и гальванизацией XFS неизвестно зачем (точнее, известно, другого уже и не осталось - не jfs же им было брать?!).
А вот Басик - вот тот самый, который раньше в редхате был - подсел на вот именно пиление именно бтрфс чего-то. Только теперь у него даже мыльник не редхатовский чего-то. А остальные из редхата и еще раньше слились.
Чем больше файлух, тем лучше. Конкуренция, все дела. Да и Шишкина позлить тоже приятно. Наверняка разродится еще одним "разгромным" интервью.
Что за разгромное интервью?
Да, кстати... Очень даже к месту!"Так что, "будущее файловых систем в Линукс" - это очередной сильно распиаренный, но мало пригодный к использованию софт. После Btrfs с большой вероятностью место такого "будущего" займёт Bcachefs, представляющая собой ещё одну попытку скрестить Linux block layer с файловой системой (дурной пример заразителен). И что характерно: там те же проблемы, что и в Btrfs. Я давно это подозревал, а потом как-то не удержаляся и заглянул в код - так и есть! Авторы Bcachefs и Btrfs, создавая свои ФС, активно пользовались чужими исходниками, мало что в них понимая. Ситуация очень напоминает детскую игру "испорченный телефон". И я примерно представляю, как будет происходить включение этого кода в ядро. Собственно "грабли" никто не увидит (на них все будут наступать потом). После многочисленных придирок к стилю кода кода, обвинению в несуществующих нарушениях, и пр. будет делаться заключение о "лояльности" автора, о том, насколько он хорошо "взаимодействует" с остальными разработчиками, и как успешно всё это потом можно будет продавать корпорациям. Конечный же результат никого не заинтересует. Лет двадцать назад, может быть, бы и заинтересовал, но сейчас вопросы ставятся по-другому: получится ли это раскрутить так, чтобы ближайший десяток лет определённые люди оказались трудоустроены. А задаваться вопросом о конечном результате, увы, не принято."
Ну и как, трудоустроился Шишкин на ближайший десяток лет со своим поделием или пришлось на галеру идти?
> Ну и как, трудоустроился Шишкин на ближайший десяток лет со своим поделием
> или пришлось на галеру идти?Его величество развело кучу умствований и при том ... ВАУ - "ещё не определился с тем, как их реализовать для простых Reiser4 томов". Это он так про снапшоты. Поэтому я пока поюзаю на btrfs, со всеми его неидеальностями, зато - вот - с снапшотами. Которые может и не идеально, но - вот - работают. Потом может сабж попользуюсь, я надеюсь дожить до этого момента.
А МакЛауды могут ждать когда его величество вообще осознает как к своему МегаИнновационному дизайну снапшоты вообще приделать. А сколько это накодить займет и тем более оттестировать до уровня стабильности не хуже хотя-бы btrfs вообще тактично помолчим - потому что люди столько не живут. Особенно если фича сразу не предусматривалась. Не та штука которую просто натянуть на глобус.
> Linux block layer с файловой системой (дурной пример заразителен). И что
> характерно: там те же проблемы, что и в Btrfs.Это на самом деле очень крутой tradeoff.
1) Все операции с RAID уровнем значительно быстрее т.к. оперируют только занятым местом, а не всей площадью.
2) Это намного гибче в плане возможности воткнуть "уж какие есть" девайсы в пул. Без канифолинга мозгов выравниванием по размеру и потерь места на этой почве. Или даже вынуть девайс после временного расширения пула под разовую задачу.
3) У таких штук изумительная реконфигурация и даже смена схемы хранения. Это как пересесть из ржавого жигуля в маленький персональный звездолет. Теперь все не прибито на гвозди и можно выбирать масштаб и конкретику по ходу дела. И сменить например схему хранения если вон то - не нравится.
4) На это все снапшоты и дедуп ложатся явно лучше чем то что было до этого. И уж тем более лучше чем это работает на чистом блочном уровне.Btrfs создал новые паттерны по которым будут делать next-gen дизайны. Bcachefs продолжатель этого направления. Достаточно интересный. Сделанный с учетом проблем предшественников. И его кодер кажется может не только бла-бла на тему как надо, а конструктивную работу с апстримом на тему интеграции. В том числе и идти на компромиссы, и дорабаьывать core-подсистемы сообща. А не так что я тут отдельное нечто в своей норке, а ващи проблемы меня не волнуют, дескать.
>1) Все операции с RAID уровнем значительно быстрееА циферки-то где? Быстрее чем тут?
https://www.opennet.ru/opennews/art.shtml?num=57026
> А циферки-то где? Быстрее чем тут?Циферки зависят от процента используемого места. Скажем если пул был на 10 терабайт, но реально пока используется только 100 гигов - при конверсиях, добавлениях и изъятиях устройств и т.п. ворочаться будут только те 100 гигов как максимум. Т.е. разница относительно обычного райда во времени операции будет в десятки раз. Одно дело глупым райдом по всей площади рестрайп делать, другое - удвинуть или сконвертить только реально используемые 10% емкости. И это сильный и валидный аргумент "за" управление томами из именно файлухи. Если из блочного уровня - он не файлуха, не знает что используется. Это обрекает пользователей на медленные и печальные операции "по всей площади" даже если использовалось 10% емкости. Попытки что-то сверх того делать выглядели еще более убого, криво и проблемно потому что блочный уровень начинает лезть в явно ФСовские епархии, для чего он не создавался. Файлухам это виднее. Наверное мог бы быть какой-то общий уровень абстракции для этого - но пока таких дизайнов мало, не очевидно как такое могло бы выглядеть. Должны появиться эн разных дизайнов чтобы понять что там общее в этом аспекте. А пока есть btrfs (zfs не в счет, он вообще не это) да вот bcachefs в виде злостного WIP. Не дофига данных для новых подсистем и рефакторов.
> https://www.opennet.ru/opennews/art.shtml?num=57026
Файлухи юзают не только ради циферок. И рейзер вообще умеет "space use aware" операции? Когда оно знает какой регион (не) используется и при конверсии схемы райд, изъятии девайса, уменьшении размера фс и проч - двигает только это? Кенту идея с backrefs и управлением пространством именно в контексте ФС тоже зашла и он тоже ее во многом содрал как я понимаю. Потому что это большой шаг вперед с точки зрения эксплуатации, что бы там шишкин не блеял. Подоткнуть первые попавшиеся девайсы для какого-нибудь разового расширения пула, а потом и быстро изъять эти девайсы бывает довольно круто. А шишкин такой номер вообще может показать для начала? Или у него только сказ про rampant layering violation? Это могут простить - если в замен предоставлены забойные фичи которыми обосновыается такая потеря эстетики и переизобретение колеса.
> Циферки зависят от процента используемого места.Ну вот и поставь Btrfs в аналогичные условия. Создай том из нескольких дисков, на нём большой файл и замерь скорость удаления диска.
> Файлухи юзают не только ради циферок
От файлух требуется эффективно управлять дисковым пространством. То есть, компактно хранить данные и быстро проводить файловые операции, а также операции над томами. Остальное - это соревнования балерин по метанию молота.
> И рейзер вообще умеет "space use aware" операции?
Ненужно. См. выше.
> Ну вот и поставь Btrfs в аналогичные условия.Аналогичные кому? Чему? Цель измерений? Вы вообще понимаете как это работает?
> Создай том из нескольких дисков, на нём большой файл и замерь скорость удаления диска.
По такому описанию я могу замерять что угодно. В любую сторону. Например, результат основательно зависит от числа дисков в конфигурации и % использования емкости.
Как простой пример, жил был системный диск. Механический. На 2 Тб. В пару ему такой же добавили, собрав в результате RAID1 порядка 2 Тб. Всего там несколько гигз было и рестрайп из single -> RAID1 занял жалкие считанные минуты. Потом диск захотелось утащить под другие нужды и RAID был превращен в single. Это тоже заняло несколько минут. Ну и вот за считанные минуты 2-терабайтный диск был вынут, просто потому что реальное использование было ессно и близко не 2 Тб.
А могу совсем наглый чит, с коэффициентом уделывания близким к бесконечности. В btrfs можно рестрайп делать не "жестко", а "мягко" - запросив тип для НОВЫХ чанков. Так все новые данные которые записывают с этого момента - будут в новом формате, а старые - останутся как есть. При этом в пуле будет смесь разных схем RAID. На самом деле это могло бы быть чуть не пофайловым решением - какую схему хранения тем блокам давать, дизайн так может, просто алгоритма таких решений для аллокатора нет. При вон той "конверсии типа RAID" - время операции крайне близко к нолю, так что win относительно более классических схем по времени приближается чуть ли не к бесконечности. На самом деле это конечно лишь доразвитие стиля CoW чуть дальше, но так можно было. И это может быть очень драматическим отличием от более классических схем по временам операций. Разумеется, есть нюансы. Скажем на полностью забитом диске никакого выигрыша относительно блочного райда не наступит. Если понимать вот эти фичи дизайна, можно ими пользоваться себе во благо. А еще, в дизайне где может быть смесь уровней RAID (данные и метаданные совершенно штатно могут иметь разную схему хранения даже без вон тех фокусов), сжатие, мульти-референстутые экстенты снапшотов и рефлинков, файлы с "дырками", и все такое - ответ на вопрос "сколько места свободно?" становится довольно интересным аспектом.
> От файлух требуется эффективно управлять дисковым пространством.
В случае RAID вынос его на файловый уровень основательно поднимает эффективность ряда операций, когда вместо жевания вон тех 2 терабайт от и до по всей площади оно удвинуло с диска несколько гигз которые есть за считанные минуты - и отдало мне диск из пула. Ну а на более классическом райде рестрайп 2-терабайтного пула на механических дисках будет оооооочень неспешной операцией. Если так вообще получится без разбора пула и сноса данных. Вон то видите ли нонстоп, при этом система работает, данные доступны.
> То есть, компактно хранить данные и быстро проводить файловые операции,
> а также операции над томами.Ну и вот в части операций над томами, а точнее, пулом, в плане его увеличения, уменьшения, смены схемы хранения и проч btrfs может дать мастеркласс любой другой вундервафле. Это менеджмент как он должен быть, простой, ненапряжный, позволяющий использовать то что по факту есть без камасутр с выравниванием. А основанность на именно ФСовском уровне позволяет этому всему знать какое место используется а какие регионы можно совсем не трогать, что в случае частичной занятости зачастую крайне радикально ускоряет операции менеджмента с пулом.
И еще снапшоты. В итоге железный хост можно менеджить почти как VM - с множественными снапшотами состояний (даже writeable!), увеличить-уменьшить стораж когда надо, без особых напрягов, или даже рестрайпнуть в другую схему хранения. Без останова.
> Остальное - это соревнования балерин по метанию молота.
Не, вот извините! Пожив с снапшотами я уже на меньшее как-то не согласен. Всегда мечтал менеджить мои железки в стиле виртуалок. Или вот DUP на однодисковых конфигах мне очень нравится. Одно дело - кончина ОС, от 1 бэда, когда системная либа не прочлась и даже не грузится, и совсем иное - "csum failed .... corrected" при том же самом эвенте под той же либой - когда оно проблемный блок просто вынет из 2 копии в другом месте девайса, вероятность что и он тоже порушен - крайне маргинальная в реалистичных ситуациях типа 1 бэда раз в сколько-то (час..год). А еще как приятный бонус - отлично обнаруиживает сбойный хардвар, от гнилых SATA шнурков до глюкавых процов и чипсетов. Вопли "csum failed" извещают меня что проблема - есть. Очень на пользу безотказной работе систем.
Ну и еще я иногда data recovery балуюсь. Очень круто делать "копию" рефлинком чтобы какой-нить fsck гонять на нем. "Копия" чушки в пару терабайт делается за секунды. И ессно реально занимает только те блоки которые изменились. Примерно как CoW диски в VM по смыслу. Это конечно "thin provisioning" и реально там может и не быть места на полную копию, но мне и не надо, fsck какой не так уж и много блоков образа меняет. А если не получилось - окей, я сотру "провальную копию", сделаю новую, и попробую на ней другие подходы. Иными методами это все очень сильно медлленнее и требует супер-дофига места в сторажах, видите ли.
> Ненужно. См. выше.
Да им и снапшоты кажется не нужны. Остается только вопрос нафига рейзер нужен. Оверинженерии во, а бенефиты с этого - вообще какие? У btrfs понятно какие. Менеджмент хоста радикально улучшается и начинает по комфорту напоминать виртуалки, а если с умом пользоваться еще и выживаемость ОС улучшается, сбойное железо обнаруживается, и можно эффектные трюки рефлинками откалывать, типа "копирования" терабайтных чушек за секунды (для всех практических целей это ведет себя как независимая копия файла, хоть изначально и ссылается на блоки оригинала).
>> Ну вот и поставь Btrfs в аналогичные условия.
> Аналогичные кому? Чему? Цель измерений? Вы вообще понимаете как это работает?Ты дурачок чтоль? Операции над томами должны быть быстрыми. Типичный пример - отобрать раздел у файлухи на ноутбуке, где просто так жесткий диск не всунешь. Btrfs у тебя будет целый день перемещать данные. Рейзер сделает это быстро.
Шишкие при чем тут?
Он интервью давал, где критиковал все файловые системы кроме своей.
Сейчас основная претензия к btrfs в том, что она падает от каждого чиха.p.s. жду клованов, которые btrfs используют с детства и у них ни разу не было проблем. Я рад за вас, но другие не такие везучие.
Это что ж у тебя за железо, что бтрфс падает от каждого чиха, неклован ты невезучий?
А что есть те у кого ext4 падает от любого чиха? Вроде нет. А значит можно делать выводы о качестве фс.
Если включишь поддержку чексумм и твоя память выдаёт ошибки, то и она вполне может развалиться "от каждого чиха", а так просто будут тихие повреждения в случайных местах и не всегда в важных. Кстати, по поводу каждого чиха. Сколько там уже десятилетий ext4 умирает при ресайзе, когда включен sparse_super2? И ведь не сообщали, что нельзя, видимо, "это знать надо".
Ещё если во время ресайза будешь стучать по диску отбойным молотком, то тоже будут тихие повреждения тебя что не предупреждали?
Зачем использовать sparse_super2 вместо sparse_super? Экономия на спичках? По умолчанию он отключен.
Там много чего может быть отключено по умолчанию, это не важно. Зачем тебе куча копий, когда хватит 2? Это может быть весьма ощутимо. Если это десяток дисков на сотни терабайт может и есть какой-то смысл (и то куда их столько), но в обычных то условиях куда?
> А что есть те у кого ext4 падает от любого чиха? Вроде нет. А значит можно делать выводы о качестве фс.Ну есть 🤷♂️
Где-то уже описывал эту историю: сервер, ЖД. Шла где-то 30-ая минута fsck (тут вам не xfs, с её fsck по минуте). Свет снова прекратился (бесперебойники не успели зарядиться после полного опустошения), и fsck начался сначала. Шёл очень долго, кончился ошибкой. ФС сдохла и уже ничем не реанимировалась. Хорошо, бэкапы были.
Это точно про ext4, чем она занималась? Я тут начал волноваться, когда journal recovery минут 10 занял, обычно то моментально после обесточивания восстанавливает. Но это забитый диск и на его было записано прилично данных прямо перед обесточиванием. Тоже сейчас думаю отключат и приплыли, для этих данных то бэкапа и нет. На такие случаи должно быть резервирование, конечно.
У тебя диск быстрее закончился чем ФС.
> У тебя диск быстрее закончился чем ФС.Неа. Я его переформатировал потом в XFS (v5 уже вышла, так что ей уже можно было пользоваться), и диск потом года полтора точно отработал. Дальше я уволился.
>сервер
>бесперебойники не успели зарядиться после полного опустошенияА зачем бесперебойники опустошили? Бесперебойник нужны исключительно чтобы корректно завершить работу. Если у вас сервер, то дейтацентр несёт ответственность за все последствия ненадлежащего оказания услуги.
>>сервер
>>бесперебойники не успели зарядиться после полного опустошения
> А зачем бесперебойники опустошили? Бесперебойник нужны исключительно чтобы корректно
> завершить работу. Если у вас сервер, то дейтацентр несёт ответственность за
> все последствия ненадлежащего оказания услуги.В целом согласен. Но тогда (это было лет 8 назад) я был админом в госухе с очень странными приоритетами и проектами, там такое считалось нормальным. Я ещё не знал как надо 🤷♂️
Да даже не то что падает, а то что архитектура переусложнена и это не фиксится. А то что падает - это уже следствие. Тут только выкидывать все наработки и переписывать с нуля.
Я btrfs использую ради коров и снимков. Пока вроде работает. Но будет интересно посмотреть допилят ли bcachefs и будет ли инструмент миграции.
> Я btrfs использую ради коров и снимков. Пока вроде работает. Но будет
> интересно посмотреть допилят ли bcachefs и будет ли инструмент миграции.Немного конкуренции и выбора еще никому не мешало :). Да и итеративное развитие вперед никто не отменял. А раалии IO за последние лет 10 заметно изменились.
Попробуй поставить на тестовый раздел/жёсткий диск и попробуй урони.
Подтверждаю
Опровергаю.
Кстати, подтверждаю. Буквально пару часов тому назад развалилась в виртуалке openSUSE Tumbleweed, на ровном месте -- просто перестала логиниться и всё. Причём без каких-либо действий с моей стороны, т.к. всё работало без нареканий (только загрузка и выключение очень долгие) со вчерашнего дня. Короче шляпа, а не ФС...
А как ты понял что дело в файловой системе?
А он и не понял. Это же эксперты с opennet. Понимать надо!
Понять было не трудно, т.к. других причин просто не было. Другие дистрибутивы (да и суся на ext4) работают безотказно. Я даже разбираться не стал -- просто снёс эту срань да и всё. Но ты продолжай грызть кактус, не обращай внимания на "экспертов с опеннета".
и как связан логин с файловой системой?
> Понять было не трудно, т.к. других причин просто не было.Вот прям так, даже без лога системных сообщений - но виновата файлуха? :) Да неужели? Уровень системной экспертизы просто пробивает потолок. Подвального этажа. Глубокого бункера.
А на кой ляд мне ломать голову что там за причины? Я устанавливал opensuse на виртуалку чисто для экспериментов с zfs (из-за доступности самых свежих её версий), а не для того чтобы чинить btrfs. Я просто переустановил её на ext4 -- теперь стоит как скала. Хотя если честно сейчас прям даже интересно стало. Надо было действидельно посмотреть что там было, чтобы, так сказать, документально засвидетельствовать фейл btrfs :-)
> А на кой ляд мне ломать голову что там за причины?Ну, как бы, если некто утверждает что виновата допустим файлуха (или лысый черт, или хренсгары) - подразумевается что он может свое утверждение как-то пруфануть или обосновать. С чем как раз вышел былинный отказ, как я понимаю.
> Я устанавливал opensuse на виртуалку чисто для экспериментов с zfs (из-за доступности
> самых свежих её версий), а не для того чтобы чинить btrfs.И что в этом спиче доказывает что проблема вообще возникает из-за файлухи? Измышлизмы какого-то анона с виртуалкой?
> Я просто переустановил её на ext4 -- теперь стоит как скала.
А законы Мерфи вот гласят, что если вам кажется что дела идут хорошо - возможно вы просто чего-то не заметили. И откуда бы вот вам знать что дела идут хорошо, если в EXT4 вообще диагностируемость в районе плинтуса? Они на журнал то чексумы приделали лишь когда петух клюнул и потуги реплея рушеных журналов стали выносить тома. А на основной площади фс вообще чексум нет. И без полного журналирования (который там дико тормознут) эта штука вообще не парится об участи файлов при перезаписи. Можно спокойно получить файло которое наполовину старое и наполовину новое при крахе. Ведь инфо для undo или redo операции с данными там просто нет. А потом юзеры удивляются - чойта за марсианские пейзажи в некоторых фоточках и офисный док не открывается?!
> Хотя если честно сейчас прям даже интересно стало. Надо было действидельно
> посмотреть что там было, чтобы, так сказать, документально засвидетельствовать
> фейл btrfs :-)Дык дерзай, если это что-то актуальное, только еще нехило бы указать детали конфигурации, для воспроизводимости эксперимента и понимания что на самом деле в нем видно.
Единственное что в бошку приходит - поставить unsafe кеширование диска виртуалки (когда оно не выполняет запросы VM на сброс кешей) и срубить это, но это как бы заведомо глючная конфига и факап именно в unsafe кешах. А в нормальной ситуации чего б ему там сыпаться хрен его знает.
Лол, достаточно зайти в телеграм-канал opensuse. Там если тамблвид с чего-то не развалился, то день, считай, прошел зря. Тамошние обитатели только и делают, что обновляются и после этого восстанавливают систему из снапшотов. Арч с подключенным ауром и то надежнее.
С чего ей разваливаться? Я вот сейчас заново накатил её на ext4 (для экспериментов с zfs) -- работает как часы. А то что btrfs УГ я заподозрил сразу по её работе (до этого не сталкивался с этой ФС): очень медленный старт системы и такое же медленное завершение, что-то там монтирует-размонтируе, колдует, насоздавала кучу снапшотов, вольюмов, а в итоге не прошло и суток как система приказала долго жить )) Банально могло что-то неправильно отмонтироваться или примонтироваться, какие-то файлы повредились и привет. Ручаться конечно не могу что причина была именно в ФС, но за много лет пользования линуксами уже вырабатывается определённая интуиция, и при таких признаках моё подозрение сразу пало на ФС, т.к. ранее я с подобным не встречался даже на xfs. В общем, каждый пусть развлекается как хочет, но моё мнение об этой файловой системе (можете назвать это предубеждением) сложилось вполне определённое.
Использую btrfs как основную 3 года на разных железках. Это что нужно такое делать, чтобы btrfs падала? может у вас проблема с железом?
использую btrfs уже примерно 10 лет, на всех личных дисках выбираю именно эту fs.
проблемы были встречал конечно. но так то строго говоря проблемы я встречал и с ext4, и с zfs, а сколько было их с ntfs, а до этого с fat32?
в целом fs - это всегда оценка рисков, и так чтобы поставил и забыл - фантастика, бекапы никто не отменял.
но так же есть хосты, где ext4 уже работает более 10 лет, и btrfs пулы, которые отрабатывали по >5 лет до вывода железа из эксплуатации.
> Сейчас основная претензия к btrfs в том, что она падает от каждого чиха."уж чихнула, так чихнула!" (c)
Не от каждого. Основная претензия именно к непредсказуемости падения. Но очень сомнительно чтоб запиленная в одно жало более сложная мегаиерархическая фс была более надежной. Ну может хоть падать будет предсказуемо, и можно будет красными флажками огородить особо опасные места, типа raid6 btrfs. Но скорее всего - опять придется на границе один огромный красный флаг вешать.
> флажками огородить особо опасные места, типа raid6 btrfs. Но скорее всего
> - опять придется на границе один огромный красный флаг вешать.Для тебя, пох, хоть автоматические туррели :)
>Да и зачем нужна эта поделка, если уже есть Btrfs?Авторы учитывают грабли на которые наступали в BTRFS,это уже + для этой фс.
Охренеллый ++ я считаю рабочий fsck, даже в домашнем применения я сталкивался (правда без потерь данных) ошибку crc и только раздел в чтение.Хорошо ошибку зафиксировали ,а чем ее починить ? scrub падал на 52 % проверки,fsck тоже так себе,не ремонтировал.(жесткий исправен,до сих пор пашет для бэкапов-от чего ошибка давно выяснил,в конверторе с ext была ошибка,починена 4 года назад) По новой форматировать? Так себе ремонт.
> Хорошо ошибку зафиксировали ,а чем ее починить ?Избыточностью, лол. А если ее не было - упс - твоя конфига внезапно не предусматривала сколь-ниудь гарантированный и рабочий фикс без потерь. Чудес не бывает.
> для бэкапов-от чего ошибка давно выяснил,в конверторе с ext была ошибка,починена
> 4 года назад) По новой форматировать? Так себе ремонт.Конверторы играют в весьма деликатную и сложную игру. Это типа-круто - но насколько это безопасно это так то отдельный вопрос. Там вон теперь ntfs2btrfs в тренде еще, желающим на грабли попрыгать еще вот тулса :))
А сабж наверное тоже так сможет, он унаследовал определенные черты дизайна - включая гибкость аллокаций. Это требуется для нормальной реализации ряда фич в таком дизайне. В первом приближении это называется "write-anywhere".
> А если ее не было - упс - твоя конфига внезапно не предусматривала сколь-ниудь гарантированный и рабочий фикс без потерь.Прикол в том что данные были целые, ошибка скорректировалась.А отремонтировать фс -упс....не может отремонтировать методанные.Это как с UDF , в последней ревизии двойная резервация методанных,а средств починки нет :-(
> Прикол в том что данные были целые, ошибка скорректировалась.А отремонтировать фс -упс....не
> может отремонтировать методанные.Это как с UDF , в последней ревизии двойная
> резервация методанных,а средств починки нет :-(Если резерв метаданных есть то и чинить их не надо - а с чего им портиться? К тому же не любые метаданные можно вообще адекватно починить. Как максимум аннулировать проблему до состояния когда это монтироваться будет но в каком оно состоянии окажется - отдельный вопрос.
Эксплуатировать такое - тоже так себе радость, кто его знает как оно такое взбрыкнет при случае?
А если просто "данные выковырять" - так в btrfs в штатные тулсы офлайн читалка без монтирования встроена. Я не понимаю чего народ хочет. Чтобы все было збс даже на трухлявом железе прояпывающем данные и рушашем память? Так не бывает, я и дохлый нтфс у таких счастливчиков отскребал, но там тоже речь о монтируемости этого хлама уже не шла, только о get data back.
>Если резерв метаданных есть то и чинить их не надо - а с чего им портиться?Ошибки имеют свойства накапливается.А потом упс,развалился том. Из за отсутствие средств ремонта фс -оказалась забыта UDF.Детская ошибка,до конца флаг разминирования драйвер под офтопиком (7-10) не отрабатывал .Данные целые,а работать с этим томом уже нельзя, и толку от дублирование метаданных и данных(опционально) ,если том идёт под формат.
> Ошибки имеют свойства накапливается.А потом упс,развалился том.Btrfs их чинит по мере обнаружения, так что на активно юзаемой ФС не накапливаются как раз. Но если вдруг - во, теперь вы знаете занафига есть такая операция как scrub. Сие читает все используемые блоки и чекает чексуммы, чиня при необходимости.
И да, менеджмент такой штуки и особенности - отличаются от "классики". Это логично, блин. И сабж тоже будет отличаться от классики. Это просто другой набор паттернов дизайна файлух. Новый, необычный, непривычный. И все же обладающий рядом крутых и полезных свойств.
> Из за отсутствие средств ремонта фс -оказалась забыта UDF.
Для меня она забыта по совсем другим причинам: "а чем она лучше всех остальных ФС?". А вот ремонтировать ФС мануально я не очень хочу. Меня вообще автоматические и беспилотные применения волнуют - и как там это вообще могло бы выглядеть?! Так что отсутствие fsck бывает и фичой, когда в системе некому кнопки жать.
> Детская ошибка,до конца флаг разминирования драйвер под
> офтопиком (7-10) не отрабатывалЧего-чего за флаг? Вы там в сапера режетесь? Или у вас отпуск с металлоискателем?
> Данные целые,а работать с этим томом уже нельзя, и толку от дублирование
> метаданных и данных(опционально) ,если том идёт под формат.Ну как бы при нормальном выборе схем хранения и исправном хардваре и нормально работающей системе такая ситуация тупо не наступает, потому что "с хрена ли"? Ну вот как могут сбойнуть 2 блока RAID1 по 1 логическому смещению на разных девайсах? Если это случается, это индикатор убер-жирных системных факапов уже явно не уровня ФС и там и остальное не лучше. Такую систему фиксить надо ASAP. Не, я не спорю что как last resort такой тул может и вариант, но это не было в приоритете для того дизайна - и это понимаемо.
>Чего-чего за флаг?Завершении сесии.В UDF многое взято с iso9660, усовершенствовали и приделали возможность работать с жёсткими и флэшками.Бага около 4-5 лет весела, в офтопике 10 в какой то ревизии исправили.
>"а чем она лучше всех остальных ФС?".До расшаривания exfat -нет ограничения 4 Гб,имена юникод,кроссплатформенная,есть unix acl.
Btrfs уже более 10 лет в ядре и в продакшене у корпораций. Пусть Bcachefs наберет такую же популярность, как Btrfs, а там, я уверен, всплывут такие проблемы и баги этой ФС, что мама не горюй.
Btrfs нужен пока для страданий, поэтому понятно, для чего эта поделка.
Юзаю Btrfs с 2012 года и не потерял ни одного бита. Железо свое глючное смени, стадалец.
> Пусть этот поц сначала нормальное название своей ФС даст.
> Да и зачем нужна эта поделка, если уже есть Btrfs?Ну это вы зря так. Bcachefs структурально - списан с btrfs, но будучи сильно более поздним дизайном...
1) Учитывает проблемы всплывшие в btrfs и старается их обойти, взяв однако ж за основу удачную часть лекал. Т.е. крутое и удобное управление пространством в стиле btrfs, разные уровни RAID, снапшоты и проч.
2) Очень сильно оптимизирован на минимум оверхеда, в эпоху дизайна BTRFS это было намного менее критично. А сейчас появились сверхскоростные SSD и сеть, так что количество операций проца между всем этим - не пустой звук. Bcachefs оптимизирован на минимум оверхеда.В общем если посчитать zfs Gen1 идей, btrfs был Gen2 а это примерно Gen 2.5+ по уровню эволюции мысли и учета ошибок предшественников. Он обещает стать примерно как btrfs, только еще теперь БЫСТРЫЙ. В смысле, спокойно дающий фору даже EXT4 и прочим. Даже на супербыстрых SSD.
Btrfs уже более 10 лет в ядре и в продакшене у корпораций.Пусть Bcachefs сначала наберет такую же популярность, как у Btrfs. А потом у нее всплывут такие проблемы и баги, которые будут похлеще, чем у Btrfs.
> Btrfs уже более 10 лет в ядре и в продакшене у корпораций.Пусть
> Bcachefs сначала наберет такую же популярность, как у Btrfs. А потом
> у нее всплывут такие проблемы и баги, которые будут похлеще, чем у Btrfs.Я думаю что у нее СНАЧАЛА всплывут проблемы сильно круче, потому что сырой код который впервые пошел в массы и поляна не вытоптана.
А потом - потом мир изменится, сторажи изменятся, IO и сети изменятся, и откуда б нам знать что тогда будет хорошо и плохо. Может все займет какой-нибудь MRAM который как RAM но - энергонезависимый, например? Тогда технологии хранения заметно поменяются.
> он любит программировать, а не отлаживать код99% современных кодерков именно такие
ты понимаешь значение слова "отлаживать"?
Поделись своим пониманием этого слова.
Вычищать из кода лажу.
Отлаживать значит ложить на более далёком расстоянии чем сейчас
Устранять несоответствие между тем, что программист хотел написать, и тем что он написал в реальности.
И это важная часть любой разработки. если программист не хочет ей заниматься значит на выходе будет гавно. Язык программирования в той или иной степени может попытаться скрыть это гавно(сборка мусора в языках с GC), или не наступить на определенный вид граблей. Но видов граблей уйма, так что от дебага не уйти, если конечно хочется сделать продукт а не какашку.
И ни один язык не спасёт программиста от неправильно применённых алгоритмов. Если условная видеоигра не умеет нормально отсекать геометрию вне камеры, то переписывание на новый технологический стек не поможет.
А написали бы "дебажить" как в оригинале
> loves to write code, but not to debug it
> just means a lot less time debuggingи никакого лингвистического спора не было бы))
А нет никакого спора. Зачем обезьянничать, когда есть свои слова ?
На ютубе один лингвист высказал такое мнение: неправильных слов нет и если debug английское слово, то вот уже дебаг русское.(тем более что оно ещё и склоняемое, то есть не стоит особняком и полностью интегрировано в язык)
> если debug английское слово, то вот уже дебаг русскоеЖелезобетонная неоспоримая логика, конечно.
Давайте тогда "фуск" и "фак" добавим в лексикон русскоязычных людей. Раз у лингвистов с YouTube нет "неправильных" слов. Расширим и без того немалый запас ненормативной лексики.
Фак уже давно и прочно вошел в лексикон, как и прочие "ассо" явно являющиеся сокращениями от сами поняли чего :)
>> он любит программировать, а не отлаживать код
> 99% современных кодерков именно такиеБоюсь, Вы перепутали "любят" и "умеют". Например, разработчики Rosa Linux не умеют. А я не люблю.
Держи нас в курсе как говорится
Давай адреса электропочты свой и своего друга, буду держать.
Здесь пиши, пожалуйста, чтобы все видели.
Ты не успел попасть в то время, когда в Сети повторяли "отучаемся говорить за всех"?
Успел. Рассказать как это было?
Расскажи, особенно интересно, почему тебя тогда не отучили говорить за всех.
На гитхапе у меня посмотри, я писал об этом.
Опеннет атакован экспертами, неотличимыми от Чат Жэпэтэ.
>кхе-кхе раньше было лучше
ZFS c Btrfs можно подумать сильно популярная ФС. А тут какое-то чудо-юдо им идёт на смену.
Узкий сегмент и узкая приминяемость в каком-то совем датацентре
Решили свою задачу и выдали миру, а применять или нет ваше дело
Может вы только пасьянсом пользуетесь чего уж там какой кеш
> ZFS c Btrfs можно подумать сильно популярная ФС.Btrfs'ом пользуется миллиард фэйсбучных юзерей. Если это не популярная фс, то что ж тогда популярно то?
А Minix используют все у кого процессор Intel, значит Minix тоже популярная операционная система.
>используют всех, у кого процессор Intel,пофиксил
> Minix тоже популярная операционная система.Ну а что, нет чтоли? А линукс использует уже наверное и пара миллиардов, с андроидами то. Пока какие-то ретарды про 1% пиндят.
Ну если применять логику, что все пользователи фейсбука используют btrfs, то можно сказать что и вообще все пользователи интернета используют linux - явно больше пары миллиардов.
> Ну если применять логику, что все пользователи фейсбука используют btrfs, то можно
> сказать что и вообще все пользователи интернета используют linux - явно
> больше пары миллиардов.Примерно так и есть. А еще у каждого найдется по нескольку устройств с линем, от телека до роутера. А майкрософт вещает про свои 1%. Им, понятное дело, с зафэйленым WinPhone считать с вон теми - неудобно.
Стоит ли транслировать своё местечковое мнение на всех, демонстрируя свою ограниченность?
А разве в Убунточке по умолчанию не BTRFS?
Желаешь судить по популярности? ZFS планировалось открыть в OpenSolaris, чего Sun Microsystems и добились открыв почти все исходники UNIX официально за исключением некоторых компонентов ядра что допиливали уже в проекте Illumos.
Сколько девушек тебе признавались в любви без твоего задаривания их чем-либо? Ты ведь хочешь по популярности у домохозяек оценить промышленную файловую систему без проблем с размером данных в принципе со 128 битным размером. Это только недавно стало так что 500 мегабайт, которые жрет ZFS по минимуму не такая большая часть от общей оперативной памяти. Плюс задействовать кеш данных через файловую систему вместо скажем кеша для Си исключительно чем плохо?
Ты просто мозгами шевелить не умеешь, вот тебе и нужны неопровержимые области применения. Но так как ты их не осилишь скорее всего такие как ты будут орать про ненужность. Ты наверное и медицину будешь орать что она ненужна пока тебе не понадобится. Смотрите какая непопулярная у людей восстановительная пластика лица у мужчин. Шрамы же мужчин украшают. Правильно, да?
> 128 битным размером.Правильно, тормозить так во всем. Чтобы даже 64-битным процам неудобно было. И не понятно будут ли в обозримом будущем 128-битные т.к. пока никто и близко не приблизился к порогу 2^64 байтов.
> Это только недавно стало так что 500 мегабайт,
А вон у того одноплатника с 256 оперативы - btrfs прекрасно работает. И сабж сможет. Какой грите процент оперативы 500 мегабайтов там? :) Случаи бывают разные.
> решить проблемы с высоким потреблением памяти при восстановлении и проверки ФС утилитой fsck
> использовать при разработке Bcachefs язык RustЧто-нибудь одно.
>> - How does bcachefs avoid the dreaded RAID write hole?
> We're copy on write - and this extends to our erasure coding
> implementation, we don't update existing stripes in place -
> we create new stripes as needed, reusing buckets from existing
> stripes that still have data.То, что в бтрфс ниасилили (и видимо уже никогда ниасилят), но осилили в openZFS.
>> - How does an O_DIRECT loop device on bcachefs compare to a zvol on ZFS?
> I'd have to benchmark/profile it. It appears there's some bugs in the way the
> loop driver in O_DIRECT mode interacts with bcachefs according to xfstests, and
> the loopback driver is implemented in a more heavyweight way that it needs to be -
> there's room for improvement.То есть для образов дисков для виртуалок оно непригодно, как и btrfs. btrfs если кто не в курсе. ужаснейшим образом фрагментируется с CoW образом диска и просто тормозит (в 2-3 раза медленее ext4) с no-CoW образом. Во втором случае ещё и остаётся без упаковки. в openZFS образы дисков в виде zdev просто ЛЕТАЮТ, быстрее чем голый диск работают. Не говоря уже о том, что упаковка на лету всегда имеется.
Про то чем лучше снапшоты так и не понял. в btrfs снапшоты просто замечательные, можно эн копий оси иметь например и грузиться по выбору в любую (пару раз пригождалось иметь новую и старую системы). В openZFS такое без доп ужимок и прыжков не выйдет (сначала надо снапшот сделать, потом его из снапшота преобразовать в полноценный датасет, а уж что делать чтоб забутиться из грёбанного initramfs в другой рут-датасет я даже не в курсе; в btrfs тупо в грубе выбирается аргументом ядру другой снапшот он же subvolume).
> То, что в бтрфс ниасилили (и видимо уже никогда ниасилят)Буквально пару версий назад радикально заделали для RAID5 - а для RAID1/10 никогда и не было актуально из-за наличия чексум. Так что реально проблемы есть только с RAID6. И кстати метаданные могут быть в другой схеме - том же RAID1 - что очень полезно в вон том плане.
> То есть для образов дисков для виртуалок оно непригодно, как и btrfs.
> btrfs если кто не в курсе. ужаснейшим образом фрагментируется с CoW
> образом диска и просто тормозит (в 2-3 раза медленее ext4) с
> no-CoW образом.По этой причине в Btrfs можно выбрать no-cow для конкретных файлов внезапно. И в сабже тоже можно будет. И да, делать двойной CoW и виртуализатором и ФС - тупая идея. Оставьте кого-то одного на этом пути. Либо RAW диск виртуалки и COW файлухой, либо COW диск виртуалки и nowcow файл. А вот cow cow'а - идея поганая.
> Не говоря уже о том, что упаковка на лету всегда имеется.
Она имеется также у btrfs и сабжа :)
> выбору в любую (пару раз пригождалось иметь новую и старую системы).
При том если делать как оно в убунте (2 subvolume, а истинный / файлухи вообще на 1 уровень выше / системы) - еще и system и data можно раздельно снапшотить и откатывать. И спрятать уровень менеджмента от софта при нормальной работе ОС (например чтобы не повредить случайно).
> рут-датасет я даже не в курсе; в btrfs тупо в грубе
> выбирается аргументом ядру другой снапшот он же subvolume).Ну да. Выбирается какого subvolume монтировать как / что довольно удобно. А операции с оными похожи на диры по сути. Стереть subvolume можно даже каким-нибудь миднайтом, как "директорию". Удобно так то.
Впрочем самые зачетные фичи btrfs это возможность подоткнуть или вынуть девайс с увеличением/уменьшением места, или даже схему хранения переиграть. И это все просто, шустро (только реально занятое место) и без останова системы. Можно даже device add -> new drive -> remove -> old drive -> прописать бутлоадер -> вы только что заменили rootfs device под ОС на ходу :). По своему забавно - сменить диск под системой нонстоп. А что, Шишкин, сможешь так же? :)
> Буквально пару версий назад радикально заделали для RAID5 - а для RAID1/10 никогда и не было актуально из-за наличия чексум. Так что реально проблемы есть только с RAID6. И кстати метаданные могут быть в другой схеме - том же RAID1 - что очень полезно в вон том плане.И как оно? write hole пропал? А заполнение целиком одного диска из трёх рандомом (аццкая имитация bitflip'а) тоже переживает? OpenZFS переживает, я специально проверял. А btrfs, когда проверял -- не переживало. Но то было несколько лет назад.
> По этой причине в Btrfs можно выбрать no-cow для конкретных файлов внезапно. И в сабже тоже можно будет. И да, делать двойной CoW и виртуализатором и ФС - тупая идея. Оставьте кого-то одного на этом пути. Либо RAW диск виртуалки и COW файлухой, либо COW диск виртуалки и nowcow файл. А вот cow cow'а - идея поганая.
Во-1, я о том и сказал, что no-CoW файлы с образом диска виртуалки в btrfs раза в 2 тормознее файла на ext4 выходят. Во-2, в OpenZFS zvol'ы ровно те же самые CoW-файлы и есть (ну или почти), и наоборот, летают быстрее голого диска. Это всё на свежесозданных пустых ФС.
> Она имеется также у btrfs и сабжа :)
Тут тоже есть нюанс. В OpenZFS можно устанавливать размер блока, которыми будет паковаться (и фрагментироваться). Например, 1 мегабайт. Меньше не будет. А в btrfs оно само будет резать на кусочки килобайт 128 упакованного - 16 неупакованного. А если в середину экстента с 128к данных байт записать, какого размера CoW-добавка будет, тоже неизвестно. Подозреваю, что 4к.
> самые зачетные фичи btrfs это возможность подоткнуть или вынуть девайс с увеличением/уменьшением места, или даже схему хранения переиграть.
Вот кстати да, забыл упомянуть. И это, и дефрагментатор свободного места онлайновый тоже имеется.
Зато, например, в OpenZFS можно собрать degraded raid6 (raidz2) массив на 2 дисках (и 2 sparse файлах на рамдиске, после чего те файлы отключить). В btrfs попытка собрать массив на файлах заканчивается ужасными плясками с loop deviceами.А ещё, в OpenZFS шифрование по-датасетно искаропки. В btrfs вроде ещё не довпилили, хотя грозятся.
> И как оно? write hole пропал?У RAID1 его и не было, а в RAID 5 таки - да - радикально починили полным RMW в спорных случаях. Хоть это и медленнее.
> А заполнение целиком одного диска из трёх рандомом (аццкая имитация bitflip'а)
> тоже переживает?Это не имитация битфлипа, т.к. от оригинальных данных вообще ничего не останется, даже суперблоков, и нельзя ЭТО идентифицировать как девайс пула. Буквы дисков это прекрасно но их порядок при загрузке не гарантирован. В случае полного отказа девайса, если НИЧЕГО вообще нет, логичнее замену девайса делать, с ребилдом порушеного на новый. Но если это все постепенно - будет орать про чексумы и фиксить их, куда оно денется?
Из _реалистичных_ проблемных сторажей точно переживает работу на текучках и сыпучках с DUP (так можно юзануть фиговую флеху/карту, одну). Просто берет и чинит - и теорвер так намного прикольнее. Теперь проигрыш не при 1 бэде в чем-то критичном, а при совпадении когда бэды сразу в 2 копиях - в физически разных местах - что довольно маловероятно. Вот так теорвер гораздо прикольнее ощущается. "Еж пищит, орет, но живет".
> OpenZFS переживает, я специально проверял. А btrfs, когда проверял -- не
> переживало. Но то было несколько лет назад.Они все же несколько разные по структуре. И если на девайсе вообще ничего не осталось - он не опознается как свой за отсуствием суперблоков. Но если на стораже не осталось нифига вообще, это replace девайса уже, а не фоновый фикс нифига. Т.к. полный отказ.
А с реалистичной точки зрения что-то сравнимое я видел только при слете транслятора на дешевом хламе типа карт и флех - и в этом случае всяко потребуется мануальщина для замена развалившегося вдрызг девайса. Пытаться такое чинить не стоит: склонно разлетаться вновь, даже если кажется что вроде починилось, реально та еще мина получается.
> Во-1, я о том и сказал, что no-CoW файлы с образом диска
> виртуалки в btrfs раза в 2 тормознее файла на ext4 выходят.Ну насчет в 2 - хотелось бы деталей как мерялось и в какой конфиге.
> Во-2, в OpenZFS zvol'ы ровно те же самые CoW-файлы и есть
> (ну или почти), и наоборот, летают быстрее голого диска. Это всё
> на свежесозданных пустых ФС.Для меня вообще загадка на кой ... надо псевдоблочный девайс поверх фс. Это какое-то извращение понятное только ZFSникам. Я конечно понимаю что гребля только с девайсами и размерами слишком скучно, надо еще и вон той гребли добавить. А btrfs так то о простом и ненапряжном менеджменте. В гробу я видел управление какими там vol'ами дополнительно к остальному еще. В btrfs управление сводится по сути к add/remove/replace девайсов да может смене схемы. Удобно. А если стало мало места, можно подоткнуть +1 девайс. Ну может ребаланс пнуть если использование устройств сильно асимметричное вышло. Прокатит даже с RAID1 или там RAID5 каким. Без академической гребли с выравниваниями, рестрайпами, размерами и проч. За одно это авторам дизайна памятник надо поставить имхо.
> Тут тоже есть нюанс. В OpenZFS можно устанавливать размер блока, которыми будет
> паковаться (и фрагментироваться).Насчет блоков: видите ли, это вовсе и не фича. Потому что, внезапно, не extent based дизайн даже еще! А какой-то block-based переросток. В чем трабл? Без ломового подпора рамой такой дизайн тормозной аки трактор! А btrfs почти как ext4, даже на роутере с 64 метрами оперативы (попробуйте там ZFS завести?!). Из-за этого как я понимаю на него рефлинки натянуть не смогли. Можно конечно поспорить за экстентные аллокаторы и их эффективность, но т.к. в целом мир выбрал для новых дизайнов их, они таки эффективнее в большинстве кейсов оказались. А btrfs живет даже на очень мелких конфигах, типа одноплатников и довольно непозорно я б сказал. Имея свои плюсы. Например, не дохнет от 1 бэда насмерть как EXT4. Да, представляете, 1 бэд под libc6 в EXT4 = система не грузится. То же самое на btrfs с dup - "csum failed ... corrected". Такая вот разница.
> Например, 1 мегабайт. Меньше не будет.
Ага, могу себе представить латенси всего этого и оверхед в менее удачных случаях, когда надо было 4К блок, а оно весь мег в результате кантовало.
> А в btrfs оно само будет резать на кусочки килобайт 128 упакованного -
> 16 неупакованного. А если в середину экстента с 128к данных байт
> записать, какого размера CoW-добавка будет, тоже неизвестно. Подозреваю, что 4к.Я это специально не проверял, но в среднем файлухи с сжатием и проч ведут себя вполне одупляемо в целом вроде. Наверное можно подобрать дурацкие случаи, но их для чего угодно подобрать можно.
> Вот кстати да, забыл упомянуть. И это, и дефрагментатор свободного места онлайновый
> тоже имеется.Ну если дефраг это "техническое зло" то вот простое, гибкое и удобное управление + снапшоты это одна из вещей за которые есть смысл потерпеть необычные причуды инопланетного дизайна. Потому что менеджмент систем переходит на совсем иной уровень.
> Зато, например, в OpenZFS можно собрать degraded raid6 (raidz2) массив на 2
> дисках (и 2 sparse файлах на рамдиске, после чего те файлы
> отключить). В btrfs попытка собрать массив на файлах заканчивается ужасными плясками
> с loop deviceами.Так их почти вроде все на loop девайсах и собирают. Ну и это как-то не основной кейс чтобы меня сильно парить.
> А ещё, в OpenZFS шифрование по-датасетно искаропки.
А это разве не в оракле только? Или они таки доделали?
> В btrfs вроде ещё не довпилили, хотя грозятся.
Ну да. И это еще можно записать в минусы - т.к. хоть и решаемо иными методами, но в ущерб вон тому, удобному менеджменту. Что как бы несколько пролюбливает пойнт.
К сожалению продвинутость дизайна имеет и обратные стороны медали... https://lore.kernel.org/linux-btrfs/YXGyq+buM79A1S0L@re.../
> У RAID1 его и не было, а в RAID 5 таки - да - радикально починили полным RMW в спорных случаях. Хоть это и медленнее.Ну зашибись, в следующем LTS потестирую.
> от оригинальных данных вообще ничего не останется, даже суперблоков, и нельзя ЭТО идентифицировать как девайс пула
И тем не менее, OpenZFS устроило срач в дмесге, но *ВСЕ* данные (все файлы) мне вернуло после такого, а после ресилвера вовсе как новое стало. Потеря суперблока на 1 девайсе не помешала. btrfs -- больше половины не вернуло. С рейд1 обе ФС вернули всё.
> Ну насчет в 2 - хотелось бы деталей как мерялось и в какой конфиге.
Гонял виртуалку, в которой делал apt dist-upgrade и засекал время (предварительно apt dist-upgrade -d делал, чтоб скорость качания не влияла).
> Для меня вообще загадка на кой ... надо псевдоблочный девайс поверх фс.
Во-1 скорость виртуалок с таким девайсом получается заметно больше, чем просто с файлом, прокинутым в виртуалку как диск, т.е. есть какие-то оптимизации. Во-2, каждый такой псевдо-блочный девайс может быть заснапшотен (а также send-receive можно делать), независимо от других. Это два технических преимущества.
> Насчет блоков: видите ли, это вовсе и не фича.
Ну мне если честно по барабану что там внутри. Btrfs просто жутчайше фрагментирует файлы под торрентами или файл (CoW) с образом виртуалки. В первом случае кол-во фрагментов оказывается даже больше, чем кол-во кусков торрента (потому что после 1ого файла границы блоков торрента оказываются посередине блоков ФС), OpenZFS тут рулит просто хотя бы тем, что мельче заранее установленного размер блока не рассыпется фрагментами (зато сосёт полным отсутствием дефрагментатора).
С другой стороны, в OpenZFS никогда не будет (по-видимому) cp --reflink=always, даже внутри датасета, не говоря уж о том, чтобы между ними. В btrfs последнее легко, если разные subvolume оказываются в одном mount point'е, cp --reflink=always офигенно между субвольюмами "копирует" таким способом.В целом каждый раз приходится выбирать, btrfs или openzfs. И пока *у меня* получается так, что под рут или под хомяк, если нет необходимости виртуалки гонять -- btrfs, для виртуалок или для файлопомойки/NAS на рейдах -- openZFS.
> Ну и это как-то не основной кейс
Когда я переезжал с 2 дисков в мирроре на 4 в рейд6 (рейдz2) оказался основным :) Но конечно бтрфс наверное бы переехала одним balance тут.
> А это разве не в оракле только? Или они таки доделали?
Уже несколько лет как, с 2.0.x версий кажется. Работает, проблем не доставляет кроме каких-то особо странных случаев типа send/receiv'а из нешифрованного сорца в шифрованный дестинейшн.
> Ну зашибись, в следующем LTS потестирую.Это если что в 6.2 или 6.3 кернеле было. Решение компромиссное, изначально была идея заворкэраундить write hole _без_ RMW, но с актуальным дисковым форматом таки оказалось "все сложно".
При том суть проблемы - и что можно делать на этот счет - описано в их вике и readthedocs. При сильном желании можно гонять и без фикса, НО - есть нюансы. А метаданные вообще имеет смысл всегда как RAID1 (data = raid5) или RAID1c3 (data = RAID6) держать, их обычно не очень много и это для метаданных более удачная идея.
> И тем не менее, OpenZFS устроило срач в дмесге, но *ВСЕ* данные
> (все файлы) мне вернуло после такого,Не спорю что сбитие автомобилем вертолета круто, но практическая польза в чем? Если сторажу совсем плохо, его фирмварь при старте тоже не прочтет служебные регионы, девайс не выйдет на режим. Если кто видел винчи клацающие при старте, девайсы не проходящие идентификацию и проч, знакомьтесь, ОНО. SSD и некоторые иные флешастые еще в readonly уходят когда резерва не осталось. Но это тоже не то. А какой практически значимый отказ вон то тестит?
Такой полный отвал девайса рюхается даже глупым классическим райдом. И в реальном случае бенефит вообще в чем? При редком постепенном вероятностном развале, характерном для текучек и сыпучек (FEC не справился, фирмварь решил вернуть "уж что вышло" вместо IO error) - btrfs ничем не хуже работает, чинит чексумы и вопит в dmesg. И так то выживает даже на откровенном трешаке где ext4 ушатывается менее чем за месяц.
И еще мне не совсем понятно - если будет как бы тот же девайс на вид, но де факто совсем другой уже, может даже с чем-то нужным, как оно определит: можно ли туда вообще писат и его ли это девайс вообще? Не то чтобы проблемный кейс просто случайно создать но в случае btrfs я понимаю как это: на девайсе 3 копии суперблоков, в них UUID фс и generation, так что можно проверить и что это наша ФС и что девайс не выпадал надолго, фатально отстав от эволюции состояний пула. А вон то как избегает факапов в таких случаях? Оно не сможет "похожий" девайс присвоить при случае и развандалить? Та же нумерация девайсов при сканировании может меняться, скан асинхронный и параллельный нынче - "кто первый ответил тот и /dev/sda", грубо говоря.
> а после ресилвера вовсе как новое стало.
Да это то понятно. Btrfs после полного scrub сыпучки тоже все утекшие регионы чинит на ура. Как и при просто натыкании на это при чтении.
> Потеря суперблока на 1 девайсе не помешала. btrfs --
> больше половины не вернуло. С рейд1 обе ФС вернули всё.На самом деле если данные реально надо - btrfs'ный дизайн в этом достаточно любопытен, т.к. точек входа на самом деле более 1 и если стало тухло можно попробовать немало вариантов альтернативного парсинга с немного более старых вариантов деревьев которые GC еще не подгреб. Запись же недеструктивная. Но тут я сильно лучше в btrfsном дизайне шарю чем в zfs'ном.
> Гонял виртуалку, в которой делал apt dist-upgrade и засекал время (предварительно apt
> dist-upgrade -d делал, чтоб скорость качания не влияла).Ну да блин, звездолет не очень ловко колесит по дорогам общего пользования. Но если вспомнить что у нас гиперпространственные движки есть, в отличие от лохов в пробках...
1) btrfs sub snap <system> </mgmt/before-upgrade>; sync; (снапшотим "систему сейчас")
2) eatmydata apt dist-upgrade ... or whatever. И шел бы fsync нафиг!
3) Если 2) зафейлился по любой причине, отваливаем на снапшот "before-upgrade". Если все прокатило ну, ок, тогда...
4) после всех проверок что результат устроил - стираем снапшот. Имеет смысл немного подождать и проверить весь софт до этого.Зачем стоять на светофорах, если можно телепортироваться в назначение? А если не понравилась материализация в фонарный столб, сгонять на машине времени в прошлое, учесть препятствие, попробовать маневр еще раз, подкорректировав чуток :)
> Во-1 скорость виртуалок с таким девайсом получается заметно больше, чем просто с
> файлом, прокинутым в виртуалку как диск, т.е. есть какие-то оптимизации.Зато менеджмент всего этого становтся просто адищем.
> Во-2, каждый такой псевдо-блочный девайс может быть заснапшотен (а также send-receive можно
> делать), независимо от других. Это два технических преимущества.У btrfs в этом плане все сильно иначе, там subvolume всего лишь поддеревья (иерархии) с независимым снапшотированием. Это никак не отражается в блочные уровни а их райд "file based" как таковой. И в их дизайне вон то не имеет особого смысла. Я так понимаю что саням этот изврат надо было потому что у них не было управления девайсами и райдов в системе и они втянули классический варианто этого в ФС. Btrfs показал что не-классический вариант когда оно на уровне именно ФС - намного круче в менеджменте, имхо.
> Ну мне если честно по барабану что там внутри.
Не, вот на минутку, вы тут вещали что должно работать быстро. Или уж должно или уж нет. Моя ремарка - о том что "нативно" такой дизайн слоупок! А то что рамдиски быстрые - никто не сомневался. Только это не достоинство ФС и ее структур. И - внезапно - не катит без сотен рамы. Если сотен рамы на ломовой кеш нет (мир на файлопомойках не кончается) - ну оно и работает понятно как. А btrfs остается юзабелен даже на тощем роутере с мизером рамы, когда я ему в usb порт какойнить переносной винч с этим цепляю.
> Btrfs просто жутчайше фрагментирует файлы под торрентами
Вообще это зависит от кучи факторов. Я качал торенты и в зависимости от преаллокации, размера частей, и свободного места результат весьма варьируется. Ну и некто iZEN в свое время то же самое на zfs смог, догнав 3-дисковый пул (правда из ноутовых дисков) до чтения "аж" 15 мегов в секунду. При том там дефрага нет и очень интересно что он потом делал с столь крутым пулом, кроме пересоздания с ноля :). Настолько ушатать btrfs у меня не получалось, хотя, ок, у меня в многодисковых пулах с механическими дисками они все ж не ноутбучные, я не настолько мазохист.
> или файл (CoW) с образом виртуалки.
Опять же - все от конкретики сильно зависит. В данном случае от поведения виртуалки. Если виртуалка активно не пишет на диск - то и похрен вообще. Если пишет часто и мелко - ну, ой, фрагментируется конечно. Частично лечится увеличеением commit = и autodefrag в опциях монтирования, но вообще, у каждого дизайна есть сильные и слабые стороны. Логично юзать сильные и избегать слабые.
> ФС), OpenZFS тут рулит просто хотя бы тем, что мельче заранее
> установленного размер блока не рассыпется фрагментамиМинимально вменяемые торентклиенты обычно обладают своим кастомным кешом, как раз поэтому, и не гасят мелкими записями такого размера. Типовые фрагменты от них это какие-то мегабайты. Ну и запись менее чем чанк торента смысла не имеет особо, а сейчас народ и 4-8 мегов юзает - для уменьшения размеров торентфайла.
> (зато сосёт полным отсутствием дефрагментатора).
Вот мне и интересно что потом iZEN с своим супер-пулом делал :)
> С другой стороны, в OpenZFS никогда не будет (по-видимому) cp --reflink=always, даже
> внутри датасета, не говоря уж о том, чтобы между ними.Это наверное как раз из-за блоков. В случае экстентов это заметно проще получается.
> cp --reflink=always офигенно между субвольюмами "копирует" таким способом.
Да оно и в пределах subvolume отлично работает. При этом оно просто 100% дедуп копии на старте, в уровень менеждмента не отсвечивает, именно "дешевый и сердитый дедуп" без ломового жрача проца и рамы, но логически это 2 разные копии.
Очень доставляет для data recovery: мастеркопию совсем не трогаем, а fsck и прочий дестрой на ее рефлинке. При номинальном размере в терабайтах реально создается за секунды, весит по размеру дельты, т.е. обычно немного, если не получилось, стереть попорченый рабочий образ, нарефлинкать за пару секунд новый и попробовать снова. Приятно себе оверсельнуть дохрена терабайтов под якобы-копию. Можно итеративно допинывать многотерабайтную чушку до кондиции не ожидая часами копирования и без мега-сторажей на 100500 терабайт, хранилка чуть больше образа нужна. А, надеюсь это объясняет почему возможность подоткнуть на время девайсов для расширения мне иногда полезна, а потом вынуть их и реюзнуть под иные цели.
> В целом каждый раз приходится выбирать, btrfs или openzfs. И пока *у
> меня* получается так, что под рут или под хомяк, если нет
> необходимости виртуалки гонять -- btrfs, для виртуалок или для файлопомойки/NAS на
> рейдах -- openZFS.Ну вот для файлопомоек в чистом виде zfs с его свойствами вполне ок... там обычно память все же не совсем мизерная, жрать ее особо некому, блочная природа дизайна не очень икается, соответственно. Но считать block based дизайн фичой относительно extent based я чисто технически отказываюсь, в целом скорее все же анти-фича. Ну вот не осталось желающих юзать блочные дизайны вместо экстентов в современном мире, что намекает.
> (рейдz2) оказался основным :) Но конечно бтрфс наверное бы переехала одним
> balance тут.Ну да, если места хватит - он это так делает: читает block group в старой схеме. Записывает в новую BG, с новой схемой, определяя чье это по backrefs. Апдейтит метаданные указывать на новый вариант. Освобождает старую BG. При чтении фиолетово в каком типа BG данные лежат, если половина в старой схеме, половина в новой - и похрен. Я даже крешил пару раз конверсию. Ну, после ребута возобновлял это дело да и дело с концом. Ничего не дохло. А вот с более классическими дизайнами я б так не рисковал - они откуда вообще знают прогресс конверсии допустим и как его возобновлять? Этой то штуке все просто - опять сканим bg в разбираемой схеме и переписываем их в новой, пока этого типа bg не останется. Т.к. cow-записи недеструктивные факап даже не портит данные по идее.
В принципе оно могло бы вообще хранить несколько типов BG для данных и по каким-то критериям более ценные данные так, менее ценне этак, просто этой логики нету в аллокаторе. Но сам дизайн мог бы даже такое. Это же позволяет мягкую конверсию, когда запрашивается новая схема отличная от старой и новые блоки идут в этой схеме, а старые так лежат в предыдущей. При этом можно "плавно" конвертить, операция оказывается дефернута в стиле cow.
> Уже несколько лет как, с 2.0.x версий кажется. Работает, проблем не доставляет
> кроме каких-то особо странных случаев типа send/receiv'а из нешифрованного сорца в
> шифрованный дестинейшн.А он это не чекает? Собссно btrfs fscrypt не сделал еще и потому что это странновато взаимодействует с мультиреференсами экстентов в _разных_ файлов, в fscrypt такое изначально не предусмотрели - для более простых фс делали. А совсем кастом они кажется не хотели, т.к. в принципе у fscrypt идея достаточно простая и как "менее параноидальное" шифрование вполне недурно смотрится.
> Не спорю что сбитие автомобилем вертолета круто, но практическая польза в чем?Отказ девайса это всё же немного другая ситуация, когда точно известно что данные там-то -- больше недоступны. И тогда даже raid5 как в mdraid справляется. Если данные битфлипнуты, raid5 их в принципе не сможет восстановить, а raid6 смог бы (если флипнулось только на 1 девайсе из N+2), но он этого не делает в принципе (я тоже проверял).
С другой стороны, я почитал старые крики btrfs-девелоперов о том что мол 'checksum on a checksum' (касательно хеша на блоки чётности) и то что они этого не сделали, потом посмотрел, что в openZFS всё чётко и изобрёл такой вот тест как в предыдущих мессагах описывал. Если openZFS выдюжило, то у меня 100% уверенность, что и любой случайный битфлип оно обнаружит и исправит. btrfs ниасилило -- ну значит и любой случайный битфлип может ниасилить, как раз из-за того, что не всё записанное на дисках рейда отхешено.> 2) eatmydata apt dist-upgrade ... or whatever. И шел бы fsync нафиг!
Вот уже начинаются пляски с бубном :) (и это с учётом ещё того, что тот самый dist-upgrade в виртуалке пофрагментирует образ вхлам). А openZFS искаропки синхронные записи выполняет быстро -- у неё маленький кусок диска под линейный лог зарезервирован -- как раз быстро флашить синхронные записи подряд, чтоб диск бошками не ездил отписывая новую версию дерева каждый раз. В btrfs, говорят, тоже такой лог есть, но факт остаётся фактом -- там было *МЕДЛЕННО*.
> Зато менеджмент всего этого становтся просто адищем.
Если имеется в виду менеджмент снапшотов то в openZFS он да, немного геморный, но только лишь потому, что они решили абстрагироваться от простой модели vfs->mountpoints. Тем не менее, в btrfs например сделать снапшот геморойнее, надо зачем-то корень монтировать (если в обычном состоянии замаунчены только сабвольюмы).
> Я качал торенты и в зависимости от преаллокации, размера частей,
Во1 насколько я понял, преаллокации в btrfs как таковой нет, т.е. она может делать sparse файлы конечно же, но заранее место и положение на диске для последующей записи не резервирует в принципе.
Во2, не очень понял про кеш торрент-клиента, какой бы он ни был по размеру, если он кратно меньше чем весь качаемый торрент, то совпадений (когда будут иметься 2 соседних блока) будет пренебрежимо мало, и он всё равно будет вынужден отписывать данные в файлы рандомно. И тут-то бтрфс и рассыпется на тысячи фрагментов, причём если в торренте много файлов, то кол-во фрагментов, репортируемых filefrag раза в 2 больше оказывается, чем кусков торрента. autodefrag хорошо помогает для файлов типа логов, которые часто и по-чутьчуть дописываются, видно как сначала 4к кусочек добавился, потом ещё 4к, потом десяток последних кусочков по 4к рраз -- и в один запакованный кусок по 2-3 блока упихали. А вот на торрентах, особенно многофайловых, он примерно никак.> Собссно btrfs fscrypt не сделал еще и потому
Я вот как-то на тот фскрипт пытался смотреть, и понял что без бутылки я там не разберусь. Даже какая-то утилита на go нашлась, которая его позволяет чуть проще менеджить. В то же время менеджмент шифрованных датасетов в openZFS примерно на уровне сложности luks -- ввёл пароль/ключ и оно появилось, вынес ключ -- обратно исчезло. Даже проще luksа, там ещё поверх расшифрованного псевдодевайса надо маунтить-размаунчивать, а openZFS само. Жаль что в btrfs не пошли таким же путём как в openZFS, а связались с fscrypt.
> А он это не чекает?
Проблема была в том, что если шифрованный пустой датасет создать на дестинейшене руками, то в него незашифрованный литься откажется, а если создавать вместе с началом заливки, то там были какие-то нетривиальные проблемы с указанием ключа, которые пришлось шаманить нетривиальными способами. После создания уже диффы новых снапшотов вливаются на ура и без проблем (надо только "расшифровать" датасет на дестинейшене перед вливом при помощи ввода пароля).
> Отказ девайса это всё же немного другая ситуация, когда точно известно что
> данные там-то -- больше недоступны.Я просто не понимаю что вы тестировали и зачем - реально устройства ТАК не отказывают.
> И тогда даже raid5 как в mdraid справляется. Если данные битфлипнуты, raid5 их
> в принципе не сможет восстановить, а raid6 смог быВ случае btrfs - сможет. В терминах RAID5 (минимальный пример): с1=a1^b1. Для a1 и b1 там чексум, отдельно, в метаданных, у метаданных может быть и иная схема, скажем raid1c3. Далее чекаем a1 и b1, если не сходится 1 из сум, XOR с parity и потом проверка по сумме еще раз. Сразу видим прокатило ли. Если померла парити, видно что a1^b1 != c1 хотя суммы верны, тогда c1 можно пересчитать из данных. Хранить и считать суммы блока c1 (парити) излишне.
> (если флипнулось только на 1 девайсе из N+2), но он этого не делает
> в принципе (я тоже проверял).Btrfs может в отличие от обычного RAID делать более информированные решения из-за чексум. Обычный RAID не имеет такого инфо, для RAID1 и RAID5 задник. Даже если мы видим несовпадения, неизвестно какая копия/блоки неверные. Чексумы позволяют это понять, улучшая свойства.
> 'checksum on a checksum' (касательно хеша на блоки чётности) и то
> что они этого не сделали,Чексум на чексум проверяемый пересчетом из блоков данных не дает никакого нового знания, зато дает оверхед на счет и хранение. Хинт: чексумы блоков проверяют коректность данных, а парити считается из данных, можно сравнить посчитаное и сохраненное, поняв верен ли блок.
> и любой случайный битфлип может ниасилить, как раз из-за того, что
> не всё записанное на дисках рейда отхешено.Я для себя предпочитаю чтобы ФС справлялась с реалистичными проблемами, а не тестами моделирующими ХЗ что: сторажи не отказывают вон так. А более реалистичные тесты на сыпучках (найденых btrfs'ом опять же) оно с должными схемами хранения переживает. Даже DUP - делает единичный проблемный девайс снова юзабельным, ценой ополовинивания. В древние времена он имел проблемы с repair т.к. не массовая штука. Но грю же - мы решаем проблемы совместными усилиями. В этом пойнт опенсорса.
>> 2) eatmydata apt dist-upgrade ... or whatever. И шел бы fsync нафиг!
> Вот уже начинаются пляски с бубном :)Управление гипердвигателем лучше делать с иной семантикой чем ДВС, введя точные координаты в назначение. Личное телепание педальки и руля уже не актуально. И какой смысл бенчить реакцию на педальку, если я выкинул это действо совсем? Это еще быстрее. Сильно быстрее. Попробуйте, увидите.
При этом я имею инфо для полного, честного отката на known good, и даже время чтобы составить мнение - хочу я новое состояние или нафиг. На злобу дня, только что откатил неудачный апгрейд Deb12 -> Deb11. Железки на конкретной машине - взбрыкнули, разбираться прямща было не с руки, так что машина времени вернула как было - теперь можно НЕСПЕШНО пнуть причастных. В фоне. Пока все работает. А без снапшотов что б вы вообще делали? Бонусом writeable снапшотов, Deb12 на самом деле есть, и в writeable версии оного можно будет сделать тесты. Когда будет фикс.
> (и это с учётом ещё того, что тот самый dist-upgrade в виртуалке пофрагментирует образ
В пиковом случае дефраг есть. Что до fsync() его в последних нескольких ядрах разогнали в разы. Но я от этого в том кейсе ничего не выигрваю - в виде "а мы типа гипердрайв" я вообще не телепал руль и педальку. В этих терминах, весь dist upgrade - транзакция, уровня ФС. В виде подконтрольном мне. И я сам решаю потом, commit или rollback.
Да, эффективное и безопасное пилотирование звездного крейсера с гипердвигателем требует неких знаний CS. Но я был любопытным и нашел нужные лекции. И теперь могу комбинировать транзакции в эффективном виде сам, не глядя как "мы так привыкли" делают. Наука об осмысленном использовании знаний а не ритуалах и зубрежке.
> openZFS искаропки синхронные записи выполняет быстро -- у неё маленький кусок
> диска под линейный лог зарезервирован --В btrfs сие разогнали в разы последние пару ядер. Но как видите я просто пересмотрел что есть sync и точки начала-конца транзакции, это не костыль, это применение CS себе во благо. Работает намного круче глупого заучивания ритуалов.
> остаётся фактом -- там было *МЕДЛЕННО*.
Можете бенчмаркнуть с новыми кернелами типа 6.3 какого. Впрочем я с этого в вон том случае ничего не выиграю - вооооон то и так было супер быстрым. Даже пищет относительно последовательно. Inplace бы seek в патчимый регион делал, а cow это не надо и он с моим пересмотром семантики как раз свои сильные стороны выпятит, оформив записи куда ему там удобно и быстро. Да, я получаю полный журнал со скоростью безжурнальной фс.
> модели vfs->mountpoints. Тем не менее, в btrfs например сделать снапшот геморойнее,
Не вижу ничего геморного набрать btrfs sub snap <what> <where>.
> надо зачем-то корень монтировать (если в обычном состоянии замаунчены только сабвольюмы).
Не "надо" а "удобно делать так". Можно и иные варианты, просто уровень на 1 выше / с разными вариантами состояний вселенных, где мы можем путешествовать в ключевые точки пространства и времени - прикольная концепция. Логично что попадаем туда только после "сдвига измерений" (в более высокую абстракцию) содержащую в себе "все". Такой стиль понятен любому кто смотрел sci-fi и понимает концепцию ключевых точек, путешествий во времени и разветвления на мультивселенные с разным развитием событий. Это весьма буквальная реализация, writeable снапшоты тоже описываются этой идеей.
А так - subvolume при снапшоте не может содержать в себе subvolume (вместо него снапшотнется пустой дир): если сделать sub-in-sub, будет кольцевая зависимость экстентов друг на друга - и как это обрабатывать?! Не отменяет возможности снапшотнуть "что видишь" куда-то еще. Просто потом рулить менее удобно, а вон та абстракция "на уровень выше /" делает это удобным, логичным, и без "сдвига измерений" сложно снести снапшот нечаянно (по крайней мере файловыми операциями, типа F8 в миднайте на диру subvolume).
> Во1 насколько я понял, преаллокации в btrfs как таковой нет,
Это как бы не очень хорошая нагрузка для cow - но и сказать что фатальная и работать не будет - да вообще, работает. Просто если это основной кейс для стоража, btrfs может и не быть лучшим выбором, если записей много и часто так что дефрагнуть не вариант.
> Во2, не очень понял про кеш торрент-клиента, какой бы он ни был
> по размеру, если он кратно меньше чем весь качаемый торрент, то
> совпадений (когда будут иметься 2 соседних блока) будет пренебрежимо мало,Может пребуферить большие сегменты и записывать их 1 операцией. При этом число фрагментов здорово снижается: 1 дело экстенты по 10 кил, другое по 10 мегз. Суть одна, а соотношения разые, второй случай = в 1024 раза меньше метаданных! И это не только про CoW но и про проблемы экстентных аллокаторов вообще. И вы еще не видели что XFS делает если это соотношение фиговое. Никогда не видали DVD-sized торент стираемый минутами? На забитый XFS его качните без преаллокации. Экстентный аллокатор предсказуемо слепит мелких экстентов, получит неудачное соотнощение данные-метаданные, будет тормозить. Это 1 из мест где печальные блочные аллокаторы могли бы хоть чем-то блеснуть но у ZFS CoW на забитом стораже не даст развернуться и как показал дизайнерский пул "от iZEN" - тоже "не очень", и дефрага нет.
> и он всё равно будет вынужден отписывать данные в файлы рандомно.
Чем крупнее экстент тем ниже число фрагментов и лучше соотношение данных и метаданных: быстрее парсинг и линейный доступ. Блочным дизайнам пофиг, там парсинг всегда в наихучшем варианте, с описанием всей аллокации блоков, от чего они и тормозные.
Солидный кеш позволяет клиенту писать готовые блоки большими непрерывными экстентами. Грю же знание CS улучшает жизнь, позволяя ОСМЫСЛЕННО подыграть дизайну ФС...
> И тут-то бтрфс и рассыпется на тысячи фрагментов,
Вопрос в размере фрагмента и соотношении data-metadata. Экстентный аллокатор эффективен если экстенты большие. Zfs пролетает, у него нет экстентов как таковых и оно не может в большой экстент, так что обречено жевать много метаданных на аллокации ВСЕГДА. Поэтому ZFS даже в проекте не конкурент САБЖУ на суперскоростных SSD где низкий оверхед наше все.
> оказывается, чем кусков торрента. autodefrag хорошо помогает для файлов типа логов,
Он в принципе любые экстенты пытается сливать. Но в торрентах больше поможет буфер клиента - тот к тому же эффективнее работает т.к. целенаправленно собирает чанки в более-менее непрерывные группы и может играть сообща с шедулером клиента "какие блоки просим у ремоты". Ну все минимально адекватные клиенты как-то так и делают, утягивая чанк(и) приличного размера, держа их в пребуфере пока не скачано целиком и не прошло верификацию и скидывая сразу солидные куски, чтобы экстентные аллокаторы не мучать плохим соотношением.
> на торрентах, особенно многофайловых, он примерно никак.
Там скорее буфер клиента актуальнее. И многофайловые ... в торентах обычно БОЛЬШИЕ файлы. Для кучи мелочи торент не эффективен, лучше упаковать. Хотя-бы чтобы сжать имена файлов которые в таком виде заметный % от данных. Чем-то типа 7z - умеющим жать оглавление архива.
> Я вот как-то на тот фскрипт пытался смотреть, и понял что без
> бутылки я там не разберусь.Именно. У этого дизайна - довольно много краевых случаев. Это плата за продвинутость. Извините, мелкий аэропорт изначально не предусматривал что межзвездный крейсер захочет запарковаться.
> шифрованных датасетов в openZFS примерно на уровне сложности luks --
...тогда профит в чем? Fscrypt интересен простотой в сетапе и использовани, но в именно btrfs из-за мультиреференсов на экстент, тот fscrypt не делан с идеей что на 1 экстент более 1 раза можно сослаться. И это как бы трабл.
> само. Жаль что в btrfs не пошли таким же путём как в openZFS, а связались с fscrypt.
У btrfs нет концепций из zfs, на самом фундаментальном уровне, связано с гибким аллокатором, и "файловой" природой RAID. Нет, никто не сдаст сильные стороны этого дизайна. Это весь пойнт его существования. Именно поэтому он nextgen и его просто менеджить. Крипто хорошо, но не ценой слома этой абстракции. Fscrypt в этом смысле наименее интрузивен, он не клещится с тем что хотел продвинутый аллокатор. Но в btrfs валидно 2 раза сослаться на 1 экстент как file1[10..20] и file2[30..40]. Btrfs на уровне дизайна волнует только чтобы блок был идентичного размера и содержимого, логическое размещение пофиг. А вот крипто обычно использует смещения для однозначного формирования nonce. И тут уже некие траблы. Нет, я не проектант запредельно крутых звездолетов и не выдам сходу хорошую логику на такой случай. Это хорошо работало для мелких самолетиков типа EXT4, а звездному крейсеру уже похуже. Но перспективнее вон того, где те понятия вообще не часть дизайна и вся идея дизайна это простое управление им а не жуткие костыли.
> ключа, которые пришлось шаманить нетривиальными способами. После создания уже диффы новых
> снапшотов вливаются на ура и без проблем (надо только "расшифровать" датасет
> на дестинейшене перед вливом при помощи ввода пароля).Ну как бы продвинутым звездолетам свои проблемы походу. Только ваш звездолет - сделан из 4-моторного винтового самолета. Тот дизайн не задумывался для того что вы хотели, просто тогда лучше не умели. Так что вариабельно-блочный аллокатор максимум что из себя смогли вон те тогда выжать. Это имхо не есть лучшее решение. Мне экстентные в целом больше нравятся, все новые дизайны - экстентные, не просто так. Одна из причин по которым btrfs не особо тупит и без подпора гигазами рамы.
Чем больше снапшотов, тем сильнее btrfs тормозит. Число сильно ограничено...
С какого кол-ва снапшотов, например, btrfs становится в 2 раза тормознее?
КО: справедливо для любой ФС со снапшотами. И не говорите, что ФС, созданная гениальными Сантехниками, не так. Может, только большее количество снапшотов тянет.
В сабже автор довольно сурово уперся на эту тему. Не помню, но он кажется смог догнаться до миллиарда, чтоли, снапшотов. Не то чтобы это реально надо, но прошареный инженер строя лесопилку глядя на опыт предшественников все ж устроит алмазное напыление на зубьях, на случай если все-таки рельсу :). А если окажется мало то и парочкой индустриальных лазеров сдобрит. "Ухты@#$, так можно было?! Сказали о...е мужики"
> В сабже автор довольно сурово уперся на эту тему.https://docs.kernel.org/filesystems/nilfs2.html
> There is no limit on the number of snapshots until the volume gets full.
1) Жесткий технический лимит на число снапшотов и импакт на перфоманс это 2 разные аспекта, не находите?
2) У конкретно nilfs есть много других проблем, главная из которых - он довольно заброшенный. Потому что не, он не то чтобы чем-то плох, но когда вопрос "чем лучше остальных?" - у него нет крутого и гибкого управления btrfs, а на 1 девайсе, или с "классическими" вариантами управления томами это все слишком канительно и кто так будет бодаться когда btrfs уже есть, а тут и сабж еще?
10 лет развивали, развивали... а потом решили пересесть на рустик и ещё 10 лет в мейнстрим это никто не возьмёт, потому что всё поменялось, опять всё фиксить... а потом надо будет опять фиксить фичи "как у ZFS и BTRFS" и перфоманс "чтобы ближе к ext4 чем к ZFS"
То есть как обычно
10 лет btrfs развивали-развивали, а тольку практически никакого - как была глючным поделием, так и осталась. Ну ладно, не настолько глючным как 10 лет назад, но сильно лучше не стало.Рустик уже в мейнстриме, первые дрова уже на подходе (ставлю на драйвер видяхи для яблока)
Чел наверное написал пару утилит и понял насколько раст лучше чем си, раз так написал.
И ему явно есть с чем сравнить - точно есть большой опыт написания кода на си))
бтрфсу конечно не хватает некоторых фич, но других фич не хватает и openZFS. Но вот насчёт глючности я бы поспорил. Я даже специально взгромоздил btrfs на раздел с торрентами, работает цуко и не глючит :) На рутовых разделах она тоже у меня живёт счастливо и радует снапшотами.Конечно, всплывает такая хрень как ужасная фрагментация (по самой сути рандомных записей в файлы при качании торрентов), но встроенный дефрагментатор своё дело делает.
Сильно лучше стало. Оно у Facebook на продакшн стоит.Это тебе не васянские локалхосты от икспердов opennet.
То что они стоит у ФБ не значит что подойдет для васянского локалхоста.
У ФБ ресурсов - redundancy, бекапы, люди - намного больше.
> У ФБ ресурсов - redundancy, бекапы, люди - намного больше.Тем не менее, даунтаймы и внезанпные глюки в юзерских данных и им тоже ни к чему. В этом месте интересы фэйсбука и локалхостов нехило совпадают.
> Тем не менее, даунтаймы и внезанпные глюки в юзерских данных и им тоже ни к чему.им пофигу - это не их данные. Да, теряли, и не один раз. А чотакова, ты котиков сам же новых понавыложишь.
А вот потерять невосстановимо фотки умершего члена семьи у себя на локалхосте - это совсем другая история.
Так что нет, не совпадают даже приблизительно. Цель фейсбука - сделать максимально дешево и х-ево.
(рабы которые все это чинят - тоже максимально дешевые)
> им пофигу - это не их данные. Да, теряли, и не один
> раз. А чотакова, ты котиков сам же новых понавыложишь.А знаешь что, мистер умник? Ты похрани-ка такой объем данных - для такого числа юзерех - на чем там тебе удобно. Столько же лет. И мы посмотрим получится ли у тебя с твоими супертехнологиями вообще лучше если отмасштабировать до того же размера.
Понимаешь, чисто практически, если MTBF = 1 000 000 часов, и у тебя 1 девайс, ты скорее всего не доживешь до его отказа. Надежно типа. А если будет 1 000 000 девайсов по планете раскидано, "каждый час что-то ломается" может получиться. Надежно, типа? :)
Из вот этих соображений тестам "в масштабе" доверия несколько больше.
> А вот потерять невосстановимо фотки умершего члена семьи у себя на локалхосте
> - это совсем другая история.Невосстановимо, в дизайне с недеструктивной записью и встроеной офлайн-читалкой и множественными точками входа для репарсинга - надо еще постараться, имхо. С более типичными файлухами если ситуация не идеальна - может хуже быть, у них запись же деструктивная и (мета)данных "есчо" чисто технически не остается, сразу и быстро, без возможности отменить или пересмотреть это вообще совсем. Ну и бэкапы не отменяли. Желательно в разных локациях. А то мало ли какие пожары, наводнения, химеры, тени, птички...
Я вон с ntfs твоего любимого testdisk+photorec вытаскивал недавно. Ну вот пролюбило оно имена файлов и аллокацию, что хочешь то и делай. Данные ессно на месте. К счастью оно не фрагментировано почти - а отсутствующие имена... чем крут линух? Можно накорябать сриптик, он пнет ffprobe и exiv2 после вон тех, позырит теги ... и через 5 минут оно лихо именует сотни тыщ фоточек и мувиков "как камера" - сгенерив имя по дате, из тегов. Через еще 5 минут все лихо переименовано и разложено лучше чем изначально :)
Но как ты уже понял, это - не заслуги нтфс. И не его штатного тулкита ФС. О которых в этой истории сложно сказать что-то хорошее.
> Цель фейсбука - сделать максимально дешево и х-ево.
Большинству юзерей энтерпрайзное железо тоже как-то дороговато, извини. А с чексумами хотя-бы глюкастики быстро замечаются. А нтфс какой они маринуют до последнего, понятия не имея что проблемы есть, пока не случится что-то типа вон того, когда там метаданные уже в хлам до состояния что это игнорить не получается.
> (рабы которые все это чинят - тоже максимально дешевые)
КМК по сравнению с тобой они - богатенькие буратины.
> Ты похрани-ка такой объем данных - для такого числа юзерех - на чем там тебе удобно.мне - нахрен оно не надо, у меня другой бизнес, не слежка за всем миром.
> Столько же лет.
в смысле - сразу же половину прое..ть?
> получится ли у тебя с твоими супертехнологиями вообще лучше если отмасштабировать до того же
> размера.а мне не надо того же размера. У меня совершенно другие задачи и вдобавок нет дешевых рабов (много жрут и гадят, а подвала нет, там бомбоубежище). И то что для мордокниги кажется приемлемым трейдофом - для меня недопустимо.
Я - не мордокнига, в этом и разница. Поэтому и никаких выводов в стиле "что хорошо мордокниге будет просто прекрасно и для меня". Нет, не будет.
"не все решения системных программистов подходят для прикладных" (с)
> Но как ты уже понял, это - не заслуги нтфс. И не его штатного тулкита ФС. О которых в этой
> истории сложно сказать что-то хорошее.их заслуга - что мне за 25 лет существования ntfs и использования его в хвост и гриву - ни разу никакой фоторек использовать не пришлось и двоичным редактором ковыряться в своем диске тоже.
А вот про прекрасные файловые системы л@п4тых - я того же самого сказать не могу.К счастью, с некоторых пор я использую их в стиле выкрасил и выбросил, никаких ценных данных на них не храня.
> мне - нахрен оно не надо, у меня другой бизнес, не слежка за всем миром.Ну дык, и все же, с точки хранения данных у них вот есть базы по 20+ терабайт. Это довольно специфичная нагрузка и забавный стресстест для файлух.
> в смысле - сразу же половину прое..ть?
Ну дык, покажи как это у тебя получится, посмотрим будет ли лучше :)
> и вдобавок нет дешевых рабов (много жрут и гадят, а подвала
> нет, там бомбоубежище).Бедный пох, у него подвал с батареей отжали под бомбарь.
> - для меня недопустимо.
Ну, я не мордокнига но мне btrfs тоже ничего.
> в стиле "что хорошо мордокниге будет просто прекрасно и для меня".
> Нет, не будет.Для себя я знаю что сан с энтерпрайзными хранилками от меня и моих хотелок был еще дальше чем эти.
> "не все решения системных программистов подходят для прикладных" (с)
Не все. Но довольно многие. И обычно это в целом все же работает. А если наоборот - можно и жесткий, трудноустранимый треш получить. Фуксия подтвердит.
> их заслуга - что мне за 25 лет существования ntfs и использования
> его в хвост и гриву - ни разу никакой фоторек использовать не пришлосьА мне вот пришлось. Правда не на своих ntfs, но это потому что для себя шатал я это архаичное тормозилово юзать. А так btrfs мне тоже не приходилось особо чинить. Хоть у меня его и есть.
> и двоичным редактором ковыряться в своем диске тоже.
Да я это тоже не практикую. Однако предпочитаю понимать "свои" дизайны (активно используемые мной) - их сильные и слабые стороны, а потом - зачем бороться с законами мироздания если ими можно пользоваться?
> А вот про прекрасные файловые системы л@п4тых - я того же самого сказать не могу.
Зато btrfs меня предупреждает о глюках железа - и чинит единичные редкие бэды влет, не говоря про простое расширение сторажей вида "подцепил что было под рукой, получил эн места".
> К счастью, с некоторых пор я использую их в стиле выкрасил и
> выбросил, никаких ценных данных на них не храня.Ну как бы если для тебя ntfs венец творения и ты юзаешь винду, твое мнение как и что должно быть в лине не очень ценно. Каки твои рассуждения о юниксвее, который для тебя же и не сработал в результате. А себе я не настолько враг чтобы камлать на технологии из 90х и наслаждаться проприетариями при этом всем. Я вообще не понимаю пойнт этого занятия. Вот наоборот - я стал в разы эффективнее и смог много новых кейсов (e.g. эмбедовка). А у тебя регресс какой-то уже.
И главное - основной разработчик btrfs. Он то 100% в курсе как выпиливать данные из мертвого раздела, в отличии от шайки оголтелых...
> И главное - основной разработчик btrfs. Он то 100% в курсе как
> выпиливать данные из мертвого раздела, в отличии от шайки оголтелых...или ему просто наплевать.
Тут, правда, у изрядной части шайки все так же - этой дешевой порнухи новой накачают.
> Just because you made a painting with a $10k horsehair brush and golden paint does not necessarily make it great art.бриллиантовый камент для любителей раста. Обычным людям это фсчудище и bcache на ноутах с NVME только для замедления процессора и деградации аккума.
Бриллиантовый камент для любителей "бриллиантовых каментов":
"A good craftsman cares about his tools. Listen to woodworkers who get together, they'll be talking about their tools just as much as the actual work. We're interacting with these tools every day, and the quality of the tool very much affects the quality of the work."
Remember they won't use 10K horsehair brush for woodcutting because it's just pointless.
>теперь безумно писать код на языке Си, когда появился лучший вариант. Rust уже задействован в Bcachefs
>Раст необязателенбалаболили они. Так же, как другие по совершенно другому поводу балаболили не краснея (но всем уже тогда было всё понятно), что реестр - это только для защиты детей.
Предлагаю прекратить этот клоунский маскарад, официально дропнуть в linux все платформы, для которых Rust не поддерживается (но из исходников фактическую поддержку не выпиливать и тестирование продолжать, но кто эти платформы в энтерпрайзе испольеует - тот пусть и решает, что ему дешевле, Rust допилить, или самим эти платформы дропнуть, от энтузиастов всё гавно как всегда толку 0, поэтому их мнение веса не имеет, если только они не готовы скинуться деньгами в достаточном количестве на fulltime-команду), и начать переписывать само ядро на Rust.
> от энтузиастов всё гавноНе, ну чего ты так про энтузиастов, обидно ведь.
Вообще не понятна претензия к поддержке платформ. Ты собираешься развернуть эту файлуху на мк или на каком-то древнем железе? Ну значит ты просто не сможешь это сделать. И всё.
Вот какой платформы тебе не хватает в раст?> и начать переписывать само ядро на Rust.
О, наконец-то до людей доходить начало!
Не, Rust же i386 поддерживает, он даже древние микроконтроллеры без mmu поддерживает. Это с платформами без llvm у него проблемы.>Вот какой платформы тебе не хватает в раст?
Мне лично всех хватает пока. Но другим людям может не хватать. Это очень обидно и унизительно, когда твоё оборудование выкидывают, а тебя пускают по миру с голой жопой и так лучше не делать. Но мир у нас злой и циничный. И не надо это маскировать. Чем это виднее, тем быстрее до людей дойдёт, что так жить не надо и тем быстрее он станет нормальным. Поэтому было бы намного лучше, если бы вместо всякого балабольства нам бы говорили всё как есть. Не "мы делаем это для вашего же блага", а "нам вредно ваше благо, но вы жалкие, и нашим действиям никак не можете помешать".
Не увидел там балабольства.
Чел пишет "хочу раст, потому что не люблю дебажить код".
Он делает это для себя - чтобы ему легче было писать код.
И саму фс он не просто так пишет - или для себя, или на заказ, или из любви к искусству.
Плюс он считает, что смена языка сделает код более надежным, т.е пользователям тоже станет лучше.Но всем хорошо не будет никогда. Да и вроде никто этого и не декларировал, даже для си.
Потому что то, что код сможет скомпилится под другую платформу, совсем не значит что он будет там вообще работать.> "нам вредно ваше благо, но вы жалкие, и нашим действиям никак не можете помешать".
Как-то слишком пафосно.
Тут скорее "мы делаем это для себя, а вы можете воспользоваться результатами НАШЕГО труда. Но если вам что-то не нравится - то или воспользуйтесь результатами еще чего-то труда, или вперед работать самим."
> Не увидел там балабольства.Балабольство у тех, кто заявляет, что Rust не будет обязательным, а не у автора файловой системы. Автор ФС - молодец, что делает исследования.
>Он делает это для себя - чтобы ему легче было писать код.
Вот пусть и держит тогда это out of tree. Без шансов найти широкое применение и всех подсадить на зависимость от Rustа. Как подсадили разрабы safetensors - теперь приходится ставить громадный растовый тулчейн и геморроиться с компиляцией только для того, чтобы pytorch мог прочитать сериализованные так модели.
> Балабольство у тех, кто заявляет, что Rust не будет обязательнымТак раст и не обязательный! Просто не пользуйся этой ФС или всем что зависит от раста.
> Вот пусть и держит тогда это out of tree.
Охохо, ты будешь указывать разрабу и ментейнерам ядра что дедать?)) Самому не смешно?
Ну так не пользуйся safetensors - бери старые версии.
Или не пользуйся чужими сериализованными моделями.
Или вообще выкинь pytorch.У тебя же куча возможностей. Еще раз - это всё делалось и делается не для тебя лично.
А, понятно. Linux - для RedHat лично. Спасибо, что напомнили.
> А, понятно. Linux - для RedHat лично. Спасибо, что напомнили.ну зачем же ты так? Есть еще другие платиновые спонсоры.
Линукс для них - тоже.
А ты перепоклонись-ка двадцать раз и colour на color и обратно поисправляй в своем ненужном редхату и мордокниге патче, а потом все равно пойди с ним нахрен потому что он кому-то чем-то не понравился.
> Так раст и не обязательный! Просто не пользуйся этой ФС или всем
> что зависит от раста.Актуальная реализация вообще на си. А про планы с хрустом - але, гараж, пока в кернеле инфраструктуры для этого толком еще нет даже. И даже для сишной версии инфраструктуру то только начали адаптировать совместными усилиями. Так что сперва будет версия на си. А когда-нибудь может и на хрусте появится. А почему бы и нет, особенно если к тому моменту GCC'шный бэкэнд хруста будет в форме для билдовки ядра?
>т.е пользователям тоже станет лучше.Мне, как пользователю, нах не нужно неотлаженное гамно, х*як, х*як и так сойдет, пользователь отпишет свой комент
>всё гавноОпечатка, там было
>всё равно
но у меня что-то зрение село в последнее время, мимо нужных клавиш промахиваюсь
Ешьте дети ext4, будете здоровы! А прочий кaл оставьте корпоративным психам, они должны страдать.
ext/2/3/4 - cамые блевoтные ФС, - для девочек которым пофиг что ставить.
Точнее они даже не вдупляют различий, преимуществ и отсутствие своих же требований.
Это ты не хочешь понять что эти твои фичи модненьких ФС это маркетинговый буллшит. Блестящая упаковка за которой ничего нет.
> Это ты не хочешь понять что эти твои фичи модненьких ФС это
> маркетинговый буллшит. Блестящая упаковка за которой ничего нет.Ну да, замененный глючный проц, пару планок битой RAM, текучие SD/flash и глючные шнурки в коллекцию - маркетинговый булшит наверное, а не чексумы фс в деле, хехе :)
А вам из всего этого комп следовало бы свинтить, с вашим EXT4, посмотреть, заметите ли вы вообще подвох :))). Не, можете и таким железом пользоваться, типа сэкономили заодно. Какимнить геймерам сойдет наверное даже. Слетит система - переставят, впервой чтоли?!
ext4 динственная фс, которую несмотря на все её недостатки, могу советовать по дефолту.
Остальное либо под конкретную задачу, либо нестабильное, либо ограниченное.
Так что ты может и прав, но это тоже само по себе плюс.
Могу посоветовать использовать NTFS. Там, конечно, бывают неудаляемые файлы, и директории, в которых они лежат, которые chkdsk терпит и ничего плохого не видит, зато есть хекс-редакторы с поддержкой парсинга, которыми можно их структуру в $MFT инвалидировать
Да ладно ... И как воспроизвести?Бэкап готового "глюка" хоть есть?
Я такое часто видел, но не не могу утверждать, по какой причине это происходит. Слишком рандомно возникает. Приходилось подмонтировать на запись с ntfs3g и удалять в ней, а это ещё хуже, потому что неизвестно, как она после неё будет работать и когда ей станет совсем плохо. Не совсем понимаю какие бекапы ты рассчитываешь увидеть, тебе отправить многотерабайтный дамп где-то там посыпавшейся ntfs, что ты с ним собираешься делать? И главное, зачем мне хранить эти дампы.Всё гораздо интереснее когда файлы исчезают, повреждаются, или вся ntfs разваливается. И такое было. Тут хотя бы есть определённая закономерность, все фатальные повреждения случались в результате автоматического запуска chkdsk, которая уже автоматически всё разносила (я уверен до неё данные были целыми).
} многотерабайтный дамп где-то там посыпавшейся ntfsМожно восстановить в VM.
На динамический .vhd / .vhdxУдалить всё остальное кроме повреждённого каталога.
Вот со сжатием файла .vhd[x] есть неясности: надо чтобы глюк не был затёрт "байтом 0"
(
Я-то разрушенный диск с ReFS сохранил.Надо же на чём-то тестировать утилиты.
)
--} chkdsk
Да, эта утилита меняет данные зачастую и без ключа "исправить".
Чаще всего видел файлы нулевого размера.
P.S. ОЗУ хоть с ECC ?Если без, то не битое?
P.P.S.
NTFS весьма надёжная FS.
При глобальных же сбоях - просто разворачивал последнюю ежечасную резервную копию.Или реверсировал зеркало на Starwind HA.
Бэкапа нет, как и диска чтобы его хранить. Я - админ локалхоста. Проблемный диск - самый большой в системе.
> ext4 динственная фс, которую несмотря на все её недостатки, могу советовать по дефолту.Ти кто, пилять, xyета Анонимная, советовать он может... Тебе имя своё стадно писать.... аналлитики, йопт. Сцк.... ржууу DDD
На самом деле на пользовательском уровне отличия очень даже очевидны. ext2 без журнала и может рассыпаться от неудачной пропажи жлектричества, ext3 медленная (по сравнению с ext2), дико долго удаляет файлы и fsck там нешустрый, в ext4 эти проблемы пофиксили, поэтому почти никакого резона сейчас использовать ext2\3 нет вообще.
> По производительности Bcachefs опережает Btrfs и другие ФС на базе механизма Copy-on-Write, и демонстрирует скорость работы, близкую к Ext4 и XFS.Ага, конечно, в перспективе разве что
>Из планов на будущее упоминается желание использовать при разработке Bcachefs язык Rust. По мнению автора Bcachefs он любит программировать, а не отлаживать код, и теперь безумно писать код на языке Си, когда появился лучший вариант. Rust уже задействован в Bcachefs в реализации некоторых утилит, запускаемых в пространстве пользователя. Более того, вынашивается идея постепенно полностью переписать Bcachefs на Rust, так как использование этого языка существенно экономит время на отладку.супер, пройдет еще с десяток лет до принятия в ядро, пока он там все перепишет...
Поэтому он сначала отправит в ядро, а потом начнет переписывать.
Сначала его отправят как Шишкина, а потом он скажет что его притесняют.
> надёжности и масштабируемостиКэш - это временная свалка, для быстрого доступа.
Нахуа помойке снапшоты и резервное копирование? :DБолее того, порядок доступа, очередь к кэшу - это динамическое состояние.
Если после сбоя поднять сервер и востановить кэш из снапшота, то запрашивающие
клиенты уже ушли, нахер нужен снимок кэша часовой давности? ИТшные дол6оящеры.
Когда у тебя помойка под петабайт, а её сброс приведёт к отказу в обслуживании (реальное железо просто не выдаст нужно производительности для восстановления). Так что холодный старт как понятие отсутствует и кэш уже давно не кеш, а операционные данные, валидность которых проверяется как можно реже.
> Если после сбоя поднять сервер и востановить кэш из снапшота,При записи на ФС данные идут на быстрый (твердотельный) накопитель, откуда фоном переносятся в хранилище (НЖМД). Первый в данном случае назван кешем. Восстанавливать его не от куда.
DRAM->SSD->HDD
>В Bcachefs используется механизм Copy-on-Write (COW), при котором изменения не приводят к перезаписи данных - новое состояние записывается в новое место, после чего меняется указатель актуального состояния.Автор путает CoW и RoW?
>>В Bcachefs используется механизм Copy-on-Write (COW), при котором изменения не приводят к перезаписи данных - новое состояние записывается в новое место, после чего меняется указатель актуального состояния.
> Автор путает CoW и RoW?А ты ешь ,кушаешь или жрёшь? :D
Реализация в корне отлична.
> Реализация в корне отлична.CoW - это абстрактная хрень, нюансы зависят от авторов.
Кто-то FIFO называет CoW :) C одного конца Copy, с другого Write
> CoW - это абстрактная хрень, нюансы зависят от авторов.Однако у них есть и ряд типовых общих свойств. Например использование ресурса на хранение только дельты от оригигнала. И это хоть RCU vs RAM хоть qcow vs снапшот, хоть btrfs и reflink относительно оригинала. Эта идея останется во всех трех случаях, хоть детали реализации и драматически разные. Собственно это и есть пойнт для возни с такими технологиями. Оверсел и оверкомит ласкает слух. Иногда даже мне. Если я на 4-терабайтной хранилке разложил пяток "копий" 3-терабайтного образа в разных стадиях эксперимента по выуживанию из него данных - я конечно "оверсельнул" себе 15 псевдо-терабайтов при всего 4 реальных, но это ж катит в силу природы файлов :)
Чем отличается от lvmcache + ext4 ? Файловая система в курсе что кешировано, а что нет?
> Чем отличается от lvmcache + ext4 ?Нормальным менеджментом стоража в стиле btrfs вместо всей этой замшелой и кривой камасутры.
> Rust уже задействован в Bcachefs
> По мнению автора Bcachefs он любит программировать, а не отлаживать код,Дальше не читал. Автор может и дальше пользоваться своей ФС. Еще одна недописанная и заброшенная в будущем ФС в ядре не нужна, тем более если тащит за собой раст.
Спасибо, но я лучше reiser5 подожду.
Кстати, а когда выйдет Ганс райзер? Я реально жду новый РайзерФС от ганса.
Следующая попытка прошения помилования в 2026
Ему же вроде в 23 должны были дать.
Живым не выйдет. Он проявил гордыню, не продемонстрировал покорность, посмел отклонить первое предложение Суверена. Ну тогда до него довели, что чтобы его обвинить и казнить им железобетонных доказательств не надо, достаточно их личной убеждённости представителей Суверена, что это он сделал. Суверену нужно, чтобы все знали - с Сувереном шутки плохи.
Гордыня предшествует падению. Не зря так говорят.Если с вами вообще тима работать совместно не хочет, и вы не понимаете что реюзабельные фичи надо вывешивать для всех caller'ов - кина не будет, тусите в своей пещере сами по себе. И вот сидит гражданин в своей пещере, сделав 0 доведенных до ума, юзабельных файлух. Рассказывает всем как надо было. Пруфом... ээ... сказки про белого бычка, отсыл к CS, сказ что я умный, все раки. А со стороны - очередной старый академбрюзга, бесполезный и не от мира сего.
> И вот сидит гражданин в своей пещере, сделав 0 доведенных до ума, юзабельных файлух. Рассказывает всем как надо было.а ты с ним сидел чтоли ?
>Из планов на будущее упоминается желание использовать при разработке Bcachefs язык Rust.И этот вляпался.
Модно, стильно, молодежно))). Иначе грантик не дадут
Интересно что они там такое хотят блочное кешировать. Во-вторых, есть кеш ОС, если кеш самого диска, которым управляет контроллер диска. А тут целая ФС только для кеширования.
Сейчас большие HDD имеют кеш сравнимый с небольшим SSD. Ещё есть гибридные HDD, которые и являются по сути встроенный SSD для кеширования без всяких специальных ФС.
> Сейчас большие HDD имеют кеш сравнимый с небольшим SSD. Ещё есть гибридные HDD, которые и являются по сути встроенный SSD для кешированиПри этом и те, и другие — консьюмерский отстой, которым большие операторы не пользуются.
Сейчас уже и некоторые SSD с гигантским кэшем (на сотни гигов).
Вот только этот кэш сильно отличается и от кэша ОС и от кэша ФС в ОЗУ и управлять им условно не получится (в теории через отправку команд или изменение прошивки, на практике никак) и фактически считается характеристикой ssd и можно его даже и не рассматривать.
И че толку от этого кэша если интерфейс по факту SAS/SATA?
Что-то там включают-выключают в ядро, а может просто починить повышенную нагрузку на CPU при передвижении USB-Mouse? Да ну нет, бред какой-то. Сук, я 15 лет наблюдаю этот глюк, скажете виноваты иксы, а мне пох, мне пришлось купить мышку с PS/S, чтобы избавиться от этого, вот тебе и линукс.
На Linux-libre этот глюк тоже наблюдается?
Чего это она повышенная мышка же хорошо двигается, быстро. Почему бы не загрузить этим процессор. А то что там у аналоговых PS/2 что-то там меньше, так и двигается она хуже. Не так активно и самозабвенно.
Это какой дохлый комп нужно иметь, чтобы USB-Mouse - давала повышенную нагрузку на CPU ?!))) На первопне что ли ? Или на 386 ?)))
> По мнению автора Bcachefs, он любит программировать, а не отлаживать код, и теперь безумно писать код на языке Си, когда появился лучший вариант.А по русски написать сложно было?
Нажимай исправить и пиши, что сложно?
> обновлённый набор патчейЯ, конечно, понимаю, что это скорее всего перевод, но этот акцент на обновлении патчей подразумевает, что все "в теме" и знают, что старая версия не зашла, а это обновлённая и уж точно всё будет гуд.
Либо текст реально достали из каких-то "внутренних" переписок.
Вот уже напрягает "стабилизация реализации снапшотов". Что там стабилизировать? Снапшоты должны просто работать, как в ZFS - снапшот это просто метаданные, то есть сохранённые адреса блоков ZFS. Даже на словах просто и понятно. Ломаться нечему, ZFS просто не подтвердит никакую запись данных в себе, пока корректно не считает записанный блок. А в этом Bcachefs какие-то "срезы" снапшотов.Мне кажется разработкой заинтересуются, если она будет не маркетинговым описанием её крутизны, а простым и понятным всем механизмом, чтобы люди сами поняли, что это делает и нужно ли оно им.
> Вот уже напрягает "стабилизация реализации снапшотов". Что там стабилизировать?_запись_
То, чего zfs не умеет в принципе, ее снапшот всегда readonly. А если тебе нужен записываемый но при этом ты не готов похоронить текущее состояние и нужно одновременно две ветки состояния фс параллельно - добро пожаловать в прекрасный мир клонов и букмарок. Полагаю большинство здешних фанатиков ими пользоваться не умеют.
Оно и действительно совершенно контринтуитивно.
В bcache по задумке все действительно красиво. Вопрос только в том, когда ж оно будет - работать.
И не попадем ли мы все в рай гораздо раньше.
В btrfs оно тоже красиво и интуитивно. Большую часть дизайна Кент слизал оттуда, постаравшись обойти опробованные btrfs'ными лбами грабли. Нормальный подход так то.
> В btrfs оно тоже красиво и интуитивно.вот вообще ни разу.
> вот вообще ни разу.Да ну ладно тебе. Если виртуализатором с снапшотами хоть раз в жизни пользовался то и эти снапшоты в общем то логичны и понятны. А "one level above /" это так в моем стиле. Клево убунтуи это придумали.
хинт - не все виртуализаторы - бредовые поделки на базе все той же единственноверной фс.А так у некоторых не будем покзаывать пальцем виртуализаторов все интуитивненько - "хотите вернуться на этот вот снапшот? Ок? Точно ок? Ваше текущее состояние и все вообще что вы с тех пор понаделали - сейчас превратится в тыкву!"
Что в целом вполне логично, где его хранить-то в системе где снапшот - сущность неизменная?Нет, отдельно сохранить еще одно состояние конечно можно - но тут ты уже сам себе создаешь вермишель и сам как хочешь так и распутывай потом.
> же единственноверной фс.Это о чем?! Я пользовался вмварью, гиперви, kvm... и в конечном итоге, логика CoW дисков-в-файле у них всех достаточно похожая. CoW диски-в-файле вообше ни на какой фс не основаны, они на блочном уровне работают как таковые.
...однако общая логика поведения снапшотов виртуалок - имеет довольно много общего. Особенно на тему отката состояния и отращивания альтернативного состояния из энной ключевой точки, оформленной как снапшот.
> состояние и все вообще что вы с тех пор понаделали -
> сейчас превратится в тыкву!"Это вполне типовое поведение виртуализаторов: если надо текущее состояние сохранить - вон там создание снапошта. Иначе оно только подумайте - и правда продолбается после отката на вон тот снапшот. И так по-моему все вышеперечисленные работают. Их снапшоты аналогичны "read only" снапшотам btrfs. Writeable - возможность продолжить с этой точки и запомнить. По своему забавно - альтернативные истории растут под своими лэйблами.
> Что в целом вполне логично, где его хранить-то в системе где снапшот - сущность неизменная?
Большинство sci-fi где есть multiverse с разными вариантами развития событий и машины времени с тобой круто не согласны. В btrfs по-моему наиболее точная и полная реализация этого. И это круто. Можно завести несколько параллельных вселенных, похожих но разных, эволюционировать их, эти так, эти иначе, потом send вообще в вооон ту виртуалочку сделать, допустим - опа и это уже template для виртуалок вот такого типа. А вон то - эдакого. System integration @ level 80 это как-то так. ИМХО это в разы быстрее и круче всего что ты мог по теме.
> Нет, отдельно сохранить еще одно состояние конечно можно - но тут ты
> уже сам себе создаешь вермишель и сам как хочешь так и распутывай потом.Снапшоты в btrfs могут быть как RW так и RO. Де факто пропертю RO на снапшот можно установить и снять постфактум и "обычными" методами они станут RO или RW - уж как хотелось. Это не только контролируемый time travel в мультивселенных - но и очень хорошо и гранулярно контролируемый, так что типовые траблы досаждавшие путешественникам во времени могут и не быть проблемой вот тут. Это по желанию.
снепшоты это история fs, как может быть "интуитивной" запись в них?
может быть кому-то прикольно иметь автоклон для снепшотов - 2 в 1, унитаз с функцией биде, но не все оценят кмк
> снепшоты это история fs, как может быть "интуитивной" запись в них?Если кто смотрел sci-fi и понял концепцию параллельных вселенных, похожих, но с разным развитием событий в каждой из них, а также путешествия во времени в ключевые точки где интересные разветвления случились, они давно понимают как это на самом деле работает... :)
> может быть кому-то прикольно иметь автоклон для снепшотов - 2 в 1,
> унитаз с функцией биде, но не все оценят кмкМультивселенную и машину времени для путешествия в ключевые точки (снапшоты) на самом деле. Это круче любого биде. Золоченый биде такая ерунда vs godlike powers, право...
Удачи потом это мержить.
Че за бред? Snapshot с записью? Отлично что ZFS проектировали не придурки, а люди четко представляющие смысл и цели решения...
> Че за бред? Snapshot с записью? Отлично что ZFS проектировали не придурки,
> а люди четко представляющие смысл и цели решения...Btrfs умеет и readonly снапшоты, более того RO/RW снапшота можно менять через родной тул фс, изменением property у снапшота, если вдруг в энном случае передумали.
Как отсутствие выбора/фичи может быть фичой - я не допираю. Типа вы лучше меня знаете как мне снапшот хотелось? В любом случае, попробуйте FAT, там вообще фич нихрена, наверное это очень круто :)
> вынашивается идея постепенно полностью переписать Bcachefs на RustRust спасёт мир! ✌😤
от bcachefs? Ну не факт. Пока это только идея, а в ведро того гляди уже включат.
Ага. Соберет всех неадекватов в одном месте)))
> Rust спасёт мир!из компилятора раст сделают SDK с ограничениями как для андроида и все формально открытые проекты где используется раст станут собственностью корпораций - никакой форк уже не спасёт
> все формально открытые проекты где используется раст станут собственностью корпорацийОни и без раста собственность корпораций.
> Они и без раста собственность корпораций.нет, публикуя код в ядре ты не передаёшь права на него. Но что толку от такого кода если ты не сможешь использовать его в коммерчеком продукте без разрешения от правообладателя SDK раст чтобы его скомпилиовать.
Растификация подсистем ядра. Начали с драйверов, теперь - ФС, потом - планировщик, система управления памятью, сетевая, и - оба на! - а ядро-то тю-тю - в руках растаманов, а те, кто стоял у истоков - уже и не при делах)
> По мнению автора Bcachefs он любит программировать, а не отлаживать код, и теперь безумно писать код на языке Си, когда появился лучший вариант.По мнению автора Bcachefs, который любит программировать, а не отлаживать код, было бы безумиеи писать код на языке Си теперь, после появления лучшего варианта.
Фух.... Отдебажил как смог.
>Целью разработки Bcachefs является достижение уровня XFS в производительностиА достижения безгеморройности ext4 нет в планах?
Кстати, может, всё-таки Reiser4?
>>Целью разработки Bcachefs является достижение уровня XFS в производительности
> А достижения безгеморройности ext4 нет в планах?Уверен что в ней нет геморроя?
> Кстати, может, всё-таки Reiser4?
А почему не 5?