metaset and state database slice question

From: Lineberger, Aaron (alineberger@navcirt.navy.mil)
Date: Mon Jun 13 2005 - 16:39:38 EDT


All,

I have a general metaset question for anyone using SVM on Solaris 9 that
has migrated from a single system to two systems using disk sets. The
metaset man page states:

For use in disk sets, disks must have a dedicated slice (six or seven)
that meets specific criteria:
        o Slice must start at sector 0
        o Slice must include enough space for disk label
        o State database replicas cannot be mounted and does not
           overlap with any other slices, including slice 2

The third statement was the one that really caught my attention as I
have always seen examples on this list which show slice 2 to be the
entire disk which overlaps slice 7 which holds the state database
information.

Out of sheer curiosity, can anyone explain why this is part of the
criteria for disk sets? I find it interesting that it's not mentioned in
the metadb man page.

As for migrating a system into an environment where it will use disk
sets with another host, does this mean that just because slice 2 gets
changed to accommodate this criteria that I need to back up and then
restore the data on slice 0 even though the actual sizes of slice 0 and
slice 7 will not change? Judging by the man page it would seem that this
is the case:

     If the existing partition table does not meet these cri-
     teria, Solaris Volume Manager repartitions the disk. A por-
     tion of each drive is reserved in slice 7 (or slice 6 on an
     EFI labelled device), for use by Solaris Volume Manager. The
     remainder of the space on each drive is placed into slice 0.
     Any existing data on the disks is lost by repartitioning.

Anyone have thoughts on this or experience in adding a second system to
an existing SVM configuration?

Please reply to the list and not to my email address. TIA

Aaron Lineberger
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers



This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:30:53 EDT