> И не один! Дьявол в деталях. Как это всё по-твоему должно работать
> когда на ФС активно пишутся данные?

Элементарно, Ватсон:
1) Избегаем записей в регион интереса.
2) Расчищаем его в фоне.

Разумеется, возможен сценарий когда на маневр места не хватит. Если фс забита, удвинуть может быть некуда. Ну тут ой, "сотрите некоторые файлы и попробуйте еще раз". Нельзя ресайзнуть меньше чем реально занятое место. И желательно какой-то разумный резерв места после завершения операции + маневровый резерв. А так я это в btrfs проферял, работает.

> Где и как хранить обратный индекс?

Btrfs на это дерево завел, насколько я помню. Но вообще где угодно можно. Даже нигде - и отстроить с ноля в момент когда приперло, но тогда ценой концентрированной ломовой нагрузки в момент когда вон то приспичило - придется все forward indices обойти и отстроить реверс, а вон то в фоне при нормальной работе его отстроило. Это тоже не бесплатно и чуть замедлило операции. Но зато ускорило менеждмент. Как менеджер вы должны понимать "tradeoff".

> Как обрабатывать ситуации аварийного завершения работы ядра?

Это CoW. Записи недеструктивны. Сначала создается КОПИЯ экстента. Если будет крах, окей, этого никогда не было. Машина времени вернется в чуть более старое состояние. Можно попробовать еще раз. Если скопировать вышло, на передвинутый экстент будут переназначенй указатели в метаданных. В этот момент новое состояние зафиксировано, после чего можно деаллоцировать расчищаемый экстент в старом месте.

У этой механики не так уж много мест для развала. Благодать cow в бесплатном по ресурсам эквиваленте полного журнала и простом крашрекавери :). Это кроме всего позволяет и передвинуть что-то относительно легко и безопасно. Расчистка конкретного девайса для ремува ничем принципиально не отличается. И даже конверсия в другую схему - примерно так же, проход по блочным группам с разбираемой схемой, а копии экстентов идут в другие BG с новой схемой.

> Что делать, если место на носителе кончилось посреди операции?

Сообщить -ENOSPC юзеру и вернуть неуспех операции ресайза. Ведь регион интереса расчистить не удалось и нельзя урезать логический размер. Пусть сотрет какое-то файло и попробует еще раз.

> Каково должно быть поведение резервирования свободного места?

Какой-то маневровый резерв должен быть конечно. А расчищаемый регион должен по возможности не использоваться. Но на самые пиковые случаи там есть GlobalReserve - если все остальное обломалось, немного маневрового места есть вот там. Тем не менее, если фалуха забита, странная идея ее ресайзить вниз. Обычно ресайзят если есть куда.

> Про главный вопрос — производительность всего этого — ты сам написал.

В случае btrfs это может быть довольно легкой, быстрой и ненапряжной операцией, потому что индекс как раз уже сразу есть, и можно просто взять и просто удвинуть что угодно из любого региона интереса. Если это хвост чтобы сократить размер ФС - ну окей. Или конкретный девайс, вот, вынуть. Просто удвинув с него то что реально аллоцировано. И если на 4Тб диске реально юзалось 20 гигз, удвинуто будут 20 гигз. Разумеется на других девайсах должно быть место для того чтобы их туда переопределить в нужной схеме.

> Действительно, можно и не дождаться окончания работы на забитой
> и фрагментированной ФС размером в 20Тб.

Если кто забил cow на 20 тб до отказа - хотя мог просто диск подоткнуть, без заморочек - ну и кто ему доктор? Еще более странно что он это вниз ресайзить хочет при этом. Дурацким желаниям дурацкие свойства при реализации. Если вы хотите варпдрайв в атмосфере, бортовому компу пофиг, просят - сделает. Что будет дальше - не его проблемы.

> Получается, что отрицательный онлайн-ресайз не
> такая уж и простая задача. А для оффлайна нет нужды морочиться:
> перенос данных на другой носитель будет быстрее.

Это уже реализовано как минимум в btrfs. Что ресайз ФС по размеру вниз, что вынуть конкретный девайс из пула. Если на это все место есть - прекрасно работает. Так что сложно. Было. Кому-то. А нам вот тут в звездолете кнопочку нажать - и варпдрайв нас переместит в назначение.