Jerry Jelinek's Weblog: Jerry Jelinek's Weblog

In an earlier blog I talked about using a USB memory disk to store a Solaris Volume Manager (SVM) metadb on a two-disk configuration. This would reduce the likelihood of hitting the mddb quorum problem I have talked about. The biggest problem with this approach is that there was no way to control where SVM would place its optimized resync regions. I just putback a fix for this limitation this week. It should be showing up in an upcoming Solaris Express release in the near future. With this fix the code will no longer place the optimized resync regions on a USB disk or any other removable disk for that matter. The only I/O to these devices should be the SVM configuration change writes or the initialization reads of the metadbs, which is a lot less frequent than the optimized resync writes.

I had another interesting experience this week. I was working on a bug fix for the latest release of Solaris and I had to run a test of an x86 upgrade for S2.7 with a Solstice DiskSuite (SDS) 4.2 root mirror to the latest release of Solaris. This was interesting to me for a number of reasons. First this code is over 6 years old but because of the long support lifetimes for Solaris releases we still have to be sure things like this will work. Second, it was truly painful to see this ancient release of Solaris and SDS running on x86. It was quite a reminder of how far Solaris 10 has come on the x86 platform. It will be exciting to see where the Solaris community takes Open Solaris on the x86 platform, as well as other platforms, over the next few years.