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 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
