Re: [Veritas-vx] Resize problem
Could you try upgrading the version of the filesystem to the maximum supported by your volume manager version? Greg. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Khurram Tariq Sent: Friday, 29 June 2007 2:24 PM To: veritas-vx@mailman.eng.auburn.edu Subject: 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 OFFSET LENGTHFLAGS 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
Re: [Veritas-vx] Resize problem
Hi Khurram, Have you tried stopping the application yet then running fsadm? What version of storage foundation are you running? Regards, James. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Khurram Tariq Sent: 29 June 2007 13:01 To: veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] Resize problem Upgraded the dg version, ran defrag again (used fsadm --F vxfs -d -e /filesystem) and still the result of fsadm -D /filesystem is the same as before (see below) vxresize does not work: Directory Fragmentation Report DirsTotal ImmedImmeds Dirs to Blocks to SearchedBlocks Dirs to Add ReduceReduce total 427 30113 1992129 604 Now I'm out of ideas, so gentlemen...please help. On 6/29/07, Robinson, Greg [EMAIL PROTECTED] wrote: Could you try upgrading the version of the filesystem to the maximum supported by your volume manager version? Greg. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Khurram Tariq Sent: Friday, 29 June 2007 2:24 PM To: veritas-vx@mailman.eng.auburn.edu Subject: 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
Re: [Veritas-vx] Resize problem
It's been out experience that fsadm will not reorganize extents of files that are open by an application. Thus, if you have even one extent of a file in the area you wish to reclaim and that file is open, you must shut down your application (or otherwise get it to close the file) to do the fsadm -e command. In this case fuser -c and lsof are your friends. It would be really nice if Veritas included commands to assist with identification of the file and/or if the fsadm told you all this. It doesn't seem like it should be TOO difficult a utility to write... Cheers, - Mike.Myers at nwdc.net -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Khurram Tariq Sent: Friday, June 29, 2007 5:01 AM To: veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] Resize problem Upgraded the dg version, ran defrag again (used fsadm --F vxfs -d -e /filesystem) and still the result of fsadm -D /filesystem is the same as before (see below) vxresize does not work: Directory Fragmentation Report DirsTotal ImmedImmeds Dirs to Blocks to SearchedBlocks Dirs to Add ReduceReduce total 427 30113 1992129 604 Now I'm out of ideas, so gentlemen...please help. On 6/29/07, Robinson, Greg [EMAIL PROTECTED] wrote: Could you try upgrading the version of the filesystem to the maximum supported by your volume manager version? Greg. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Khurram Tariq Sent: Friday, 29 June 2007 2:24 PM To: veritas-vx@mailman.eng.auburn.edu Subject: 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
Re: [Veritas-vx] Resize problem
Hi Mike, This is what I was trying to allude to in my mail earlier. In the older versions of SF it was sometimes not possible to move certain application files due to them being memory mapped (Oracle in particular). However, this has been fixed for the later releases of storage foundation. Rearranging the volume layout will not help - this is purely at a file system level. Regards, James. -Original Message- From: [EMAIL PROTECTED] [mailto:veritas-vx- [EMAIL PROTECTED] On Behalf Of Myers, Mike Sent: 29 June 2007 16:01 To: Khurram Tariq; veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] Resize problem It's been out experience that fsadm will not reorganize extents of files that are open by an application. Thus, if you have even one extent of a file in the area you wish to reclaim and that file is open, you must shut down your application (or otherwise get it to close the file) to do the fsadm -e command. In this case fuser -c and lsof are your friends. It would be really nice if Veritas included commands to assist with identification of the file and/or if the fsadm told you all this. It doesn't seem like it should be TOO difficult a utility to write... Cheers, - Mike.Myers at nwdc.net -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Khurram Tariq Sent: Friday, June 29, 2007 5:01 AM To: veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] Resize problem Upgraded the dg version, ran defrag again (used fsadm --F vxfs -d -e /filesystem) and still the result of fsadm -D /filesystem is the same as before (see below) vxresize does not work: Directory Fragmentation Report DirsTotal ImmedImmeds Dirs to Blocks to SearchedBlocks Dirs to Add ReduceReduce total 427 30113 1992129 604 Now I'm out of ideas, so gentlemen...please help. On 6/29/07, Robinson, Greg [EMAIL PROTECTED] wrote: Could you try upgrading the version of the filesystem to the maximum supported by your volume manager version? Greg. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Khurram Tariq Sent: Friday, 29 June 2007 2:24 PM To: veritas-vx@mailman.eng.auburn.edu Subject: 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
[Veritas-vx] Announcing SF SimpleAdmin (Beta)
Hello All: Just a quick note to let you all know that SF Simple Admin (Beta) is now available for download from www.symantec.com/sfsimpleadmin. You can use the Simple Admin utility for pretty most most of the basic file system commands and also for implementing storage pools if you so desire using one simple command sfop. The file system commands of sfop allow you to create, mount, umount, and remove pooled file systems. File systems clones can also be created using sfop. Please check the User Guide on the website for more details. Of course there are a number of limitations currently with the utility, given that it is Beta launch, so try stuff out on your test/dev boxes and post any feedback directly or at https://forums.symantec.com/syment/board?board.id=94 Regards Gautham ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Resize problem
Hi Mike, No worries, the problem relating to mmap'd files was fixed in 4.0MP2. Regards, James. -Original Message- From: Myers, Mike [mailto:[EMAIL PROTECTED] Sent: 29 June 2007 17:45 To: James Slater; Khurram Tariq; veritas-vx@mailman.eng.auburn.edu Subject: RE: [Veritas-vx] Resize problem Hey, inside information, great stuff :) Do you know at what level this was addressed? It would make a great incentive to upgrade :) Cheers, - Mike.Myers at nwdc.net -Original Message- From: James Slater [mailto:[EMAIL PROTECTED] Sent: Friday, June 29, 2007 9:43 AM To: Myers, Mike; Khurram Tariq; veritas-vx@mailman.eng.auburn.edu Subject: RE: [Veritas-vx] Resize problem Hi Mike, This is what I was trying to allude to in my mail earlier. In the older versions of SF it was sometimes not possible to move certain application files due to them being memory mapped (Oracle in particular). However, this has been fixed for the later releases of storage foundation. Rearranging the volume layout will not help - this is purely at a file system level. Regards, James. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
