[SunHELP] Veritas Weirdness
Canada, Brian
sunhelp at sunhelp.org
Thu Jan 18 22:26:07 CST 2001
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C081CF.F1B3CE00
Content-Type: text/plain
I've done this in the past. You must grow the file system and the volume.
At the time I found a doc on Sunsolve that described how to do it.
-----Original Message-----
From: Marc Belanger [mailto:mbelang1 at travelers.com]
Sent: Thursday, January 18, 2001 7:58 PM
To: sunhelp
Subject: [SunHELP] Veritas Weirdness
Hello sunhelpers-
I am looking for a reasonably safe solution to a SEVM 2.5 abnormality.
It seems a striped plex was created, and the volume was created at a
smaller size. The difference is ~6GB. I am looking for a way to correct
the situation without having to rebuild the volume, and restore. I
understand it may be the only way to correctly fix the problem.
I have researched a bit and found I may be able to "grow" the volume by
adding 3 more disks, but I do not know what that will do to the plex.
Further, I'm not so sure I want to *start* slicing up whole 9GB disks.
Here's some */slightly snipped/* output:
*/ NOTE: some of this might be line wrapped at 72 chars, sorry /*
# uname -a
SunOS */snip/* 5.6 Generic_105181-19 sun4u sparc SUNW,Ultra-4
# pkginfo -l SUNWvxvm
PKGINST: SUNWvxvm
NAME: Sun Enterprise Volume Manager
CATEGORY: system
ARCH: sparc
VERSION: 2.5
BASEDIR: /
# vxprint -ht */relavent group anyway/*
v xtra fsgen ENABLED ACTIVE 41886720 SELECT
xtra-04
pl xtra-04 xtra ENABLED ACTIVE 52704000 STRIPE
3/128 RW
sd midg16-01 xtra-04 midg16 0 17568000 0/0
c6t20d1 ENA
sd midg17-01 xtra-04 midg17 0 17568000 1/0
c6t20d2 ENA
sd midg18-01 xtra-04 midg18 0 17568000 2/0
c6t20d3 ENA
# df -k */relavent fs/*
Filesystem kbytes used avail capacity Mounted on
/dev/vx/dsk/midg/xtra 20615385 18064179 1520437 93% /xtra
# cat /etc/vfstab */again with the relavent stuff/*
#device device mount FS fsck mount
mount
#to mount to fsck point type pass at boot
options
#
/dev/vx/dsk/midg/xtra /dev/vx/rdsk/midg/xtra /xtra ufs 3 yes -
Any thoughts or comments are welcomed. I would be most interested in
knowing if there is an easier method of repairing the v/pl size
mismatch, especially if I will not cause an outage to do so. Any ideas
on how/why this happened would be helpful to prevent future occurances.
I am looking to know what will happen to v/pl if I was to try to grow
the volume.
I would not usually try to "fall forward", however, info on this
situation under Solaris 8 and VxVm 3.0.1 (or better) might be worth a
shot.
Thanks in advance,
-Marc
_______________________________________________
SunHELP maillist - SunHELP at sunhelp.org
http://www.sunhelp.org/mailman/listinfo/sunhelp
------_=_NextPart_001_01C081CF.F1B3CE00
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [SunHELP] Veritas Weirdness</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>I've done this in the past. You must grow the =
file system and the volume. At the time I found a doc on Sunsolve =
that described how to do it.</FONT></P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Marc Belanger [<A =
HREF=3D"mailto:mbelang1 at travelers.com">mailto:mbelang1 at travelers.com</A>=
]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 18, 2001 7:58 PM</FONT>
<BR><FONT SIZE=3D2>To: sunhelp</FONT>
<BR><FONT SIZE=3D2>Subject: [SunHELP] Veritas Weirdness</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>Hello sunhelpers-</FONT>
</P>
<P><FONT SIZE=3D2>I am looking for a reasonably safe solution to a SEVM =
2.5 abnormality.</FONT>
<BR><FONT SIZE=3D2>It seems a striped plex was created, and the volume =
was created at a</FONT>
<BR><FONT SIZE=3D2>smaller size. The difference is ~6GB. I am looking =
for a way to correct</FONT>
<BR><FONT SIZE=3D2>the situation without having to rebuild the volume, =
and restore. I</FONT>
<BR><FONT SIZE=3D2>understand it may be the only way to correctly fix =
the problem.</FONT>
</P>
<P><FONT SIZE=3D2>I have researched a bit and found I may be able to =
"grow" the volume by</FONT>
<BR><FONT SIZE=3D2>adding 3 more disks, but I do not know what that =
will do to the plex.</FONT>
<BR><FONT SIZE=3D2>Further, I'm not so sure I want to *start* slicing =
up whole 9GB disks.</FONT>
</P>
<P><FONT SIZE=3D2>Here's some */slightly snipped/* output:</FONT>
<BR><FONT SIZE=3D2>*/ NOTE: some of this might be line wrapped at 72 =
chars, sorry /*</FONT>
</P>
<P><FONT SIZE=3D2># uname =
-a &nbs=
p; &nbs=
p; &nbs=
p; &nbs=
p; </FONT>
<BR><FONT SIZE=3D2>SunOS */snip/* 5.6 Generic_105181-19 sun4u sparc =
SUNW,Ultra-4</FONT>
</P>
<P><FONT SIZE=3D2># pkginfo -l =
SUNWvxvm &nbs=
p; &nbs=
p; </FONT>
<BR><FONT SIZE=3D2> PKGINST: =
SUNWvxvm &nbs=
p; &nbs=
p; </FONT>
<BR><FONT SIZE=3D2> NAME: Sun =
Enterprise Volume =
Manager  =
; </FONT>
<BR><FONT SIZE=3D2> CATEGORY: =
system =
=
=
</FONT>
<BR><FONT SIZE=3D2> ARCH: =
sparc &=
nbsp; &=
nbsp; &=
nbsp; </FONT>
<BR><FONT SIZE=3D2> VERSION: =
2.5 &nb=
sp; &nb=
sp; &nb=
sp; </FONT>
<BR><FONT SIZE=3D2> BASEDIR: /</FONT>
</P>
<P><FONT SIZE=3D2># vxprint -ht =
*/relavent group =
anyway/*</FONT>
<BR><FONT SIZE=3D2>v =
xtra =
fsgen ENABLED =
ACTIVE 41886720 SELECT </FONT>
<BR><FONT SIZE=3D2>xtra-04 </FONT>
<BR><FONT SIZE=3D2>pl xtra-04 =
xtra ENABLED =
ACTIVE 52704000 STRIPE </FONT>
<BR><FONT SIZE=3D2>3/128 RW </FONT>
<BR><FONT SIZE=3D2>sd midg16-01 =
xtra-04 midg16 =
0 17568000 =
0/0 </FONT>
<BR><FONT SIZE=3D2>c6t20d1 ENA</FONT>
<BR><FONT SIZE=3D2>sd midg17-01 =
xtra-04 midg17 =
0 17568000 =
1/0 </FONT>
<BR><FONT SIZE=3D2>c6t20d2 ENA</FONT>
<BR><FONT SIZE=3D2>sd midg18-01 =
xtra-04 midg18 =
0 17568000 =
2/0 </FONT>
<BR><FONT SIZE=3D2>c6t20d3 ENA</FONT>
</P>
<P><FONT SIZE=3D2># df -k =
*/relavent fs/*</FONT>
<BR><FONT =
SIZE=3D2>Filesystem  =
; kbytes used avail =
capacity Mounted on</FONT>
<BR><FONT SIZE=3D2>/dev/vx/dsk/midg/xtra 20615385 18064179 =
1520437 93% /xtra</FONT>
</P>
<P><FONT SIZE=3D2># cat /etc/vfstab =
*/again with the relavent stuff/*</FONT>
<BR><FONT =
SIZE=3D2>#device =
device =
mount =
FS fsck mount =
</FONT>
<BR><FONT SIZE=3D2>mount </FONT>
<BR><FONT SIZE=3D2>#to mount to =
fsck =
point =
type pass at boot</FONT>
<BR><FONT SIZE=3D2>options</FONT>
<BR><FONT SIZE=3D2>#</FONT>
<BR><FONT SIZE=3D2>/dev/vx/dsk/midg/xtra =
/dev/vx/rdsk/midg/xtra /xtra ufs 3 yes =
-</FONT>
</P>
<P><FONT SIZE=3D2>Any thoughts or comments are welcomed. I would be =
most interested in</FONT>
<BR><FONT SIZE=3D2>knowing if there is an easier method of repairing =
the v/pl size</FONT>
<BR><FONT SIZE=3D2>mismatch, especially if I will not cause an outage =
to do so. Any ideas</FONT>
<BR><FONT SIZE=3D2>on how/why this happened would be helpful to prevent =
future occurances.</FONT>
<BR><FONT SIZE=3D2>I am looking to know what will happen to v/pl if I =
was to try to grow</FONT>
<BR><FONT SIZE=3D2>the volume.</FONT>
</P>
<P><FONT SIZE=3D2>I would not usually try to "fall forward", =
however, info on this</FONT>
<BR><FONT SIZE=3D2>situation under Solaris 8 and VxVm 3.0.1 (or better) =
might be worth a</FONT>
<BR><FONT SIZE=3D2>shot.</FONT>
</P>
<P><FONT SIZE=3D2>Thanks in advance,</FONT>
<BR><FONT SIZE=3D2>-Marc</FONT>
</P>
<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>SunHELP maillist - =
SunHELP at sunhelp.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.sunhelp.org/mailman/listinfo/sunhelp" =
TARGET=3D"_blank">http://www.sunhelp.org/mailman/listinfo/sunhelp</A></F=
ONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C081CF.F1B3CE00--
More information about the SunHELP
mailing list