Dave;
Every executable or library already loaded into memory has a backing
store attached to them, anonymous or otherwise. Executables in memory
have a backing store which naturally points back to the original binary
executable (or library) file on disk (file system), referenced in memory
by the vnode, then translated to the actual inode.
If you mount in place a similar file image on top of the original, would
not the in memory file reference (e.g. vnode/inode) be different? It's
on a different "file system" after all.
Forgive me, but I fail to see how a mount in place can help protect the
original, much less increase the stability of the system.
I readily concede that the newly developed system properly works, since
it has now been tested and released by Sun. But I was hoping if Sun or
the folks here could provide a more detailed explanation.
Also, does the procedure require the administrator to undertake any
special steps? Or would it be completely transparent to the admin?
Warmest Regards
Steven Sim
Dave Miner wrote:
Steven Sim wrote:
Folks;
Today Sun BIG ADMIN website posted an article by Lynne Thompson
entitled "What's New in Patching "
See http://www.sun.com/bigadmin/sundocs/articles/patch-wn.jsp
Could somebody here elaborate more on the following statement....
".........Now, deferred-activation patching uses the loopback file
system (lofs) to ensure the stability of the running system. When a
patch is applied to the running system, the lofs preserves stability
during the patching process. These large kernel patches have always
required a reboot, but now the required reboot activates the changes
made by the lofs."..
It's a bit confusing......especially the part about "lofs preserves
stability during the patching process"....
Hopefully I can get one of those who actually did the work to post a
blog entry about it. Anyway, the executables and libraries which need
to remain stable during the entire duration of the patching
application and would be affected by the patch operation are copied
into a temporary location, lofs is used to mount them up into the
original location, and then we can patch the originals without
adversely affecting the binaries in use. You must reboot at the end
of such a patch application to get the system back into a consistent
state.
Live Upgrade for patching is still recommended, since it's at least as
safe and doesn't require quiescing the system to apply such patches,
but this provides an alternative when that is not an option.
Dave
Fujitsu Asia Pte. Ltd.
_____________________________________________________
This e-mail is confidential and may also be privileged. If you are not the intended recipient, please notify us immediately. You should not copy or use it for any purpose, nor disclose its contents to any other person.
Opinions, conclusions and other information in this message that do not relate
to the official business of my firm shall be understood as neither given nor
endorsed by it.
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
