SUMMARY: Upgrade of disk and now Mirror different size to Submirror

From: Andy Ford <andy.ford_at_telindus.co.uk>
Date: Wed Nov 03 2004 - 09:50:00 EST
Thanks to Darren Dunham for pointing out that the mirror size was
different to the submirror size.

I did some probing to find out what I needed to do.
If you are interested - follow this link and check out the Unix
section ......

http://www.idevelopment.info/

Essentially, after the upgrade to the 36GB disk from the 18GB disk, I
needed to detach the d7 mirror (the only one that had changed in size),
and re-attach it.

I did ..

>metadetach d7 27
d7: submirror d27 is detached

>metadetach d7 d17
metadetach: d7: attempt to detach last running submirror

>metaclear d27
d27: Concat/Stripe is cleared

>metaclear d7 (this gets rid of the mirror itself)
d7: Mirror is cleared

Then I 
	- re-initialised d17 and d27 with 
		- metainit d17 1 1 c1t0d0s7
		- metainit d27 1 1 c1t1d0s7
	- re-initialised d7 with d17 with 
		metainit d7 -m d17
	- attached d27 with
		- metattach d7 d27
	- waited for the resynch to complete
	- created the ufs filesystem with 
		-newfs /dev/md/rdsk/d7

Then remounted d7, and it worked

Andy

--------------------------------------------------------------------------

Moving on from my previous post (metadisk and moving partition from
rawfs to ufs) I have found an issue where we upgraded two mirrored disks
from 18GB to 36GB some time ago.

What I didn't notice (kindly pointed out by Darren Dunham) was that the
Mirror has a different size to the Submirrors. i.e.

metastat d7...

d7: Mirror
    Submirror 0: d17
      State: Okay         
    Submirror 1: d27
      State: Okay         
    Pass: 1
    Read option: roundrobin (default)
    Write option: parallel (default)
    Size: 11134456 blocks

d17: Submirror of d7
    State: Okay         
    Size: 46137600 blocks
    Stripe 0:
        Device              Start Block  Dbase State        Hot Spare
        c1t0d0s7                   0     No    Okay         


d27: Submirror of d7
    State: Okay         
    Size: 46137600 blocks
    Stripe 0:
        Device              Start Block  Dbase State        Hot Spare
        c1t1d0s7                   0     No    Okay         

Anyone know ho I can fix this problem. This is definitely the issue I am
having with running out of space on this slice.

The odd thing is, df -k reports the slice as ~22GB but the d7 mirror
reports it as ~5.5GB

Any suggestions would be welcomed with open arms

Thanks

Andy


-------- Forwarded Message --------
From: Andy Ford <andy.ford@telindus.co.uk>
To: sunmanagers <sunmanagers@sunmanagers.org>
Subject: metadisk and moving partition from rawfs to ufs
Date: Tue, 02 Nov 2004 10:07:41 +0000
Hi everyone

I have recently moved a rawfs partition to a ufs partition to satisfy
upgrading of an application (InfoVista).
I have two disks that are mirrored where slice 7 is used for the
InfoVista databases. Slice 7 (/dev/md/dsk/d7) is now mounted
on /InfoVista.

The partitions are 22GB in size but I seem to be having problems writing
large amounts of data to them.

I have written a small perl file that writes a counter to a file
in /InfoVista/file but it doesn't get past line 9038.

I have a couple of questions

 1. Is it possible to physically damage the disk while using md
 2. How else can I prove that I have problems with this slice

Thanks

Andy
--
perl -e "print qq^bIG VeRN ! ^^qq^#'#Yv#=<D+ ^"

This e-mail is private and may be confidential and is for the intended
recipient only.  If misdirected, please notify us by telephone and confirm
that it has been deleted from your system and any copies destroyed.  If you
are not the intended recipient you are strictly prohibited from using,
printing, copying, distributing or disseminating this e-mail or any
information contained in it.  We use reasonable endeavours to virus scan all
e-mails leaving the Company but no warranty is given that this e-mail and any
attachments are virus free.  You should undertake your own virus checking.
The right to monitor e-mail communications through our network is reserved by
us.
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
-- 
perl -e "print qq^bIG VeRN ! ^^qq^#'#Yv#=<D+ ^"
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
Received on Wed Nov 3 09:53:20 2004

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:39 EST