James,
The issue seem to repro even after installing patch 118822-30 on Solaris 10
update 1 machine. After this problem even the original disk set becomes
unusable. I tried to work around the problem by importing the original disk
set after creating a new metadb disk. But even that fails with unknown error.
>>>> CREATE NEW STATE DATABASE REPLICA
bash-3.00# metadb -a -f c2t32d0s0
>>>> CHECK WHETHER STATE DATABASE REPLICA IS CREATED
bash-3.00# metadb
flags first blk block count
a m pc luo 16 8192 /dev/dsk/c2t32d0s0
bash-3.00#
>>>>> SEE WHETHER ORIGINAL DISK SET IS IMPORTABLE
bash-3.00# metaimport -r -v
Import: metaimport -s <newsetname> c2t11d0
Last update: Thu Sep 21 01:01:25 2006
Device offset length replica flags
c2t11d0 16 8192 a u
bash-3.00#
>>>> TRY IMPORTING THE ORIGINAL DISK SET
bash-3.00# metaimport -s test_dg c2t11d0
Drives in replicated diskset including disk c2t11d0:
c2t11d0
More info:
metaimport -r -v c2t11d0
metaimport: sun198-07: Unknown error
bash-3.00#
Hence should I file a bug to get this issue fixed?
Thanks,
-Kumar.
> James,
>
> We are not using autotake disk sets. Hence when
> we try to take over the disk set we get the
> following error.
>
> bash-3.00# metaset -s test_dg -t
> metaset: sun198-06: there are no existing databases
>
> bash-3.00#
>
> By the way this issue happens intermittently and
> it doesn't happen consistently. Right now I tried to
> repro the same issue but it is not reproing now for
> me. And another issue that we face quite often is
> that mdmonitor service going to maintenance mode
> after reboot. This happens quite consistently and we
> have clear the maintenance flag and restart the
> service after reboot for mdmonitor to come online.
>
> Thanks,
> -Kumar.
>
> > Kumar,
> >
> > Is this a cluster, or are you using auto-take
> > e metasets ? If not then
> > you have to take ownership of the set manually
> after
> > rebooting with
> > metaset -s {setname} -t.
> >
> > If this is being used but failing, can you get the
> > e error message
> > returned please ? The output from metaset in step
> 4
> > would also be useful.
> >
> > James.
> >
> > Kumaravel Thillai wrote:
> > > Hi,
> > >
> > > We seem to hit an issue with SVM in the
> > following scenario. Hence can you please let me
> know
> > whether this is a know issue with SVM and it is
> fixed
> > or not? If it is not a known issue then any help
> on
> > this issue is appreciated.
> > >
> > > Steps to repro this issue.
> > >
> > > 1. Clone disks (LUs) that contain a disk set on
> > the storage server
> > > 2. Map the cloned disks to host so that LUs are
> > now accessible from the host on which the original
> > disk set is available
> > > 3. Instead of running "metaimport" command to
> > import the cloned disk set just reboot the system
> > > 4. After reboot do metset of original disk set
> > > 5. SVM says the ownership of the original disk
> set
> > is not with the host and no operation can be
> > performed on the original disk set.
> > >
> > > Thanks,
> > > -Kumar.
> > >
> > >
> > > This message posted from opensolaris.org
> > > _______________________________________________
> > > lvm-discuss mailing list
> > > lvm-discuss at opensolaris.org
> > _______________________________________________
> > lvm-discuss mailing list
> > lvm-discuss at opensolaris.org
> >
This message posted from opensolaris.org
