> нет, но я не могу себе представить настолько ненужных данных чтобы мне
> это понадобилось.В случае btrfs это довольно безопасные операции. Я даже крешил пару раз. Оно вполне себе переживает это и может нормально возобновить это. CoW дизайн еще и не такие приколы позволяет.
Он же не дестроит старое состояние, а блочные группы у btrfs могут быть разных типов (в плане схемы хранения) - там особой почвы для развала просто нет. Это специфичный диалект операции балансирования, когда заодно еще схема хранения в новом назначении другая. А деаллокация случается не раньше того как это все прокатило и закомитилось.
Поэтому на вон том дизайне это сильно менее сыкотная операция чем на классике и прочих сратисах от раджей. Оно даже с смесью типов блочных групп штатно живет. Как один из вариантов можно вообще не рестрайпить сразу - и лишь запросить новую схему для новых записей. Это "странное желание" но работать будет и ни к чему этакому не ведет.
> (дизайн в общем-то непричем, разработчики просто тоже не могли
> такое себе вообразить)
Тогда ты только что сказал что Крис Мэйсон крутой чувак. Хорошая фантазия - визитная карточка мощных архитектов. Он придумал как это все делать достаточно безопасно, используя возможности CoW на полную катушку. Несомненно - он получил за это специфичный набор приколов. Но вообще надеюсь так понятнее почему всякие, типа кента, именно ЭТО на цитаты будут разбирать, а не zfs ваш печальный. Терпеть не могу програмеров и дизайнов где нельзя то, не предусмотрено сяк, и вообще, давайте прибьем все игрушки к полу гвоздями - так проще, дескать. Это голимый менеджмент, извините. Хорошо - когда ресусы можно динамически и ненапряжно ре-аллоцировать и ре-конфигурировать на новые задачи. Это эффективное использование ассетов и инвестиций. И это повод уйти того кто стоит на этом пути. Что для васян-гаражника что для мегакорп. В этом мы одинаковы внезапно.
> туда - хотя надо быть просто редкостным дятлом чтоб такое создать
> да еще на таком диске который не в первой помойке попадается)
Прости я про то что если у тебя RAID энного размера - как ты его расширяешь? В btrfs можно, вот, подоткнуть хоть вообще 1 диск - любого размера, какой был под рукой. И таки отрастет эн места. Потому что там RAID1 это запрос аллокатору положить те блоки на 2 разных девайса. Т.к. в ассортименте +1 девайс, вариантов как это сделать прибавляется и +эн места отрастает. В ряде случаев может ребаланс захотеться для более равномерного использования, но зачастую катит просто добавить 1 девайс и получить эн места немедленно. И RAID1 можно собрать из ну вот вообще совсем девайсов какого угодно размера. И так далее
Т.е. можно подцепить в пул те ассеты которые есть. Временно расширить. Или убавить. И все это без камасутры "храните на складе эн одинаковых винчей". Это нехилая фича - рулить асссетами динамически, "as needed".
>> В смысле? RAID6 с write hole - на btrfs уже таки сто лет есть
> только крэшится и портит всю fs (это не write hole). Спасибо, уберите.
Если понимать механизм проблемы с этим даже можно жить. Но лучше не нужно. Но математику таки осилили. Трабла не в ней а в RMW, пардон муа. И в том что btrfs один из первых дизайнов который пытался агрессивно скипать эту операцию на full stripe - и в принципе это могло бы и катить но - красиво было на бумаге, ога. На практике овраги все же нашлись и - вот - для RAID5 это дело таки - закостылили, более агрессивным RMW. Который так то ключевая проблема RAID56 по перфомансу.
>> Чего там кто не смог? Коды рида соломона то?
> да, полная ерунда, каждый васян может. Ой, не совсем.
Ну Васян врядли сильно поймет ту математику. Впрочем - я более-менее понимаю, хоть и урезанно, ибо специфичный раздел математики а полинимиальная математика не была моим таким уж прямо любимым топиком. Если б мне сказали для чего оно полезно я б конечно получше изучил, но тут уже поздняк.
>> они вообще сто лет в линукскернеле есть
> Ага, со второй попытки. Первая превращала данные в труху. Нет, автор не виноват.
Не ошибается тот кто ничего не делает. А "обычные" RAID данные в труху вообще часто превращают. Особенно когда копии или парити разъезжается. На флешастиках это вообще норма, потому что там видимо FEC не вытягивает и девайс начинает гнать наружу туфту, зачастую даже не маркируя это как IO error. Btrfs вопит про csum error, чинит. Довольно хорошо чинит - вон чуваку 80 000 блоков из копий аж зафиксило! А дятл что-то и не напрягался что его SSD уже в могиле одной ногой. "SMART же нормальный!". Агаблин, а 80К ошибок чтения с девайса по CSUM - фича, не иначе. Конечно после такого хинта птичкодятел сменил свой текучий сыпучий SSD в темпе вальса и все стало ЗБС. Вот этому даже повезло. Бывают более тупые или менее удачливые, типа додика отключившего каким-то чудом избыточность метаданных на многодисковой конфиге.
> Но к сожалению есть оно внутри md raid который устарел на 25 лет.
Btrfs пользуется "общелинуксными" модулями алго. Они не "md raid", они сами по себе. И ридсоломон, и оптиизированный XOR, и крипто, и сжатие... это как раз был их шаг навстречу, чтобы на layering violation быковали меньше.
> (кстати, привет там тебе от выравнивания и от много чего еще) А не внутри btrfs.
Btrfs таки в целом ведет себя далеко не самым плохим образом, и с SSD и вообще. Твои теоретизмы про 64x это прекрасно, кроме того что не имеет ничерта общего с многими крейсерскими режимами и статистикой накопителей.
>> Ну ты ж понимаешь что сперва место кончается - а потом начинают чесать репу что делать.
> проблемы д-лов меня мало волнуют. Я-то знаю что мне делать - удалить
> что-то ненужное.
В случае btrfs можно просто подоткнуть любой подвернувшийся диск как быстрое решение траблы. Но даже это не все допирают. А таки стирание не полностью решает проблему фрагментации. Хотя если ты сотрешь все файлы в пуле, тогда, конечно, будет не так уж плохо. Только это ничем не лучше пересоздания с ноля. А остальное может быть в заисимости от того что вышло быть весьма компромиссным. Дефрагера у вас же нет чтобы это более прицельно обыграть, чо.
> Потому что оно "кончится" у меня лично ровно вот на этих 23% когда становится критичным.
Ну дык и даже так фрагментация постепенно может накапливаться. Хотя учитывая что твоя шляпа экстенты нормально не умеет, там что так задник что сяк, просто с фрагментами задника еще больше.
> Можно облажаться на васян-локалхосте (но его и send/receive недолго), но если ты
> про это забыл на хранилке емкостью побольше пары терабайт - и не вспомнил за все
> время что заcиpaл эти терабайты (в любой момент можно) - то это уже не лечится.
Ну да, ну да, гиморный менеджмент без права на ошибку - ваше все. Остается только вопрос кому такой менеджмент систем кроме вас нужен, трястись над файлухами как царь Кощей.
