[SunHELP] Veritas Weirdness
Lund, Dennis
sunhelp at sunhelp.org
Tue Jan 23 07:18:09 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_01C0853E.EE2CD61A
Content-Type: text/plain
I have not seen any responses to your problem, so I thought I would send
this
in case you were still looking for a solution.
This is an interesting command, about which almost nothing is written.
syntax: vxresize (file name) (size in gb=g or m=mb )
used to expand a file system under volume manager, it also resizes
the volume to fit the increased file system (if you should happen to
resize a volume when you should have resized the filesystem).
In the event a volume is expanded first, the filesystem will remain at
it's original size. If this is the case use vxresize to expand the file
system to slightly larger than the volume size( even 1mb). The resized
file system will utilize all of the increased volume size.
If the file system is type ufs then the syntax to expand is:
vxresize -F ufs (file name) ( size in g or m )
EXAMPLE: vxresize -F ufs u05 22g <<< expand ufs file u05 to 22g
For a vxfs file the syntax to expand is:
EXAMPLE: vxresize -F vxvs u05 22g <<< expand ufs file u05 to 22g
Hope this helps, or helps in the future should you need it.
Dennis L. Lund
-----Original Message-----
From: Marc Belanger [mailto:mbelang1 at travelers.com]
Sent: Thursday, January 18, 2001 8: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
- - - - - - - Appended by Scientific-Atlanta, Inc. - - - - - - -
This e-mail and any attachments may contain information which is
confidential, proprietary, privileged or otherwise protected by law. The
information is solely intended for the named addressee (or a person
responsible for delivering it to the addressee). If you are not the intended
recipient of this message, you are not authorized to read, print, retain,
copy or disseminate this message or any part of it. If you have received
this e-mail in error, please notify the sender immediately by return e-mail
and delete it from your computer.
------_=_NextPart_001_01C0853E.EE2CD61A
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.2650.12">
<TITLE>RE: [SunHELP] Veritas Weirdness</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>I have not seen any responses to your problem, so I =
thought I would send this</FONT>
<BR><FONT SIZE=3D2>in case you were still looking for a =
solution.</FONT>
</P>
<P><FONT SIZE=3D2>This is an interesting command, about which almost =
nothing is written.</FONT>
</P>
<P><FONT SIZE=3D2>syntax: vxresize (file name) (size in gb=3Dg or =
m=3Dmb )</FONT>
</P>
<P><FONT SIZE=3D2>used to expand a file system under volume manager, it =
also resizes</FONT>
<BR><FONT SIZE=3D2>the volume to fit the increased file system (if you =
should happen to</FONT>
<BR><FONT SIZE=3D2>resize a volume when you should have resized the =
filesystem).</FONT>
</P>
<P><FONT SIZE=3D2>In the event a volume is expanded first, the =
filesystem will remain at</FONT>
<BR><FONT SIZE=3D2>it's original size. If this is the case use =
vxresize to expand the file</FONT>
<BR><FONT SIZE=3D2>system to slightly larger than the volume size( even =
1mb). The resized</FONT>
<BR><FONT SIZE=3D2>file system will utilize all of the increased volume =
size.</FONT>
</P>
<P><FONT SIZE=3D2>If the file system is type ufs then the syntax to =
expand is:</FONT>
</P>
<P><FONT SIZE=3D2> vxresize -F ufs (file name) ( size in g =
or m )</FONT>
</P>
<P><FONT SIZE=3D2>EXAMPLE: vxresize -F ufs u05 22g <<< =
expand ufs file u05 to 22g</FONT>
</P>
<P><FONT SIZE=3D2>For a vxfs file the syntax to expand is:</FONT>
</P>
<P><FONT SIZE=3D2>EXAMPLE: vxresize -F vxvs u05 22g <<< =
expand ufs file u05 to 22g</FONT>
</P>
<P><FONT SIZE=3D2>Hope this helps, or helps in the future should you =
need it.</FONT>
</P>
<P><FONT SIZE=3D2>Dennis L. Lund</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 8: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>
<BR>
<P> - - - - - - - Appended by =
Scientific-Atlanta, Inc. - - - - - - - =20
<BR>This e-mail and any attachments may contain information which is =
confidential, proprietary, privileged or otherwise protected by law. =
The information is solely intended for the named addressee (or a person =
responsible for delivering it to the addressee). If you are not the =
intended recipient of this message, you are not authorized to read, =
print, retain, copy or disseminate this message or any part of it. If =
you have received this e-mail in error, please notify the sender =
immediately by return e-mail and delete it from your computer. </P>
<BR>
</BODY>
</HTML>
------_=_NextPart_001_01C0853E.EE2CD61A--
More information about the SunHELP
mailing list