Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Delete all SVM metadevices

275 views
Skip to first unread message

js

unread,
Oct 27, 2005, 3:08:49 AM10/27/05
to

Solaris 9

I have metadevices that I cannot get rid of.

Is there a way to wipe out all SVM devices by say ... deleting all metadb
state repliaces in both the local state database and diskset state
database ?

What about deleting disksets in an unconventional way ?? At the moment, I
cannot even access the disksets, as I am getting "metaset: syddb280r: No
such device".

So I would really like a way to wipe out all SVM devices and disksets
WITHOUT having to reinstall Solaris.


1) Cannot take ownership or delete a metaset:

# metaset -s testset

Set name = testset, Set number = 2

Host Owner
syddb280r
syddbe220r

Drive Dbase

c3t0d5 Yes

c4t0d5 Yes

# metaset -s testset -t -f
metaset: syddb280r: testset: there are no existing databases

bash-2.05# metaset -s testset -t
metaset: syddb280r: testset: there are no existing databases

bash-2.05# metaset -s testset -d c3t0d5
metaset: syddb280r: testset: must be owner of the set for this command

2) The device ID is no longer up to date with SVM ... eventually
ending up with "metastat: No such device "

$ metastat -s shared3310 d50

shared3310/d50: Mirror
Submirror 0: shared3310/d51
State: Needs maintenance
Submirror 1: shared3310/d52
State: Needs maintenance
Pass: 1
Read option: roundrobin (default)
Write option: parallel (default)
Size: 204767040 blocks (97 GB)

shared3310/d51: Submirror of shared3310/d50
State: Needs maintenance
Invoke: metasync shared3310/d50
Size: 204767040 blocks (97 GB)
Stripe 0:
Device Start Block Dbase State Reloc Hot
Spare
c3t0d4s0 0 No Okay Yes


shared3310/d52: Submirror of shared3310/d50
State: Needs maintenance
Invoke: metasync shared3310/d50
Size: 204767040 blocks (97 GB)
Stripe 0:
Device Start Block Dbase State Reloc Hot
Spare
c4t0d4s0 0 No Okay Yes


Device Relocation Information:
Device Reloc Device ID


< ... snip ...>

I tried to detach the submirrors, but I then get the
following errors:


bash-2.05# metadetach -s shared3310 -f d50 d52
metadetach: syddb280r: shared3310/d50: resync in
progress

bash-2.05# metadetach -s shared3310 -f d50 d51
metadetach: syddb280r: shared3310/d50: resync in
progress


# metadb -i -s shared3310
flags first blk block count
a m luo 16 8192 /dev/dsk/c3t0d0s7
a luo 16 8192 /dev/dsk/c3t0d1s7
a luo 16 8192 /dev/dsk/c3t0d2s7
a luo 16 8192 /dev/dsk/c3t0d3s7
M 16 unknown /dev/dsk/c3t0d4s7
a luo 16 8192 /dev/dsk/c4t0d0s7
a luo 16 8192 /dev/dsk/c4t0d1s7
a luo 16 8192 /dev/dsk/c4t0d2s7
a luo 16 8192 /dev/dsk/c4t0d3s7
M 16 unknown /dev/dsk/c4t0d4s7


# metadb -s shared3310 -d c4t0d4s7

# metadb -s shared3310 -a c4t0d4s7


# metadb -i -s shared3310
flags first blk block count
a m luo 16 8192 /dev/dsk/c3t0d0s7
a luo 16 8192 /dev/dsk/c3t0d1s7
a luo 16 8192 /dev/dsk/c3t0d2s7
a luo 16 8192 /dev/dsk/c3t0d3s7
M 16 unknown /dev/dsk/c3t0d4s7
a luo 16 8192 /dev/dsk/c4t0d0s7
a luo 16 8192 /dev/dsk/c4t0d1s7
a luo 16 8192 /dev/dsk/c4t0d2s7
a luo 16 8192 /dev/dsk/c4t0d3s7
a u 16 8192 /dev/dsk/c4t0d4s7

# metastat -s shared3310 d50
metastat: syddb280r: No such device

# metastat -s shared3310 d30
metastat: syddb280r: No such device

# metastat -s shared3310
metastat: syddb280r: No such device

# metaset -s shared3310
metaset: syddb280r: No such device

Mr. Johan Andersson

unread,
Oct 27, 2005, 4:28:28 AM10/27/05
to

On Thu, 27 Oct 2005, js wrote:

>
> Solaris 9
>
> I have metadevices that I cannot get rid of.
>
> Is there a way to wipe out all SVM devices by say ... deleting all metadb
> state repliaces in both the local state database and diskset state
> database ?
>
> What about deleting disksets in an unconventional way ?? At the moment, I
> cannot even access the disksets, as I am getting "metaset: syddb280r: No
> such device".
>
> So I would really like a way to wipe out all SVM devices and disksets
> WITHOUT having to reinstall Solaris.

<lots of metastat data snipped>

Not one of your commands seesm to have tried adding the -f flag to your
arguments, i.e. force it whatever the error.

IF that fails, then we can investigate further.

IF you cant remove the metasets, then you can remove the "local set" and
reinitiate that, that should wipe any knwledge about the metasets from it.

/Johan A

js

unread,
Oct 27, 2005, 9:27:43 AM10/27/05
to
Mr. Johan Andersson wrote:

>
> On Thu, 27 Oct 2005, js wrote:
>
>>
>>
>> Is there a way to wipe out all SVM devices by say ... deleting all metadb
>> state repliaces in both the local state database and diskset state
>> database ?
>>
>> What about deleting disksets in an unconventional way ?? At the moment, I
>> cannot even access the disksets, as I am getting "metaset: syddb280r: No
>> such device".
>>
>> So I would really like a way to wipe out all SVM devices and disksets
>> WITHOUT having to reinstall Solaris.
>
> <lots of metastat data snipped>
>
> Not one of your commands seesm to have tried adding the -f flag to your
> arguments, i.e. force it whatever the error.

