Is there any particular reason to keep it that way (Global first and local next)? Is it not a good idea to do patchadd (yes, of course the pkgadd also will have to be changed to tread this path, if we accept this change) on local first and global in the last?
Regards, Narendra On 10/19/06, Enda O'Connor ( Sun Micro Systems Ireland) < Enda.Oconnor at sun.com> wrote: > > Hi > First pdo analyses the global and all non global zones to determine if > the patch or patches can be applied. > From that a list of applicable patches is generated. > If only one patch was specified for install, then pdo > calls /usr/lib/patch/patchadd in the global to do the patching in the > global > and then calls > /usr/lib/patch/patchadd in each local zone in a serial manner to do the > patching in the local zones. So we patch global, followed by each zone > in sequence. > > If we specified a list or directory of patches then once the analysis > phase has completed and we have a list of applicable patches we: > 1 call /usr/lib/patch/patchadd in the global to add all the patches in > the global first > 2 then call /usr/lib/patch/patchadd in each local zone to add the list > of patches to each zone. > > So in the last case if we are adding 5 patches and we have two zones > zone-1 and zone-2 > first > 1 add all 5 patches to the global > 2 then add all five patches to zone-1 > 3 then add all five patches to zone-2 > > > Enda > "??????? ??????.???.?? =?UTF-8?Q?=E0=B3=8D(Narendra_Kumar.S.S, > ssnkumar at gmail.com" wrote: > > Hello Vasilly, > > > > From the above explanation, what I understood is, "Patches will be > > installed in local zones first and then in global zones". > > I this understanding correct? > > > > Regards, > > Narendra > > > > > > > > On 10/19/06, *Vasiliy* <vassun at gmail.com <mailto:vassun at gmail.com>> > wrote: > > > > I was asked to provide some information on pdo.c - new patch > > dependency algorithm introduced in Solaris 10 FCS. It is complicated > > code, just because it is complicated staff it is dealing with and so > > I decide that best place to do some introduction will be here - > > available for everybody in one place. > > > > I will keep it in usual format step by step, post by post describing > > the matter - some kind of "Arabian Nights" of packaging-patching... > > > > [b]Why new code was introduced?[/b] > > > > 1. Two phase transaction patching. > > > > Some patches affects are shared between zones. This patches need to > > be checked for all zones first and only when everything OK with all > > zones we may apply this patches to shared are. This is classic two > > phase distributed transaction, when we check success on all nodes > > and then commit or rollback changes everywhere. Patchadd.ksh script > > was not suited for this, our estimates was that it will be much easy > > to reimplement it on C (and we had it partially reimplemented > > already for different project) then try to use what we had. > > > > 2. Performance, performance, performance. > > > > Any install operation time with zones will be performed as many > > times as many zones present. It there is 10 zones it will be 10 > > times slower. We tried to run pkgadd in parallel and in result it > > was much slower then even sequential execution just because all > > installation operation is about disk access and parallelization will > > not help. So zones existence expose any install performance problem > > as magnifying glass as many times as many zones involved. There are > > no simple tricks to speed it up and only way to resolve it - improve > > performance of installation itself. > > > > Ksh-script (patchadd before S10) obviously not a right solution for > > performance problems. Any operation like check required patch will > > involve awk, grep, sed etc... - which are unix process each. Also by > > nature dependency check algorithm is classical "recursive walk over > > tree" and kshell script language does not support it very well from > > data structure point of view as well as from algorithm coding. > > > > C - language implementation looks just right for this kind of > > problem and allows to make performance as good as possible. It has > > hashtable for PatchIds and prelinked in both directions relations > > etc. It is pretty simple to outperform kshell script 100 times and > > more. > > > > Also it allows to introduce real multipatching which is also matter > > of performance as well as convenience for customer. Manual ordering > > for patches painful already but with zones it may be just > impossible. > > > > [b][i]"...At this point Shahrazad saw the approach of morning and > > discreetly fell silent..."[/i][/b] > > The book of thousand and one night. by Powys Mathers > > > > Next I will talk about patch dependencies... > > > > vassun > > > > > > This message posted from opensolaris.org <http://opensolaris.org> > > _______________________________________________ > > install-discuss mailing list > > install-discuss at opensolaris.org <mailto: > install-discuss at opensolaris.org> > > http://opensolaris.org/mailman/listinfo/install-discuss > > > > > > > > > > -- > > Warm Regards, > > ??????? ??????.???.??? > > (S.S.Narendra Kumar) > > > > Visit my blogs at: > > http://ssnarendrakumar.blogspot.com/ > > http://blogs.sun.com/roller/page/ssnkumar > > ___ ___ __ _ > > / __/ / __/ / | / / > > _\ \ _ \ \ / /| |/ / > > \___/ \___/ /_/ |__/ > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > install-discuss mailing list > > install-discuss at opensolaris.org > > http://opensolaris.org/mailman/listinfo/install-discuss > > -- Warm Regards, ??????? ??????.???.??? (S.S.Narendra Kumar) Visit my blogs at: http://ssnarendrakumar.blogspot.com/ http://blogs.sun.com/roller/page/ssnkumar ___ ___ __ _ / __/ / __/ / | / / _\ \ _ \ \ / /| |/ / \___/ \___/ /_/ |__/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/install-discuss/attachments/20061019/9bf0c260/attachment.html>
