ext2resize-devel Mailing List for GNU ext2resize (Page 6)
Status: Inactive
Brought to you by:
adilger
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
(8) |
Apr
(1) |
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
(5) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
|
Feb
|
Mar
(6) |
Apr
(2) |
May
|
Jun
|
Jul
(3) |
Aug
(2) |
Sep
|
Oct
(5) |
Nov
(5) |
Dec
|
2002 |
Jan
(14) |
Feb
(8) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(3) |
Sep
(12) |
Oct
(12) |
Nov
(10) |
Dec
(10) |
2003 |
Jan
|
Feb
(7) |
Mar
(1) |
Apr
(6) |
May
(3) |
Jun
|
Jul
(3) |
Aug
(3) |
Sep
(2) |
Oct
(4) |
Nov
(1) |
Dec
(2) |
2004 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2005 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(14) |
Sep
(4) |
Oct
|
Nov
|
Dec
(5) |
2006 |
Jan
|
Feb
(4) |
Mar
(19) |
Apr
(1) |
May
(9) |
Jun
(34) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Andreas D. <ad...@cl...> - 2003-02-20 17:40:18
|
On Feb 20, 2003 11:42 +0000, Louis Becker wrote: > root@little: /root/install/ext2resize > make > Making all in doc > make[1]: Entering directory `/root/install/ext2resize/doc' > cd .. && automake --gnu doc/Makefile > configure.in:4: your implementation of AM_INIT_AUTOMAKE comes from an > configure.in:4: old Automake version. You should recreate aclocal.m4 > configure.in:4: with aclocal and run automake again. > make[1]: *** [Makefile.in] Error 1 > make[1]: Leaving directory `/root/install/ext2resize/doc' > make: *** [all-recursive] Error 1 We probably should just remove the aclocal.m4 file and have it run aclocal instead. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ |
From: Louis B. <lou...@da...> - 2003-02-20 11:48:18
|
HI, is it normal that the size of the kernel built whith make rpm from= =20 the standard RH80 + patch is 12GB big ? Louis BECKER. Syst=E8mes & R=E9seaux ____________________________________________________ commerce.fr ( Groupe DANEEL ) 42, avenue de la R=E9publique - BP 636 - 68009 COLMAR Cedex T=E9l.: +33 (0)3 89 217 330 - Fax : +33 (0)3 89 217 331 mailto:lou...@da... - http://www.daneel.com Freelancing : http://www.daneel.ch/en/detailprofil.htm?code=3D12=20 or http://www.daneel.ch/de/detailprofil.htm?code=3D11 |
From: Louis B. <lou...@da...> - 2003-02-20 11:42:30
|
HI, i checked out the sources of ext2resize from cvs did : ./configure make but gets always : oot@little: /root/install/ext2resize > ./configure checking for a BSD compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking whether make sets ${MAKE}... yes checking for working aclocal... found checking for working autoconf... found checking for working automake... found checking for working autoheader... found checking for working makeinfo... found checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for executable suffix... checking for object suffix... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking how to run the C preprocessor... gcc -E checking whether gcc needs -traditional... no checking for ranlib... ranlib checking for getopt.h... yes checking for signal.h... yes checking for sys/types.h... yes checking for unistd.h... yes checking for linux/unistd.h... yes checking for ANSI C header files... yes checking for sys/types.h... (cached) yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... (cached) yes checking for __s8... no checking for __u8... no checking for __s16... no checking for __u16... no checking for __s32... no checking for __u32... no checking for loff_t... yes checking for open64... yes checking for lseek64... yes checking for llseek... yes configure: creating ./config.status config.status: creating Makefile config.status: creating doc/Makefile config.status: creating src/Makefile config.status: creating src/config.h root@little: /root/install/ext2resize > make Making all in doc make[1]: Entering directory `/root/install/ext2resize/doc' cd .. && automake --gnu doc/Makefile configure.in:4: your implementation of AM_INIT_AUTOMAKE comes from an configure.in:4: old Automake version. You should recreate aclocal.m4 configure.in:4: with aclocal and run automake again. make[1]: *** [Makefile.in] Error 1 make[1]: Leaving directory `/root/install/ext2resize/doc' make: *** [all-recursive] Error 1 so i removed aclocal.m4 did : aclocal ./configure and got : root@little: /root/install/ext2resize > ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes /root/install/ext2resize/missing: Unknown `--run' option Try `/root/install/ext2resize/missing --help' for more information configure: WARNING: `missing' script is too old or missing checking for gawk... gawk checking whether make sets ${MAKE}... yes checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking how to run the C preprocessor... gcc -E checking whether gcc needs -traditional... no checking for ranlib... ranlib checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking getopt.h usability... yes checking getopt.h presence... yes checking for getopt.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking for sys/types.h... (cached) yes checking for unistd.h... (cached) yes checking linux/unistd.h usability... yes checking linux/unistd.h presence... yes checking for linux/unistd.h... yes checking for __s8... no checking for __u8... no checking for __s16... no checking for __u16... no checking for __s32... no checking for __u32... no checking for loff_t... yes checking for open64... yes checking for lseek64... yes checking for llseek... yes configure: creating ./config.status config.status: creating Makefile config.status: creating doc/Makefile config.status: creating src/Makefile config.status: creating src/config.h config.status: executing depfiles commands What environment do i need to be abble to compile the new= ext2resize ? Louis BECKER. Syst=E8mes & R=E9seaux ____________________________________________________ commerce.fr ( Groupe DANEEL ) 42, avenue de la R=E9publique - BP 636 - 68009 COLMAR Cedex T=E9l.: +33 (0)3 89 217 330 - Fax : +33 (0)3 89 217 331 mailto:lou...@da... - http://www.daneel.com Freelancing : http://www.daneel.ch/en/detailprofil.htm?code=3D12=20 or http://www.daneel.ch/de/detailprofil.htm?code=3D11 |
From: Andreas D. <ad...@cl...> - 2003-02-19 19:48:10
|
On Feb 19, 2003 17:14 +0000, Louis Becker wrote: > After reboot i am trying to growth a filesystem with : > > > e2fsadm /dev/datavg/datawwwvol -L 110M > e2fsadm -- rounding size up to physical extent boundary > lvextend -- extending logical volume > "/dev/datavg/datawwwvol" to 112 MB > lvextend -- doing automatic backup of volume group "datavg" > lvextend -- logical volume "/dev/datavg/datawwwvol" > successfully extended > > ext2online: ext2_open: fs has unsupported feature(s) > enabled:ext2online: can't open /dev/datavg/datawwwvol > > i can not understand what exactly happens is the Kernel patch not > apply ? What version of ext2resize do you have? What does the Filesystem features line of "dumpe2fs -h /dev/datavf/datawwwvol" show? If it is an ext3 filesystem, you need to use the CVS version of ext2resize. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ |
From: Andreas D. <ad...@cl...> - 2003-02-19 19:46:31
|
On Feb 19, 2003 16:53 +0000, Louis Becker wrote: > I am a newbie in this mailinglist i subscribed to it for the > following reason : > How can i install ext2resize after a fresh system > installation ? > > I installed a new box with RedHat 8.0, ( 2.4.18-14 ) > Software Raid for 4 disks > LVM ontop of the raid > and i want to be abble to resize the fs on in a Volumegroup ( like > AIX ) > i tried to find out how to patch the Kernel : > cd /usr/src > ln -sf linux-2.4.18-14 linux > cat > /packages/DCE_V80/all/ext3patch/online-ext2-2[1].4.18.diff | patch -p0 > ln -sf linux-2.4.18-14 linux-2.4.18 > cat > /packages/DCE_V80/all/ext3patch/online-ext3-2[1].4.18.diff | patch -p0 > cd linux-2.4.18 > make mrproper > make menuconfig > [ selection in the Tree of Filesystems, then select ext2 > resize and ext3 resize then save the new config ] > make dep > make > make bzImage > make modules > make modules_install > make install > [ edit /etc/grub.conf and change the default kernel boot > option to 0 so the new inserted kernel will be the default ] > reboot > but i suppose that there will be a shorter way to just patch the > kernel for ext(2)(3)online ? > > Thanks for any help and/or confirmation This seems fine to me, although for RH systems I'd suggest using "make rpm" to build the kernel and not "make dep bzImage install modules modules_install". Then, install the RPM from /usr/src/redhat/RPMS/i386 Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ |
From: Louis B. <lou...@da...> - 2003-02-19 17:14:43
|
Hi, After reboot i am trying to growth a filesystem with : e2fsadm /dev/datavg/datawwwvol -L 110M e2fsadm -- rounding size up to physical extent boundary lvextend -- extending logical volume=20 "/dev/datavg/datawwwvol" to 112 MB lvextend -- doing automatic backup of volume group "datavg" lvextend -- logical volume "/dev/datavg/datawwwvol"=20 successfully extended ext2online: ext2_open: fs has unsupported feature(s)=20 enabled:ext2online: can't open /dev/datavg/datawwwvol i can not understand what exactly happens is the Kernel patch not= =20 apply ? Louis BECKER. Syst=E8mes & R=E9seaux ____________________________________________________ commerce.fr ( Groupe DANEEL ) 42, avenue de la R=E9publique - BP 636 - 68009 COLMAR Cedex T=E9l.: +33 (0)3 89 217 330 - Fax : +33 (0)3 89 217 331 mailto:lou...@da... - http://www.daneel.com Freelancing : http://www.daneel.ch/en/detailprofil.htm?code=3D12=20 or http://www.daneel.ch/de/detailprofil.htm?code=3D11 |
From: Louis B. <lou...@da...> - 2003-02-19 16:53:50
|
HI, I am a newbie in this mailinglist i subscribed to it for the=20 following reason : How can i install ext2resize after a fresh system=20 installation ? I installed a new box with RedHat 8.0, ( 2.4.18-14 ) Software Raid for 4 disks LVM ontop of the raid and i want to be abble to resize the fs on in a Volumegroup ( like= =20 AIX ) i tried to find out how to patch the Kernel : cd /usr/src ln -sf linux-2.4.18-14 linux cat=20 /packages/DCE_V80/all/ext3patch/online-ext2-2[1].4.18.diff | patch -p0 ln -sf linux-2.4.18-14 linux-2.4.18 cat=20 /packages/DCE_V80/all/ext3patch/online-ext3-2[1].4.18.diff | patch -p0 cd linux-2.4.18 make mrproper make menuconfig [ selection in the Tree of Filesystems, then select ext2=20 resize and ext3 resize then save the new config ] make dep make make bzImage make modules make modules_install make install [ edit /etc/grub.conf and change the default kernel boot=20 option to 0 so the new inserted kernel will be the default ] reboot but i suppose that there will be a shorter way to just patch the=20 kernel for ext(2)(3)online ? Thanks for any help and/or confirmation Louis BECKER. Syst=E8mes & R=E9seaux ____________________________________________________ commerce.fr ( Groupe DANEEL ) 42, avenue de la R=E9publique - BP 636 - 68009 COLMAR Cedex T=E9l.: +33 (0)3 89 217 330 - Fax : +33 (0)3 89 217 331 mailto:lou...@da... - http://www.daneel.com Freelancing : http://www.daneel.ch/en/detailprofil.htm?code=3D12=20 or http://www.daneel.ch/de/detailprofil.htm?code=3D11 |
From: Robert W. <rj...@du...> - 2002-12-18 17:59:52
|
> Looks like a signed/unsigned problem, perhaps? 2TB is certainly a > suspicious-sounding number... I found the bug, but of course it wasn't this. There was a buffer leak in ext2_make_group. I'll be checking a fix into CVS as soon as SourceForge's CVS starts working again. Is anyone else having problems doing CVS work at the moment too? Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
From: Robert W. <rj...@du...> - 2002-12-18 00:05:27
|
Hi all, There appears to be some problem with online resizing an ext3 filesystem by more than 2TB at a go. When 2TBs have been added to the filesystem, it prints out this error message: ext2resize: couldn't flush! I don't have any more details - that's all I got in the bug report. Looks like a signed/unsigned problem, perhaps? 2TB is certainly a suspicious-sounding number... Anyway, restarting the resize after the failure allows it to continue correctly, so it's not the end of the world. I'm going to try to get this fixed over the next few days, though - I'm running an online resize right now from 10GB up to 3.2TB with verbose and debug modes turned on. Watch this space. Regards, Robert. |
From: Robert W. <rj...@du...> - 2002-12-11 00:14:31
|
Hi, ext2online in the CVS head now accepts a -C <fd> option. If specified, it outputs completion feedback to file descriptor <fd>. Use it like this: # ext2online -C 1 /whee to get output on stdout. Something to look at while large resizes are happening. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
From: 'Andreas Dilger' <ad...@cl...> - 2002-12-10 02:15:32
|
On Dec 09, 2002 17:58 -0800, Poul Petersen wrote: > > Sadly, ext2prepare does not work with the new ext3 code. I am such a > > procrastinator, shoot me. We do have a patch for mke2fs which will > > prepare a new filesystem for a 1000x growth from the initial size, but > > we _really_ need ext2prepare for the new ext3 format to > > handle existing filesystems also. > > I'm confused about this - I though I had seen a post from Robert > Walsh stating that he had successfully resized ext3 file systems from 1GB to > 1TB - wait, was that for offline resizing? If ext2prepare doesn't work, how > does one avoid the 16GB boundary limit (with 4k blocks)? I have the mke2fs > patch from the ext2resize sourceforge page, but I don't see anything about > avoiding this limit and the resize does fail if I try to increase beyond the > 16GB boundary. You need to run "mke2fs -O resize_inode" in order to activate this functionality. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ |
From: Poul P. <pe...@ro...> - 2002-12-10 01:59:27
|
> Sadly, ext2prepare does not work with the new ext3 code. I am such a > procrastinator, shoot me. We do have a patch for mke2fs which will > prepare a new filesystem for a 1000x growth from the initial size, but > we _really_ need ext2prepare for the new ext3 format to > handle existing > filesystems also. I'm confused about this - I though I had seen a post from Robert Walsh stating that he had successfully resized ext3 file systems from 1GB to 1TB - wait, was that for offline resizing? If ext2prepare doesn't work, how does one avoid the 16GB boundary limit (with 4k blocks)? I have the mke2fs patch from the ext2resize sourceforge page, but I don't see anything about avoiding this limit and the resize does fail if I try to increase beyond the 16GB boundary. Thanks again, -poul |
From: Brian J. M. <593...@in...> - 2002-12-09 22:11:33
|
On Mon, Dec 09, 2002 at 01:20:15PM -0700, Andreas Dilger wrote: >=20 > Sadly, ext2prepare does not work with the new ext3 code. And now that you say that, I am reminded that I did know this. Memory is getting bad in my old age. :-) b. --=20 Brian J. Murrell |
From: Poul P. <pe...@ro...> - 2002-12-09 20:54:55
|
> Did you "prepare" the filesystem after creating it initially? By > default, there is only enough space in the block bitmaps to support > 16GB worth of blocks (assuming 4k blocks). "Preparing" (man > ext2prepare) allocates more block bitmaps to support larger number of > blocks in the filesystem. Oh right! I forgot about ext2prepare - the 16GB stop makes sense now. The first tests I ran on my home system where I only have a 16GB drive anyways, so I left that out of my notes. -poul |
From: Andreas D. <ad...@cl...> - 2002-12-09 20:20:42
|
On Dec 09, 2002 15:01 -0500, Brian J. Murrell wrote: > On Mon, Dec 09, 2002 at 11:33:51AM -0800, Poul Petersen wrote: > > However, the ext3 file-system stopped extending at about 16GB. You probably should have gotten messages to the console or syslog saying that the filesystem couldn't be expanded further... > Did you "prepare" the filesystem after creating it initially? By > default, there is only enough space in the block bitmaps to support > 16GB worth of blocks (assuming 4k blocks). "Preparing" (man > ext2prepare) allocates more block bitmaps to support larger number of > blocks in the filesystem. Sadly, ext2prepare does not work with the new ext3 code. I am such a procrastinator, shoot me. We do have a patch for mke2fs which will prepare a new filesystem for a 1000x growth from the initial size, but we _really_ need ext2prepare for the new ext3 format to handle existing filesystems also. > > [root@nfs1node1 ext2resize-1.1.18_pre]# ext2resize /dev/vg00/sa_test > > ext2resize v1.1.18 - 2001/03/18 for EXT2FS 0.5b > > BUG! block 32782 shouldn't have been marked! > > Now this, this does not look good. I will have to leave this up to a > real expert (I am just playing one in this episode :-) to answer. Not sure about the source of this, but in general such an error will not cause any filesystem corruption, just prevent you from resizing... Could you run "ext2resize -v -d /dev/vg00/sa_test" and send that + "dumpe2fs -h /dev/vg00/sa_test" to me and Robert Walsh <rj...@us...>? Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ |
From: Brian J. M. <4d9...@in...> - 2002-12-09 20:01:24
|
On Mon, Dec 09, 2002 at 11:33:51AM -0800, Poul Petersen wrote: > > However, the ext3 file-system stopped extending at about 16GB. Did you "prepare" the filesystem after creating it initially? By default, there is only enough space in the block bitmaps to support 16GB worth of blocks (assuming 4k blocks). "Preparing" (man ext2prepare) allocates more block bitmaps to support larger number of blocks in the filesystem. > [root@nfs1node1 ext2resize-1.1.18_pre]# ext2resize /dev/vg00/sa_test > ext2resize v1.1.18 - 2001/03/18 for EXT2FS 0.5b > BUG! block 32782 shouldn't have been marked! Now this, this does not look good. I will have to leave this up to a real expert (I am just playing one in this episode :-) to answer. b. --=20 Brian J. Murrell |
From: Poul P. <pe...@ro...> - 2002-12-09 19:38:40
|
I've been running some tests with online resizing of ext3 volumes. First, let me explain the setup: kernel 2.4.19 lvm-1.0.6 ext3-2.4 + online_resize patch ext2resize from CVS (~12/6) RedHat 7.2 running on dual P-II 400 Qlogic 2200 San -> Zzyzx RocketStor 2000 Through the san I assigned one 205GB raid set to this machine and setup a 1GB LV and ext3 filesystem. I then mounted this filesystem, exported it via NFS, and set about 16 hosts to read and write to the volume (we have a home-brewed nfsload script that tries to mimic the build activity we see on out production NFS server). I then set e2fsadm in a loop adding 512MB to the volume every 5 minutes. The server never crashed or experienced any difficulties and the LV was eventually extended to the full size of the VG. However, the ext3 file-system stopped extending at about 16GB. I stopped the activity, unmounted the disk and ran e2fsck which reported no errors. I then tried to do a ext2resize with the disk offline and got the following: [root@nfs1node1 ext2resize-1.1.18_pre]# ext2resize /dev/vg00/sa_test ext2resize v1.1.18 - 2001/03/18 for EXT2FS 0.5b BUG! block 32782 shouldn't have been marked! Please send a filesystem dump and ext2resize version to: <ext...@li...> Naturally, I'm not about to send a 16GB dump to the mailing list :) I have not done anything else to this filesystem and the hardware is all test hardware, so I can do pretty much anything that would be helpful. Thanks for any suggestions... -poul |
From: Andres S. <dil...@vo...> - 2002-11-27 23:28:29
|
Just wanted to give a "worked for me" report for resizing ext3 partitions: [root@neuromancer /root]# ext2online -v /dev/site/lvol1 ext2online v1.1.18 - 2001/03/18 for EXT2FS 0.5b new filesystem size 7503872 using 0 reserved group descriptor blocks creating group 228 with 32768 blocks (rsvd = 0, newgd = 2) cache direct hits: 93, indirect hits: 0, misses: 2 [root@neuromancer /root]# df Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda5 1035660 536580 446472 55% / /dev/sda7 2071384 1527320 438840 78% /usr /dev/sda6 2071384 824832 1141328 42% /var none 258228 0 258228 0% /dev/shm /dev/site/lvol1 29545448 11375028 16672252 41% /home That was grown from 18 gigs, using the tools and 2.4.19 patch from HEAD. Updated docs/release would be appreciated, as the ext2online stuff confused me initially (ext2online complains about features that it doesn't support, as someone else report to the mailing list). -- It's not denial. I'm just selective about the reality I accept. -- Bill Watterson |
From: Poul P. <pe...@ro...> - 2002-11-13 00:50:24
|
> Our bad - you need to use the ext2resize code from CVS for the ext3 > resizing to work. Maybe we need to make a pre-release? Excellent! I'm using the CVS version now and it works! I'll be running some test resizes during various levels of NFS client activity. I'll let you know if I run into any problems. Thanks, -poul |
From: Robert W. <rj...@du...> - 2002-11-09 01:23:42
|
> Our bad - you need to use the ext2resize code from CVS for the ext3 > resizing to work. Maybe we need to make a pre-release? I've checked in a patch to the CVS tree. You can do ahead with the release, now, if you like. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
From: Robert W. <rj...@du...> - 2002-11-08 19:36:20
|
> Our bad - you need to use the ext2resize code from CVS for the ext3 > resizing to work. Maybe we need to make a pre-release? Sounds like a plan. I fixed a core dump in ext2online last night. I'll submit the patch later today. Maybe you should wait for that. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
From: Andreas D. <ad...@cl...> - 2002-11-08 19:32:18
|
On Nov 08, 2002 11:10 -0800, Poul Petersen wrote: > I have a feeling I'm going to feel stupid when I get an answer, but > here goes: > > I'm working with 2.4.18-14 (RH) and I have applied the ext3-online > patch for 2.4.18, enabled in kernel, recompiled etc. I have also applied the > e2fsprogs 1.28 patch for resizing to, well e2fsprogs 1.28. I'm also running > ext2resize-1.1.17 which I pulled down from > http://ext2resize.sourceforge.net/ext2resize-1.1.17.tar.gz Now, when I try > to resize an online ext3 filesystem with ext2online I get the error: > > ext2_open: fs has unsupported feature(s) enabled > > This message is generated at line 887 in ext2.c and the test that is > failing seems to be checking, among other things, whether or not the target > fs is ext3. Have I got the wrong tools? The patches in the test/ subdir seem > to be earlier versions of ext3online kernel patches. Offline resizing of > ext3 is working fine. Our bad - you need to use the ext2resize code from CVS for the ext3 resizing to work. Maybe we need to make a pre-release? Cheers, Andreas -- Andreas Dilger http://www-mddsp.enel.ucalgary.ca/People/adilger/ http://sourceforge.net/projects/ext2resize/ |
From: Poul P. <pe...@ro...> - 2002-11-08 19:13:35
|
I have a feeling I'm going to feel stupid when I get an answer, but here goes: I'm working with 2.4.18-14 (RH) and I have applied the ext3-online patch for 2.4.18, enabled in kernel, recompiled etc. I have also applied the e2fsprogs 1.28 patch for resizing to, well e2fsprogs 1.28. I'm also running ext2resize-1.1.17 which I pulled down from http://ext2resize.sourceforge.net/ext2resize-1.1.17.tar.gz Now, when I try to resize an online ext3 filesystem with ext2online I get the error: ext2_open: fs has unsupported feature(s) enabled This message is generated at line 887 in ext2.c and the test that is failing seems to be checking, among other things, whether or not the target fs is ext3. Have I got the wrong tools? The patches in the test/ subdir seem to be earlier versions of ext3online kernel patches. Offline resizing of ext3 is working fine. Thanks, -poul > -----Original Message----- > From: Robert Walsh [mailto:rj...@du...] > Sent: Saturday, November 02, 2002 1:01 AM > To: ext2resize > Cc: Andreas Dilger; Bryan O'Sullivan; Andrew Morton > Subject: [ext2resize] New ext3 online resize & e2fsprogs patches > > > Hi all, > > I have posted new ext3 online resize patches to linux-2.4.18 and > linux-2.4.19. New in these patches is a fix to a problem where the > wrong entry from the resize inode dind block was being zeroed > out after > a new gdb was created. This caused the resize to fail at seemingly > arbitrary points, and eventually caused corruption of the filesystem. > > I have also posted new patches to e2fsprogs-1.28 and e2fsprogs-1.29. > New in these patches is a fix to a bug in the resize inode size > calculations to handle really large resize inodes and removal of the > hack to e2fsck to work around this bug. I haven't tested the patch to > 1.29 yet, but it does compile; caveat emptor. > > Note: I just noticed that e2fsprogs-1.30 has been released. > My initial > attempt to apply the 1.29 patch failed, and the port looks nasty, > actually. I'll try get to that in the middle of November, if > I have the > time. Please use 1.28 (or 1.29, if you feel brave) for the moment. > > The upshot of the above patches is that resize should now work for > resizing any arbitrary sized filesystem to any new (larger) size. It > also means that the resulting filesystem passes fsck without any > problems and no hacky workarounds. > > I have tested the patches on 2.4.19 growing various sized filesystems > from 1GB to 1TB. Next week, I should have a chance to test them on > filesystems from 1TB to 4TB (with large block device support.) In the > next month or two, I'm going to try scrape enough disks > together to test > up to 16TB - I'll let you know how it goes. > > All of the above patches are in the CVS tree and posted on the > ext2resize SourceForge patch tracker page. > > Let me know if you have any problems. > > Regards, > Robert. > > -- > Robert Walsh > Amalgamated Durables, Inc. - "We don't make the things you buy." > Email: rj...@du... > |
From: <ad...@cl...> - 2002-11-04 06:38:49
|
On Sun, Nov 03, 2002 at 06:33:15PM -0800, Robert Walsh wrote: > > Patch is in CVS, and also on the SF "patches" page. > > Something I've just noticed right now (in both the 2.4 and 2.5 patches) > is the #define EXT3FS_DEBUG at the top of resize.c. Is that there for > some particular reason, or is it safe to nuke it? It comes before the > #includes, so it probably does have repercussions. I only put that in there while developing the ext3 version, so that it would make it easier to debug. Feel free to turn it off. Cheers, Andreas |
From: Robert W. <rj...@du...> - 2002-11-04 02:32:22
|
> Patch is in CVS, and also on the SF "patches" page. Something I've just noticed right now (in both the 2.4 and 2.5 patches) is the #define EXT3FS_DEBUG at the top of resize.c. Is that there for some particular reason, or is it safe to nuke it? It comes before the #includes, so it probably does have repercussions. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |