Два соображения:
1) Нет никакого смысла проводить такое обновление в контейнере; его можно перегенерировать — по крайней мере, я исходил из именно такого опыта подготовки и эксплуатации контейнеров.
2) Если у кого-либо достаточно свободного времени отлаживать процедуру на union FS и ответственно её поддерживать в отчуждаемом от автора виде — patches welcome.

Как минимум, например, на каскадной ФС в общем случае должно быть нельзя сделать `mv --exchange`, если один из аргументов не на верхнем слое.

(В p11 и текущем сизифе mv не умеет в эту опцию, мы используем отдельную маленькую C-программу.)

(Ответ для Arseny Maslennikov на комментарий #1)
> Два соображения:
> 1) Нет никакого смысла проводить такое обновление в контейнере; его можно
> перегенерировать — по крайней мере, я исходил из именно такого опыта
> подготовки и эксплуатации контейнеров.
Почему-то вы решили, что контейнеры можно перегенерировать. Это из обширного опыта использования контейнеров?

2) Если у кого-либо достаточно свободного времени отлаживать процедуру на union FS и ответственно её поддерживать в отчуждаемом от автора виде — patches welcome.
Не понимаю, что такое «в отчуждаемом от автора виде».

> Как минимум, например, на каскадной ФС в общем случае должно быть нельзя сделать `mv --exchange`, если один из аргументов не на верхнем слое.
Это хорошее соображение, но надеюсь, что это не просто предположение.

Жаль, что мне сломали возможность обновить десятки систем с p10.

(In reply to Vitaly Lipatov from comment #3)
> (Ответ для Arseny Maslennikov на комментарий #1)
> > Два соображения:
> > 1) Нет никакого смысла проводить такое обновление в контейнере; его можно
> > перегенерировать — по крайней мере, я исходил из именно такого опыта
> > подготовки и эксплуатации контейнеров.
> Почему-то вы решили, что контейнеры можно перегенерировать. Это из обширного
> опыта использования контейнеров?

Ваша реплика заставила меня задуматься, о чём мы именно говорим. :) Слово "контейнер" я встречал в 3 смыслах:
* VZ-виртуалка без своего ядра;
* mainline-namespaces-окружение без своего ядра, которым пользуются как stateful недовиртуалкой, ставят туда пакеты, etc. Правда, там overlayfs обычно нет;
* системы на генерируемых образах, в которых обычно применяется overlayfs.

Вот последние обычно по построению можно свободно перегенерировать; по крайней мере, нижний их слой с системой. Это следует из того, что ОС свободная. А зачем они иначе нужны вообще?

(In reply to Vitaly Lipatov from comment #3)
> (Ответ для Arseny Maslennikov на комментарий #1)
> > 2) Если у кого-либо достаточно свободного времени отлаживать процедуру на
> > union FS и ответственно её поддерживать в отчуждаемом от автора виде —
> > patches welcome.
> Не понимаю, что такое «в отчуждаемом от автора виде».

Бывает такое ПО, которое хорошо и надёжно работает только у своего автора или в его непосредственном присутствии, а иначе начинает ломаться и кривляться. Вот его применение фактически не отчуждаемо от автора (как бы там ни было юридически).

Любой программный продукт (абстрактно) отличается от не-продукта в т. ч. тем, что его можно использовать без присутствия автора.

> > Как минимум, например, на каскадной ФС в общем случае должно быть нельзя сделать `mv --exchange`, если один из аргументов не на верхнем слое.
> Это хорошее соображение, но надеюсь, что это не просто предположение.
> 
> Жаль, что мне сломали возможность обновить десятки систем с p10.

Какой-то алгоритм апгрейда для каскадных ФС, вероятно, возможен; там не будет mv --exchange, и, очевидно, значительно повысятся требования к месту на диске (и надо будет хорошо обрабатывать ENOSPC). Не берусь судить, насколько он совпадёт с алгоритмом для R/W FS, или сработает ли наивное `cp -Tax`, или можно ли наживую в верхнем слое заменить dentry с каталогом на совсем другую dentry. Как обычно: если это для вас ценно, то вы можете исследовать тему и его реализовать (или найти кого-то, кто это сделает). Возражать против этого не буду :)