SVM metadbs, USB disks and S2.7

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.