🚀 go-pugleaf

Marek <fake@fakeemail.com> wrote:
> On Tue, 26 Nov 2013 08:47:34 +0000 (UTC), toslaw <sorry@nomail.4u.pl> 
> wrote:
>> Plus, istnieją też dodatkowe opcje update'owania aktualnie używanych 
>> plików systemowych o nazwie hot-patching. Polega to na modyfikowaniu 
>> początków eksportowanych funkcji przez biblioteki systemowe tak, aby 
>> skakały do nowych wersji funkcji, omijając stare, do pierwszego 
>> restartu. Dopiero po restarcie pliki są podmieniane, całkowicie 
>> usuwając stare wersje funkcji. W oczywisty sposób to wymaga 
>> synchronizacji z resztą części w systemie, wpływając na dodatkowe 
>> opóźnienie.

> To jest jakiś absurd. Rozwiązanie, które od razu by design wymaga 
> restartu. 20 lat developingu i ciągle mają w tym MS jakas fixacje na 
> punkcie tych restartów. A unixach wystarczy aby proces upate'u zrobil 
> unlink lib.so a nastepnie cp newlib.so lib.so. Procesy uruchomione i 
> zlinkowane z lib.so (starą wersją) będą nadal działać ze starą lib 
> (unlink nie usunie fizycznie z dysku otwartej lib przez inny proces, 
> plik znika tylko z dirlist) a nowo ładowane procesy już będą 
> zlinkowane z nowa wersją lib.so. Stare procesy/usługi wystarczy 
> zrestartować aby skorzystały już z nowych funkcji lib.so.
> I nie ma potrzeby restartowania systemu. Rozwiązanie proste i 
> genialne w swojej prostocie, bo wykorzystuje natywne mechanizmy 
> dostępu do fs.

Pod Uniksami w przeciwieństwie do Windowsa nie ma po prostu działającego 
mechanizmu file lockingu[1][2] więc nie było dotąd motywacji aby 
realizować aktualizację prawidłowo. Jednak to się zmienia np. Fedora 
idzie drogą Windowsa z Offline System Updates[3]. Inne dystrybucje także 
są świadome problemów z takim działaniem aktualizacji. Debian od zawsze 
upgrade dystrybucji zalecał robić nie spod środowiska graficznego.

1. http://0pointer.de/blog/projects/locking.html
2. http://0pointer.de/blog/projects/locking2
3. http://fedoraproject.org/wiki/Features/OfflineSystemUpdates
-- 
Piotr Borkowski