Скорее, подготовка к пришествию btrfs. Чтобы снапшоты после критичных обновлений были атомарными.
Ну и перестраховка тоже, на случай критических ошибок и дыр в ядре и libc.

В основном да, перестраховка. Существующую схему обновлений никто ведь не собирается ломать. А новая кому-то будет удобной (при этом ни чьими интересами жертвовать не надо). Я например на рабочих серверах если ставлю большие обновления - руками гашу большую часть того, что работает, и запускаю заново (и по возможности/необходимости ребут). А если либы обновляются - еще и prelink заставляю пересоздавать кеш целиком. При этом я прекрасно знаю что и так всё работает, какие-то машины с rhel6 месяцами пашут с включенным yum autoupdate, и сами себя по ночам обновляют (после этого правда чинить иногда приходится :))

Открытый файл при удалении теряет имя, но блоки файловой системы будут деаллоцированы только при закрытии последнего файлового дескриптора.

А грабли бывают тогда, когда что-то требуется по ходу пьесы и ожидается одно, но приехало уже другое.

Говорят, когда-то на настоящих юниксах(tm) при попытке обновить запущенный бинарник можно было огрести text file busy, но своими глазами (и в основном на линуксах) вроде бы не наблюдал... хотя это опять же tradeoff, у каждого варианта есть плюсы и минусы.

Может, они имел в виду Fedora 7?

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

Да не мешает ничего, и необходимости нету. Речь не идет о починке того, что не сломано. :)
Просто на работающей системе если делать btrfs/lvm снепшоты до и после обновления - в дельту помимо изменений в софте будут попадать данные, которые запущенный софт пишет. Отделить на этом уровне одно от другого нереально. Потери места из-за хранения ненужных промежуточных состояний файлов бывают не то что заметными, а даже неприятными.

Обсуждали с legion@, я не смог вспомнить/найти ни одного use case для подобного.

Похоже, что укольчик понадобится, да, ненужная херь в моём линуксе меня беспокоит.

Она намекает админам локалхоста что обновить пакет на диске мало, надо еще перезапустить все процессы зависящие прямо или косвенно от изменившихся данных. Но подохреваю что это метание бисера перед сленами древней секрты "я все обновил безо всяких перезапусков, идите все на"

Тащемта, не снепшота, а boot environment. Это задолго до ZFS было в соляре.

Кстати еще одно соображение добавилось - в линуксе таких проблем особо нет так как мало долгоиграющих процессов, которые бы сами с чем-то обменивались, обычно запускаются соответствующие утилиты. Но если у нас всё через D-Bus и подобное организовано - то нужен перезапуск, что, возможно, повлечёт проблемы с user experience. Так что где-то даже логично - вместо того чтобы требовать "перезапустите firefox, чтобы он дальше мог сыпать notifications обновившемуся компоненту гнома" просто обновить всё пачкой при старте системы. В смысле - демона часто можно перезапустить не тревожа пользователя, а вот гуишную программу - хрен там.

Пользователь прогу не перезапустил. Через некоторое время он пытается сделать действие, которое пытается подгрузить ресурс по старому протоколу... и обламывается. Пользователь кричит "Бага!".

Это как пример того, что решают оффлайновые апгрейды. Но для решения такой ситуации оффлайновые апгрейды не единственное решение: ведь достаточно просто перезапустить прогу, чтоб всё стало хорошо. Просто разработчикам проще сделать оффлайновый апгрейд и ГАРАНТИРОВАТЬ, что багов из-за неперезапущенных приложений не будет, чем сделать нотификацию пользователей определённых приложений, чтоб они их перезапустили.

Маразм это "обновиться" и не перезапускать. Нахрена обновляться тогда?