Search
Close this search box.

Month: May 2005

In a previous
blog
I talked about integration of Solaris Volume Manager (SVM) and
RCM. Proper integration of SVM with the other subsystems in Solaris
is one of the things I am particularly interested in.

Today I’d like to talk about some of the work I did to integrate
SVM with the new Service Management Facility (

SMF
)
that was introduced in S10.
Previously SVM had a couple of RC scripts that would run when the
system booted, even if you had not configured SVM and were not using
any metadevices. There were also several SVM specific RPC daemons
that were enabled. One of the ideas behind SMF is that only the services
that are actually needed should be enabled. This speeds up
boot and makes for a cleaner system. Another thing is that not
all of the RPC daemons need to be enabled when using SVM. Different
daemons will be used based upon the way SVM is configured.
SMF allows us to clean this up and manage these services within the code
so that the proper services are enabled and disabled as you
reconfigure SVM.

The following is a list of the services used by SVM:

svc:/network/rpc/mdcomm

svc:/network/rpc/metamed

svc:/network/rpc/metamh

svc:/network/rpc/meta

svc:/system/metainit

svc:/system/mdmonitor

The system/mdmonitor, system/metainit and network/rpc/meta services are the
core services. These will be enabled when you create the first metadb.
Once you create your first diskset the network/rpc/metamed and
network/rpc/metamh services will be enabled. When you create your first
multi-node diskset the network/rpc/mdcomm service will also be enabled.
As you delete these portions of your configuration the corresponding
services will be disabled.

Integrating this coordination of SVM and SMF is easy since SMF offers
a full API which allows programs to monitor and reconfigure the services
they use. The primary functions used are smf_get_state, smf_enable_instance
and smf_disable_instance, all of which are documented on the

smf_enable_instance(3SCF)
)
man page. This could have all be done previously using various hacks to
rename scripts and edit configuration files in various ways but it is trivially
simple with SMF. Furthermore, the code can always tell when there is something
wrong with the services it depends on. Recently I integrated some new code
that will notify you whenever you check the status of SVM with one of the CLI commands (metastat,
metaset or metadb) and there is a problem with the SVM services. We have barely scratched the service
here but SMF lays a good foundation for enabling us to deliver a true
self-healing system.

Sanjay Nadkarni,
another member of the Solaris Volume Manager engineering team
has just started a
blog.
Sanjay was the technical lead for the project
that added new clustering capabilities to SVM so that it can now support
concurrent readers and writers. If you read my blog because
you are interested in SVM you will want to take a look at his too.
Welcome Sanjay.

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.

Recent Posts

September 23, 2010
September 13, 2010
May 26, 2009

Archives