It could be that the file system is too busy for the fsadm section of the
command (which has the problem) to complete its move of certain blocks. This is
more likely due to the fact that the majority of the data in the volume is on
the first subdisk.
You could try the following approach if it is feasible in your environment.
Take the application offline which is accessing data on this volume (user
impact can not be avoided)
Repeat the defrag whilst the volume is quiesced.
Repeat the vxresize request whilst the volume is quiesced..
________________________________
From: [EMAIL PROTECTED] on behalf of Khurram Tariq
Sent: Thu 6/28/2007 2:44 PM
To: veritas-vx@mailman.eng.auburn.edu
Subject: Re: [Veritas-vx] Resize problem
I had thought of it but the size of the volume is slightly larger than the
capacity of Disk_161 so mirroring wont be possible. Size of the volume visible
in VEA is 200.970GB & Disk_161 is 199.980GB.
On 6/28/07, Weber, Klaus <[EMAIL PROTECTED]> wrote:
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] <mailto:[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
