Re: Как реализован "in place upgrade" в Дебиан? На чем основан и чем чревато?
On 2012-11-12, Victor Wagner wrote:
> Cygwin работает на файловой системе NTFS. Которая не позволяет удалять
> файлы, открытые работающим процессом.
>
> В Unix-подобных системах, в том числе и в Linux файловая система
> работает по-другому. Ссылка на файл из каталога (т.н. hardlink) и
> ссылка на файл из
> открывшего его процесса фактически равноправны. На файл может
> существовать сколько угодно ссылок, и он физически удаляется с диска
> только если исчезла последняя ссылка на него.
>
> Поэтому, если удалить разделяемую библиотеку обыкновенным системным
> вызовом unlink(2), процессы, использующие эту библиотеку будут
> продолжать её видеть. А package manager или утилита install могут
> прекрасно записать новую библиотеку на место старой.
>
> И только при завершении последнего процесса, использюующего старую
> библиотеку, она физически будет удалена с диска (inode помечен как
> deleted).
>
> Если внимательно следить да debian-системой в процессе апгрейда основной
> системной библиотеки (glibc) то можно увидеть что при апгрейде иногда
> производится перезапуск некоторого набора сервисов.
>
> Это делается потому что glibc на самом деле не одна библиотека, а
> несколько (всякие там подгружаемые модули libnss). И если апгрейд таков,
> что процессы, подгрузившие старый libc.so не смогут при необходимости
> работать с новыми libnss, которые им захочется подгрузить позже,
> при завершении апгрейда процессы перезапускают.
>
> Кроме уже рассмотренного системного вызова unlink(2) есть еще вызов
> rename(2). Он отличается тем, что работает атоммарно. Поэтому если
> записать файл на диск под именем something.tmp а потом удалить старый
> something и переименовать something.tmp в something, время когда на
> диске не существует корректного файла c именем something (либо старого, либо
> нового) будет минимальным.
Как говорится - подали на ложечке. Вообще спасибо всем учасникам.
Как бы дальше осмысляя появился ряд "странных" вопросов:
* У программы есть ресурсы, например иконки, раскиданые по файлам, которые
загружаюся по необходимости. Если я обновлю пакет и программа из пакета
будет запущенной - то новые запросы на ресурсы вернут дескрипторы на
обновленные файлы. А ведь файлы могут быть переименоваными в пакете или
изменен формат данных - т.е. будет плохо?
* Если доступаться к файлам пакета по требованию не безопасно с точки зрения
возможности обновлять пакет "in place" - стоит ли писать/переписать
программу в стиле - открыть все возможные файлы, а затем использовать
полученые дескрипторы?
--
Best regards!
Reply to: