Re: [Veritas-vx] Resize problem
$ vxprint -ht ccbappl Disk group: oraappdg V NAME RVG/VSET/CO KSTATE STATELENGTH READPOL PREFPLEX UTYPE PL NAME VOLUME KSTATE STATELENGTH LAYOUTNCOL/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 CACHEDISKOFFS LENGTH [COL/]OFF DEVICE MODE DC NAME PARENTVOLLOGVOL SP NAME SNAPVOL DCO EX NAME ASSOCVC PERMSMODE 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
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 OFFSETLENGTHFLAGS 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 STATELENGTH READPOL PREFPLEX UTYPE PL NAME VOLUME KSTATE STATELENGTH LAYOUTNCOL/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 CACHEDISKOFFS LENGTH [COL/]OFF DEVICE MODE DC NAME PARENTVOLLOGVOL SP NAME SNAPVOL DCO EX NAME ASSOCVC PERMSMODE 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
Re: [Veritas-vx] Resize problem
After the evacuation I'm left with 2 x 200GB disks in the volume. Disk_160 is 79% used Disk_161 is 20% used and the volume still refuses to shrink giving me the same error as before. I've started defrag again in the hopes that it will this time allow me to shrink the volume. Ideas suggestions are most welcome. On 6/28/07, Khurram Tariq [EMAIL PROTECTED] wrote: Gentlemen, I've started the evacuation to Disk_161. Like Robert said Disk_1 is the first disk of the volume. This way I'll be making either Disk_161 the first disk (hopefully) will be able to take Disk_160 or 161 out of the volume leaving one 200GB disk in there. Lets see how it goes. Khurram On 6/28/07, Smedley, Jeremy P [EMAIL PROTECTED] wrote: 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 OFFSETLENGTHFLAGS 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 STATELENGTH READPOL PREFPLEX UTYPE PL NAME VOLUME KSTATE STATELENGTH LAYOUT NCOL/WID MODE SD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE MODE SV NAME PLEX VOLNAME NVOLLAYR LENGTH [COL/]OFF AM/NMMODE SC NAME PLEX CACHEDISKOFFS LENGTH [COL/]OFF DEVICE MODE DC NAME PARENTVOLLOGVOL SP NAME SNAPVOL DCO EX NAME ASSOCVC PERMS MODE STATE SR NAME KSTATE v ccbappl
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 TAOShttp://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 ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
