Mike Gerdts wrote: > [Removed OP from reply, added zones-discuss, updated subject] > > On 3/29/07, Dave Miner <Dave.Miner at sun.com> wrote: >>>>> Are there any parts of flash that can be opened? Any interface specs, >>>>> ARC cases, etc? These would be great improvements that the community >>>>> could work on. >>>>> >>>> Flash has some unresolved issues in opening the code. However, now that >>>> you mention it, the specs and ARC cases actually should be clean, such >>>> that you and other interested parties could work on a clean-room >>>> version. I'll look into that a bit and see what I can sort out. >>> Cool - that would be extremely helpful. Initially I was resigned to >>> just wait for the next generation of the related technologies to come >>> out. Then I noticed that there were lots of lu* commands used during >>> zone creation. With zone creation being such a key part of life with >>> Solaris, it really seems as though this needs to be open for the >>> community to work with it. >>> >> Yeah, that piece is somewhat problematic, though the reliance on LU >> there is mostly for infrastructure, and not much on the actual LU >> functionality. The "plan" kicking around in my head was to break the >> connection by cutting zone installation over to using essentially the >> same code as zone cloning; there's a fair amount of similarity already, >> anyway. > > Sounds good on the surface, but some details suggest a devil is > lurking somewhere nearby. How does this play with zones that use > inherit-pkg-dir? How about files that are added but not part of a > package? >
It strongly relates to going to ZFS as the root file system, as that's where I'd expect there to be significant improvement. By basing the install of non-global zones off a snapshot of the original installed file systems in the global (which is something we expect to keep), you avoid the files that aren't part of packages. Patching remains interesting, of course; it's probably in the same realm of difficulty as what we already do with the spooled originals of editable & volatile files, but possibly a bit cleaner. Yes, there are plenty of devilish details left there ;-) > When a zone is cloned, there is the implication that you want all of > the customizations (sans sysidcfg stuff) to come over as well. If the > global zone is cloned, this is likely not the case and as such more > care should be taken to only take what is part of the package > database. That puts us in a situation where we are doing something > like reading /var/sadm/install/contents filtering out all of the > files/dirs in an inherit-pkg-dir, removing /dev entries, etc. to > generate a list of files to give to cpio. I suspect this is pretty > much what ludo/lucreatezone is already doing. > Essentially. > An interesting question comes up when ZFS root comes about. Could the > global zone be cloned to form full-root non-global zones? If /usr, > /lib, /platform and /sbin are separate zfs file systems in the global > zone, could the global zone be cloned to form sparse non-global zones? > Arguably the value of sparse zones goes down substantially when ZFS > clones are involved, but it does provide interesting food for thought. > Sparse zones present some problems in packaging that we haven't solved, so I wouldn't mind if they went away ;-) Doubt it's that simple, though. Dave
