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
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] <mailto:[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
<mailto: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 
                
                




_______________________________________________
Veritas-vx maillist  -  Veritas-vx@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx

Reply via email to