Re: [Evms-cluster] Expanding OCFS2 Partition after LUN has been increased in size
Steve Dobbelstein <[email protected]> Mon, 20 Apr 2009 12:50:12 -0500
| Newsgroups | gmane.linux.evms.devel |
|---|---|
| Message-ID | <OF25D6BC3D.7B2E3194-ON8625759E.005DFAB3-8625759E.0061FAC0@us.ibm.com> |
--===============5319222105028592140== Content-type: multipart/alternative; Boundary="0__=09BBFF0DDFCE7C238f9e8a93df938690918c09BBFF0DDFCE7C23" Content-Disposition: inline --0__=09BBFF0DDFCE7C238f9e8a93df938690918c09BBFF0DDFCE7C23 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable "Jason Ngim" <[email protected]> wrote on 04/13/2009 07:01:37 AM: > "Jason Ngim" <[email protected]> > 04/13/2009 07:01 AM > > To > > <[email protected]> > > cc > > Subject > > [Evms-cluster] Expanding OCFS2 Partition after LUN has been increased= in size > > Dear Gurus > > I have a SAN storage connected to 2 servers using Fibre Optics. > > In it i have created 4 LUNs. for future expansions, the LUNS will be > resized to be bigger, and the OCFS2 partition will also be expanded. > Please tell me how i can achieve it using EVMS. > > example: > > before > /dev/sdb 50GB > /dev/sdb1 50GB (formated using OCFS2) > > after > /dev/sdb 100GB > /dev/sdb1 100GB (size is also expanded not creating another > logical partition) > > i would like to know how i can configure so that the /dev/sdb1 can > be logically expanded to the new size. > Thank you very much!! > > Best Regards > Jason Hi, Jim. Sorry for the late reply. The normal way you would go about expanding a volume is to target/selec= t the volume for expansion rather than the segment. That is, one might initially think of expanding the segment, e.g., /dev/sdb1, first. Howe= ver, since EVMS coordinates the expansion of the segment with the expansion = of the volume, it needs to know the volume that is being expanded. After = all, that is what you want in the end is a bigger volume. After that explanation, here is the bad news. Looking at the source co= de for the OCFS2 plug-in for EVMS, I see that it does not support expandin= g or shrinking a volume. :( I assume that at the time the author wrote the= plug-in that OCFS2 did not support changing the size of a volume. Look= ing on the web I see that the tune.ocfs2 utility is supposed to allow you t= o change the volume size, among other things. For now, you will have to expand the volume by hand -- use fdisk to expand /dev/sdb1 and then use= tune.ocfs2 to expand the OCFS2 volume. You will have to do that outsid= e of EVMS, i.e., don't be running EVMS at the same time you do the expansion= . EVMS will not pick up the changes if you do. EVMS should pick up the changes from your manual expansion the next time it is started. This w= ill work if you did a mkfs of OCFS2 on the "compatibility volume" /dev/evms/sdb1. That is, you did not make an "EVMS volume" from /dev/sdb1 and then put OCFS2 on the EVMS volume. If you made /dev/sdb1 into an EVMS volume then the procedure gets more complicated. The metadata for the EVMS volume will need to be migrated= for the new volume size. (EVMS volume metadata appears at the end of the device.) If you are OK with backing up and restoring your data, the simplest thing to do would be: 1. Backup the data. 2. Delete the OCFS2 volume. 3. Expand /dev/sdb1. 4. Recreate the EVMS volume from /dev sdb1. 5. Put OCFS2 on the volume. 6. Restore your data. If you need to leave your data intact, the following procedure should w= ork (off the top of my head, no testing, no guarantees): 1. Backup the data, just in case. 2. With EVMS not running, use fdisk to expand /dev/sdb1. 3. Temporarily move /lib/evms/<evms-version>/ocfs2* out of the /lib/evms/<evms-version>/ directory so that EVMS will not load the plug-in adn therefore will not be able to recognize /dev/sdb1 as an OCF= S2 volume. 4. Start EVMS. 5. Recreate the EVMS volume from /dev/sdb1. This will put the EVMS vol= ume metadata at the end of /dev/sdb1. 6. Save the changes. You will now have a volume /dev/evms/<name>. 7. Run tune.ocfs2 on /dev/evms/<name> to set the new size. Do not run tune.ocfs2 on /dev/sdb1 or it will most likely blow away the EVMS volum= e metadata at the end of /dev/sdb1. 8. Move the OCFS2 plug-in back into the /lib/evms/<evms-version>/ directory. 9. Now when you start EVMS again you should see the OCFS2 volume with t= he new size. Your other option is to write up a patch for the OCFS2 plug-in to give = it the ability to resize OCFS2 volumes. :) Hope this helps. Steve D.= --0__=09BBFF0DDFCE7C238f9e8a93df938690918c09BBFF0DDFCE7C23 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable <html><body> <p><tt>"Jason Ngim" <[email protected]> wrote on 04= /13/2009 07:01:37 AM:<br> <br> > "Jason Ngim" <[email protected]> </tt><br> <tt>> 04/13/2009 07:01 AM</tt><br> <tt>> <br> > To</tt><br> <tt>> <br> > <[email protected]></tt><br> <tt>> <br> > cc</tt><br> <tt>> <br> > Subject</tt><br> <tt>> <br> > [Evms-cluster] Expanding OCFS2 Partition after LUN has been increa= sed in size</tt><br> <tt>> <br> > Dear Gurus </tt><br> <tt>> <br> > I have a SAN storage connected to 2 servers using Fibre Optics. </= tt><br> <tt>> <br> > In it i have created 4 LUNs. for future expansions, the LUNS will = be<br> > resized to be bigger, and the OCFS2 partition will also be expande= d.<br> > Please tell me how i can achieve it using EVMS. </tt><br> <tt>> <br> > example: </tt><br> <tt>> <br> > before </tt><br> <tt>> /dev/sdb 50GB </tt><br> <tt>> /dev/sdb1 50GB (formated using OCFS2) </tt>= <br> <tt>> <br> > after </tt><br> <tt>> /dev/sdb 100GB </tt><br> <tt>> /dev/sdb1 100GB (size is also expanded not creating ano= ther <br> > logical partition) </tt><br> <tt>> <br> > i would like to know how i can configure so that the /dev/sdb1 can= <br> > be logically expanded to the new size. </tt><br> <tt>> Thank you very much!! </tt><br> <tt>> <br> </tt><br> <tt>> Best Regards </tt><br> <tt>> Jason <br> </tt><br> <tt>Hi, Jim.</tt><br> <br> <tt>Sorry for the late reply.</tt><br> <br> <tt>The normal way you would go about expanding a volume is to target/s= elect the volume for expansion rather than the segment. That is, = one might initially think of expanding the segment, e.g., /dev/sdb1, fi= rst. However, since EVMS coordinates the expansion of the segment= with the expansion of the volume, it needs to know the volume that is = being expanded. After all, that is what you want in the end is a = bigger volume.</tt><br> <br> <tt>After that explanation, here is the bad news. Looking at the = source code for the OCFS2 plug-in for EVMS, I see that it does not supp= ort expanding or shrinking a volume. :( I assume that at th= e time the author wrote the plug-in that OCFS2 did not support changing= the size of a volume. Looking on the web I see that the tune.ocf= s2 utility is supposed to allow you to change the volume size, among ot= her things. For now, you will have to expand the volume by hand -= - use fdisk to expand /dev/sdb1 and then use tune.ocfs2 to expand the O= CFS2 volume. You will have to do that outside of EVMS, i.e., don'= t be running EVMS at the same time you do the expansion. EVMS wil= l not pick up the changes if you do. EVMS should pick up the chan= ges from your manual expansion the next time it is started. This = will work if you did a mkfs of OCFS2 on the "compatibility volume&= quot; /dev/evms/sdb1. That is, you did not make an "EVMS vol= ume" from /dev/sdb1 and then put OCFS2 on the EVMS volume.</tt><br= > <br> <tt>If you made /dev/sdb1 into an EVMS volume then the procedure gets m= ore complicated. The metadata for the EVMS volume will need to be= migrated for the new volume size. (EVMS volume metadata appears = at the end of the device.) If you are OK with backing up and rest= oring your data, the simplest thing to do would be:</tt><br> <tt>1. Backup the data.</tt><br> <tt>2. Delete the OCFS2 volume.</tt><br> <tt>3. Expand /dev/sdb1.</tt><br> <tt>4. Recreate the EVMS volume from /dev sdb1.</tt><br> <tt>5. Put OCFS2 on the volume.</tt><br> <tt>6. Restore your data.</tt><br> <br> <tt>If you need to leave your data intact, the following procedure shou= ld work (off the top of my head, no testing, no guarantees):</tt><br> <tt>1. Backup the data, just in case.</tt><br> <tt>2. With EVMS not running, use fdisk to expand /dev/sdb1.</tt><br> <tt>3. Temporarily move /lib/evms/<evms-version>/ocfs2* out of th= e /lib/evms/<evms-version>/ directory so that EVMS will not load = the plug-in adn therefore will not be able to recognize /dev/sdb1 as an= OCFS2 volume.</tt><br> <tt>4. Start EVMS.</tt><br> <tt>5. Recreate the EVMS volume from /dev/sdb1. This will put the= EVMS volume metadata at the end of /dev/sdb1.</tt><br> <tt>6. Save the changes. You will now have a volume /dev/evms/<= ;name>.</tt><br> <tt>7. Run tune.ocfs2 on /dev/evms/<name> to set the new size. &n= bsp;Do not run tune.ocfs2 on /dev/sdb1 or it will most likely blow away= the EVMS volume metadata at the end of /dev/sdb1.</tt><br> <tt>8. Move the OCFS2 plug-in back into the /lib/evms/<evms-version&= gt;/ directory.</tt><br> <tt>9. Now when you start EVMS again you should see the OCFS2 volume wi= th the new size.</tt><br> <br> <tt>Your other option is to write up a patch for the OCFS2 plug-in to g= ive it the ability to resize OCFS2 volumes. :)</tt><br> <br> <tt>Hope this helps.</tt><br> <br> <tt>Steve D.</tt><br> </body></html>= --0__=09BBFF0DDFCE7C238f9e8a93df938690918c09BBFF0DDFCE7C23-- --===============5319222105028592140== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p --===============5319222105028592140== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Evms-devel mailing list [email protected] To subscribe/unsubscribe, please visit: https://lists.sourceforge.net/lists/listinfo/evms-devel --===============5319222105028592140==--