On 3/28/07, Dave Miner <Dave.Miner at sun.com> wrote: > Mike Gerdts wrote: > > But it would be a fairly trivial change to make to support this mode > > of operation. Flash archives typically have multiple sections. A > > section could be created that includes an archive of the files that > > normally get destroyed. Another section could be created to contain a > > jumpstart profile[1] that would partition the disks appropriately as > > well as contain JASS or JET to perform the necessary customizations > > (e. g. soft partitions, tweaking eeprom settings, re-applying the > > sysidconfig-related files, etc.) that are typically outside of the > > scope of what flash archives do. > > > > [1] The jumpstart profile could be extracted via a special begin > > script that extracts this section from the flar. This extracted > > profile would be treated as a derived profile in the current jumpstart > > architecture. > > > > I wouldn't generally apply the adjective "trivial" to what you describe > here, maybe "straightforward", but I agree they are a thoroughly > sensible set of enhancements. Somewhere on the Caiman roadmap I've > suggested we would flesh out Flash or something like it into a more > complete recovery and replication solution, and this is the sort of > thing I had in mind.
Taken as a whole, the paragraph definitely went well past the trivial deep into the straightforward or more realm. Creating a flash archive that doesn't make an effort to exclude files should be much closer to the trivial line than some of the other things mentioned. > To at least answer (though not satisfactorily, I'm sure) your comment: > the reason why things seem to have "no traction" is that the number of > engineers we currently have available to work on > installation/packaging/patching projects, enhancements, and bugs is in > the high single digits. That means we prioritize rather aggressively, > and that means even worthy things such as the sun4u/4v issue just don't > get addressed. I hope that will change. I understand completely. We all have to set priorities or work within the priorities set by others. > > 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. Mike -- Mike Gerdts http://mgerdts.blogspot.com/
