Mike Gerdts wrote: > On 3/28/07, Dave Miner <Dave.Miner at sun.com> wrote: >> Reviewing the blog entry you're referring to[1], yes, it's true, >> although it's a fairly fine distinction. Flash isn't a classic backup >> solution, as for most people backup means getting back *all* of the >> files *exactly* as they were at the time of the backup. Flash doesn't > > 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. ... > There's a laundry list of enhancements at least as good as this that I > would file if I had any real hope that they would be worked on by Sun > or the community[2]. As it is, really easy changes like "use gzip > instead of compress" and really important things like "allow a single > flar to work on sun4u and sun4v" seem to have no traction. > 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. > [2] Not trying to exclude myself. I have a very strong interest in > these areas and would contribute as time and employer sponsorship > allows. > > 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. Dave
