possible solution could be
Create a mirror using disk_161
remove both disk_1 and disk_160 from mirror
shrink volume to desired size
attach mirror consisting of disk_160
remove disk_161 from mirror
all this should be possible whilst the volume is started
Klaus
________________________________
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von
Khurram Tariq
Gesendet: Donnerstag, 28. Juni 2007 15:23
An:
Betreff: Re: [Veritas-vx] Resize problem
Agreed but I can also evacuate Disk_1 if I had enough free space on
Disk_160. This is why I'm decreasing the volume by 2GB so I can have
sufficient unused space on Disk_160 & a subdisk can be created there to
accomodate Disk_1's evacuation. The output of vxdg free is:
$ vxdg -g oraappdg free
DISK DEVICE TAG OFFSET LENGTH FLAGS
oraappdg01 Disk_0 Disk_0 85946368 1792 -
oraappdg02 Disk_1 Disk_1 85946368 1792 -
oraappdg03 Disk_11 Disk_11 106917888 1792 -
oraappdg04 Disk_12 Disk_12 44003328 1792 -
oraappdg05 Disk_160 Disk_160 335511984 83883344 -
oraappdg06 Disk_161 Disk_161 0 419395328 -
Disk_1 has 896KB free (99% used), this is why its showing up in the
output above.
What do you guys advise? I dont want to use Disk_161 and then have a
200GB disk stuck in that volume.
Regards,
Khurram
On 6/28/07, robertinoau <[EMAIL PROTECTED]> wrote:
So from this output:
v ccbappl - ENABLED ACTIVE 421458352 SELECT
- fsgen
pl ccbappl-01 ccbappl ENABLED ACTIVE 421458352 CONCAT
- RW
sd oraappdg02-01 ccbappl-01 oraappdg02 0 85946368 0
Disk_1 ENA
sd oraappdg05-01 ccbappl-01 oraappdg05 0 335511984
85946368 Disk_160 ENA
Disk_1 starts at offset 0 and the size is 85946368, so this is
your 40G drive.
So the problem here is this is a contact so you can't take out
the 40G by shrinking the volume. If you shrink the volume, you will
free up space on Disk_160 first (it shrinks from the bottom up).
Understand what I am trying to say ?
If you do a vxdg free, I almost certain you won't see Disk_1 in
the list.
----- Original Message ----
From: Khurram Tariq <[EMAIL PROTECTED]>
To: veritas-vx@mailman.eng.auburn.edu
Sent: Thursday, 28 June, 2007 5:17:33 PM
Subject: Re: [Veritas-vx] Resize problem
$ vxprint -ht ccbappl
Disk group: oraappdg
V NAME RVG/VSET/CO KSTATE STATE LENGTH READPOL
PREFPLEX UTYPE
PL NAME VOLUME KSTATE STATE LENGTH LAYOUT
NCOL/WID MODE
SD NAME PLEX DISK DISKOFFS LENGTH
[COL/]OFF DEVICE MODE
SV NAME PLEX VOLNAME NVOLLAYR LENGTH
[COL/]OFF AM/NM MODE
SC NAME PLEX CACHE DISKOFFS LENGTH
[COL/]OFF DEVICE MODE
DC NAME PARENTVOL LOGVOL
SP NAME SNAPVOL DCO
EX NAME ASSOC VC PERMS
MODE STATE
SR NAME KSTATE
v ccbappl - ENABLED ACTIVE 421458352 SELECT
- fsgen
pl ccbappl-01 ccbappl ENABLED ACTIVE 421458352 CONCAT
- RW
sd oraappdg02-01 ccbappl-01 oraappdg02 0 85946368 0
Disk_1 ENA
sd oraappdg05-01 ccbappl-01 oraappdg05 0 335511984
85946368 Disk_160 ENA
On 6/28/07, Smedley, Jeremy P <[EMAIL PROTECTED]> wrote:
Can you provide a vxprint -th of the volume please.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Robinson, Greg
Sent: 28 June 2007 06:49
To: veritas-vx@mailman.eng.auburn.edu
Subject: Re: [Veritas-vx] Resize problem
Hi all,
could you perhaps evacuate the data from the
40GB LUN to some temporary space, then remove the 40GB LUN, then shrink
the volume and then remove the temporary space?
Another option maybe is to mirror to other LUNS
and then try and shrink and remove...
Are there any disk errors showing up in
messages?
Greg.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Khurram
Tariq
Sent: Thursday, 28 June 2007 2:13 PM
To: veritas-vx@mailman.eng.auburn.edu
Subject: Re: [Veritas-vx] Resize problem
Nopes. It has always been VxFS. Defrag didnt
help either and decreasing the size in chunks as small as 1GB isnt
working either. Initially this FS was 440GB & had 2 x 200GB LUNs & 1 x
40GB. Resize worked day before yesterday & I was able to free up one
200GB LUN out of the volume but its not working now.
Regards,
Khurram
On 6/27/07, Darren Dunham <[EMAIL PROTECTED]>
wrote:
> I have a 201GB volume which is
composed of two LUNs (40GB & 200GB). Now I
> want to free up the 40GB LUN from that
volume by shrinking the volume to
> 198GB but vxresize is giving me the
following error:
>
> UX:vxfs fsadm: ERROR: V-3-20343:
cannot shrink /dev/vx/rdsk/some-dg/volumea
> - blocks are currently in use.
> VxVM vxresize ERROR V-5-1-7514 Problem
running fsadm command for volume
> volumea, in diskgroup some-dg
This filesystem wasn't converted from
UFS in the past, was it?
--
Darren Dunham
[EMAIL PROTECTED]
Senior Technical Consultant TAOS
http://www.taos.com/
Got some Dr Pepper?
San Francisco, CA bay area
< This line left intentionally
blank to confuse you. >
_______________________________________________
Veritas-vx maillist -
Veritas-vx@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
IMPORTANT: This email remains the property of
the Australian Defence Organisation and is subject to the jurisdiction
of section 70 of the CRIMES ACT 1914. If you have received this email in
error, you are requested to contact the sender and delete the email.
_______________________________________________
Veritas-vx maillist -
Veritas-vx@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
_______________________________________________
Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu
<mailto:Veritas-vx@mailman.eng.auburn.edu>
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
________________________________
Yahoo!7 Mail has just got even bigger and better with unlimited
storage on all webmail accounts. Find out more
<http://au.docs.yahoo.com/mail/unlimitedstorage.html> .
_______________________________________________
Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
