Исходное сообщение
"В ветку ядра Linux-next добавлена реализация ФС Bcachefs" Отправлено Аноним, 20-Сен-23 23:46
> Как только напишешь непротиворечивый алгоритм «отрицательного ресайза» — > пиши в lkml, там найдётся кому накодить. В btrfs накодили - сделали backrefs которые указывают кому блок принадлежит. При нужде убавить размер ФС, 1) идем в хвост фс 2) смотрим по backref чей это блок, 3) двигаем его, 4) апдейтим метаданные, 5) goto 1 если еще больше надо расчистить. Чего тут вообще противоречивого? Это прекрасно работает, и для 1 девайса, и для эн, в том смысле что можно и конкретный девайс из многодевайсной файлухи так вынуть. Маленький catch только в том что это структурами файлухи должно быть подперто для эффективной реализации. А в легаси-дизайне из прошлого века о таком никто вообще совсем не парился. А потом прикнутить на проволоку такое - если совсем не думать о такой фиче при кодинге остального - ну, сами понимаете. А без этого всего - изъятие места сделать при сильном желании можно, но инверсный лукап кому блок принадлежит может оказаться медленным и печальным, если такого индекса сразу не было. В принципе такой инжекс можно отстроить и опосля если сильно захотеть, и даже "сбоку" - но дизайн должен допускать такую мысль и предполагать гибкую аллокацию, когда экстент можно малой кровью подвинуть в логическом размещении и НЕМНОГО отапдейтить метаданные. Если много - скорость всего этого пробьет пол. Подземного этажа. Глубокого бункера. И юзер может не дожить до окончания операции на более-менее крупном хранилище.