Believe me ... I tried

>
> IF that fails, then we can investigate further.
>
> IF you cant remove the metasets, then you can remove the "local set" and
> reinitiate that, that should wipe any knwledge about the metasets from it.
>

That's what I thought, I just wanted confirmation from someone who knows
better. Since disksets have their own metadbs, and they are not listed
in /etc/lvm/* , ... SVM must know if the location of the state replicas for
disksets from the local disksets.

If I then recreate the disksets, I presume SVM will not read any existing
diskset state database replicas that previously existed on the disks.


js

unread,
Oct 27, 2005, 9:35:11 AM10/27/05
to
js wrote:

>
> That's what I thought, I just wanted confirmation from someone who knows
> better. Since disksets have their own metadbs, and they are not listed
> in /etc/lvm/* , ... SVM must know if the location of the state replicas
> for disksets from the local disksets.

That should have read:

Since disksets have their own metadbs, and they are not listed

in /etc/lvm/* , ... SVM must know of the location of the state replicas
for disksets from the local metadb

Having said that, you actually said:

== IF you cant remove the metasets, then you can remove the "local set" and
== reinitiate that, that should wipe any knwledge about the metasets from
it.

I actually originally read that you meant "remove the local state replicas".
Meaning, I presume you meant "metadb -d", without specifying any diskset
parameter, until all local state replicas are deleted, will effectively
wipe out any knowledge of disk sets.

Then I can recreate the disk sets again by first creating new local state
replicas.

Mr. Johan Andersson

unread,
Oct 27, 2005, 10:20:11 AM10/27/05
to

On Thu, 27 Oct 2005, js wrote:

> js wrote:
>
> >
> > That's what I thought, I just wanted confirmation from someone who knows
> > better. Since disksets have their own metadbs, and they are not listed
> > in /etc/lvm/* , ... SVM must know if the location of the state replicas
> > for disksets from the local disksets.
>
> That should have read:
>
> Since disksets have their own metadbs, and they are not listed
> in /etc/lvm/* , ... SVM must know of the location of the state replicas
> for disksets from the local metadb

This is what I ment and belive yes...

> Having said that, you actually said:
>
> == IF you cant remove the metasets, then you can remove the "local set" and
> == reinitiate that, that should wipe any knwledge about the metasets from
> it.
>
> I actually originally read that you meant "remove the local state replicas".
> Meaning, I presume you meant "metadb -d", without specifying any diskset
> parameter, until all local state replicas are deleted, will effectively
> wipe out any knowledge of disk sets.

Yes, basically that means recreating your default metaset and all in it,
not a big problem if you know what you are doing.

when you specify any meta command and dont give a -s <metaset> you are
working with the default metaset, if you clean that, i.e remove all
metadevices and metadatabases and start over, it should NOT remember that
you had such before.

> Then I can recreate the disk sets again by first creating new local state
> replicas.

I believe that should work, was a while since I needed to do something
like that though so I am not 100% sure, you might need to reboot "out of
SDS" to clear in memory data, but I am as I said unsure of that.

/Johan A

js

unread,
Oct 28, 2005, 3:05:09 AM10/28/05
to
js wrote:

>
> 1) Cannot take ownership or delete a metaset:
>
> # metaset -s testset
>
> Set name = testset, Set number = 2
>
> Host Owner
> syddb280r
> syddbe220r
>
> Drive Dbase
>
> c3t0d5 Yes
>
> c4t0d5 Yes
>
> # metaset -s testset -t -f
> metaset: syddb280r: testset: there are no existing databases
>
> bash-2.05# metaset -s testset -t
> metaset: syddb280r: testset: there are no existing databases
>
> bash-2.05# metaset -s testset -d c3t0d5
> metaset: syddb280r: testset: must be owner of the set for this command
>

Sun support offered this gem:

metaset -s testset -P

... and the diskset is now gone.

Interestingly, the -P option is not in the man page of metaset in Solaris9,
but it seems that it is in Solaris10. Fortunately, it also works on
Solaris9.


John de Sousa

unread,
Mar 21, 2023, 12:19:40 PM3/21/23
to
18 years later and I needed this info, the -P is a gem indeed!

YTC#1

unread,
Mar 22, 2023, 7:47:09 AM3/22/23
to
Hi John :-) You mut still be working on some old kit then :-)


--
Bruce Porter
"The internet is a huge and diverse community but mainly friendly"
http://ytc1.blogspot.co.uk/
There *is* an alternative! http://www.openoffice.org/

Marco Moock

unread,
Mar 22, 2023, 2:22:13 PM3/22/23
to
Am 22.03.2023 um 11:47:04 Uhr schrieb YTC#1:

> On 21/03/2023 16:19, John de Sousa wrote:
> > 18 years later and I needed this info, the -P is a gem indeed!
>
> Hi John :-) You mut still be working on some old kit then :-)

No, Solaris even runs on new x64 hardware - I tried it out last week in
VirtualBox.

YTC#1

unread,
Mar 23, 2023, 5:16:59 AM3/23/23
to
You misunderstood my comment, it was about the use of SVM/ODS/SDS, not
Solaris.

I still work with Solaris (all versions), usually SPARC, and only come
across SVM on Sol 8 or 9 instances (or very early S10), and these are
usually servers that are being migrated to newer tin (LDoms/zones),
whenever possible I will get the client to shift to ZFS.

I also know John, and the government depts he often works at, and am
surprised that there is still stuff to be modernised.
0 new messages