> Ну у меня не рутФС, но кент как-то разрабатывает и молчит, что
> там какие-то патчи этим утилитам нужны? Значитк ак минимум у него все работает.Ну как, если подкостылить с явным указанием типа ФС - работает. Но автодетект, натурально, пролеатет. Что в тулсах, что в ядре при цеплянии как рутфс. Видимо эту штуку еще не все и не везде детектят. Допилят со временем.
> на самом деле лично у меня не хватает понимания сказать.
Ну я вот как минимум заметил что автодетект этой штуки пока софт не умеет, требуется явное указание типа ФС везде. Мне похрен, я его и так все время указывал для скорости операций, ибо автодетект пытается маунтить как разные ФС, это дольше. Не люблю медленную загрузку.
>>Для btrfs grub это умеет, и сие довольно круто
> Это очень хорошая фича и прям в некоторых случаях даже маст хэв.
Мне понравилось. Если бутлоадер может читать фс, в снапшоте может быть например кернел и initrd, и тогда рекавери - "довольно точный", почти как в VM. Можно, вот, грохнуть пакетником пакет с кернелом - и - отыграть назад! Машина времени это хорошо и правильно.
> с монтированием оно отношение иметь может ). Но для ФС это
> не комбо - она по сути работает как задумывалось.
Для ФС то да, а вот где-то на стыках интеграция может и отъехать.
> Объясняю: в btrfs бывали случаи, что она показывает, что свободного места еще
> дохуха, а запись на нее или любое действие (в т.ч. и ребаланс) - ENOSPC.
Это возможно в некоторых весьма специфичных ситуациях, но в основном с старыми ядрами. В новых запилили global reserve на совсем пиковые случаи, и теперь даже штука с фэйсбук на ENOSPC не натыкается по сути, с их то парком серверов. А с Кентом если я правильно помню историю его патчей, он отменил тот немеряный маневровый резерв, и за это познал... тадам... вариант этсамого для себя :). Но он там бойко чинил в -rc так что загасил то что было у него и тех кто на это нарвался.
> В bcachefs это немного по другому реализовано: оно берет тупо пустые buckets
> и сообщает их объем.
Это однако в такой штуке не обязано соответствовать фактически записаному объему данных. Скажем, оотношение данные-метаданные заранее знать нельзя. Все становится еще прикольнее если вспомнить что число копий данных и метаданных совпадать не обязано. И вот откуда бы это соотношение заранее знать? Как я уже сказал в предельном случае можно ФС забить под ноль одними метаданными, с формальной аллокацией 0 байтов на данные. Даже совсем классические. Ацтой типа EXT4 правда может быстрее нарваться на лимит инодов, номерков дедуле мало.
> GC еще не отработал), а вот показать свободное место, когда его
> нету - не может. Вообще. Никак.
Оптимизм это хорошо. Но реализм лучше.
> Да, но реализовано иначе и часть проблем не присутствует.
А таки кентушка кажется познал радость ENOSPC в процессе -rc :)
> это у меня сейчас. При вашем подходе будет расти btree, а свободное
> место в ФС будет таять. Это как иноды в ext. Но да, формулировка моего
> оптимизма не корректна, учту ).
У EXT будет и место на метаданные жраться, и можно нарваться на нехватку инодов. Если бы ее не было - на ФС с динамической аллокацией инодов можно нарваться на то что метаданные сожрут все место. Потому что на хранение сведений о каждом файле что-то тратится, даже если он 0 байтов.
Это кроме всего прочего гарантирует что data/metadata ratio - заранее неизвестен. И наверное когда вы спрашиваете df сколько места, вы врядли имеете хоть какое-то представление сколько у вас при этом могло бы быть метаданных. В лучшем смысле вы позырили суммарный объем данных в источнике, но это ничего не говорит о вон том аспекте.
> Все могут учитывать. Я не говорю что btrfs совсем уж кусок того
> самого. Он кое-в чем не плох.
Мне понравилось как они bg_tree забацали, монтироваться быстро стал. И монтирование у него прикольнее, с автосканом девайсов. Bcache так вроде не умеет для многодисковых и надо явно все девайсы прописывать, как я понял.
> Ну да, у меня 32G RAM, а вы тестировали в "стесненной среде обитания".
Ну так на воркстейшне рамы есть, но если я буду каждой VM выдавать дохрена, она как раз и кончится, думаете у меня 1 вм? Вот я например тут болтаю с вами - а это тоже VM :). Другая ессно.
> Боюсь, на голом железе такая проблема никогда не была бы
> найдена, только специальное тестирование в виртуалках такие баги позволяет отловить.
Голое железо разное бывает... скажем мелкие одноплатники с кредитку размером, у некоторых опаративы 256-512 мег всего. Зато и стоят 10 баксов за "это типа тоже комп с линухом" :). Btrfs там нашел свое примение, с ним загрузочный SD/eMMC заметно надежнее. Ибо разовый случайный бэд не ведет к разлету железки и претензиям - а то экстренному визиту к черту на куличики. А вот с EXT4 был неприятный опыт такого плана. Оказывается если бэд под libc6 - ОС резко и внезапно превращается в тыкву. Без намека на предупреждение.
> алгоритм - я думаю, это маловероятно. А вот zstd по настоящему
> нормально тестить стали только в майнлайне.
Там вроде какие-то отличия есть в том как оно запилено. Для zstd какой-то дефер, чтоли - может на этом себя наело. Я подозреваю что записывал быстрее чем оно паковать успевало и возможно оно unbound allocation и так можно в принципе где угодно налететь.
> Ну вот лично я ко всем категориям принадлежал. Сначала у меня небыло
> бэкапов. Потом оказалось, что они не распаковываются. В следующий раз распаковалось,
> но файлы оказались битые. Теперь проверяется не только консистентность, но и
> распаковка в виртуальную среду.
А я ... самые ценные штуки я бэкапал ... по моему всегда. Еще в стародавние времена я развлекался диск-докторами и чем там. И уже тогда починил паре типов ФС - и вынул их продолбаные курасчи, проекты и что там еще. Это показало мне что бэкапать так то попроще в целом :)
