ext2resize-devel

Re: [ext2resize] Patches for ext2resize?

[Takashi S. <sh...@tn...>]

Hi,
 
> Hi.
> 
> I am working on a new release of ext2resize, and have noticed your
> patches for
> <URL:http://www.ussg.iu.edu/hypermail/linux/kernel/0604.1/date.html#1090>.
> I believe some of the area already applied to the ext2resize CVS,
> <URL:http://sourceforge.net/projects/ext2resize/>, but am unsure which
> remain.  As the patches available from the mailing list archives fail
> to apply, it is a bit hard for me to verify this.
> 
> Do you have time to check which of your patches are missing from the
> ext2resize CVS, and submit updated versions relative to the current
> CVS to the ext2resize-devel at lists.sourceforge.net mailing list?

Sure, I have checked ext2resize in CVS.
The patch to fix calculation of offsets wasn't applied.
You can get it from following URL.

http://marc.theaimsgroup.com/?l=linux-kernel&m=114856199101617&w=1

This patch is small so you can apply manually if you cannot apply
automatically by patch command.

If you have some questions, feel free to ask me.

Cheers, sho 

[ext2resize] Patches for ext2resize?

[Petter R. <pe...@hu...>]

Hi.

I am working on a new release of ext2resize, and have noticed your
patches for
<URL:http://www.ussg.iu.edu/hypermail/linux/kernel/0604.1/date.html#1090>.
I believe some of the area already applied to the ext2resize CVS,
<URL:http://sourceforge.net/projects/ext2resize/>, but am unsure which
remain.  As the patches available from the mailing list archives fail
to apply, it is a bit hard for me to verify this.

Do you have time to check which of your patches are missing from the
ext2resize CVS, and submit updated versions relative to the current
CVS to the ext2resize-devel at lists.sourceforge.net mailing list?

I hope to make a new release of ext2resize this weekend, so it would
be nice if you managed to reply soon.

Cc to the ext2resize-devel mailing list, to keep the rest of the
  ext2resize team updated.

Friendly,
-- 
Petter Reinholdtsen

[ext2resize] Releasing version 1.1.20?

[Petter R. <pe...@hu...>]

I believe it is time to release a new version of ext2prepare.  I've
compared CVS with the patches in the Debian package, and the only two
remaining ones is the big endian fix and the disabling of offline
resizing support in ext2online.  I believe 1.1.20 should be released
when a decision regarding these two patches have been reached.

This is the current content in NEWS.  Can those of you which did
commit changes since 2004-09-30 check if the summary is correct and
complete.  I've written it by looking at the CVS log, and might have
misunderstood something.

Version 1.1.20 (2006-XX-XX)
 * Fixed a few compiler warnings.
 * Fix typos in the documentation and manual.
 * Correct handling of endian issues.
 * Adjust handling of ioctl BLKGETSIZE64 to match recent kernels.
 * Teach ext2prepare how to handle file systems over 2 TiB.
 * Update ext2prepare to use the same resize_inode format as mke2fs.
 * Renamed some functions to make the code easier to read.
 * Fix bug in ext2 metainfo handling (use correct offset).
 * Corrected and improved program output.

Version 1.1.19 (2004-09-30)
 [news summary were not recored at the time]

Friendly,
-- 
Petter Reinholdtsen

[ext2resize] [PATCH] disable fallback to offline resizing in ext2online

[Petter R. <pe...@hu...>]

I've checked all the patches in the debian package, and only two
remains now.  The previous one for big endian support, and this one to
disable offline resizing fallback in ext2online.

Should this be commited?  It disable a large chunk of code.  If it is
commited, it might be better to remove the unused code completely?

#! /bin/sh /usr/share/dpatch/dpatch-run
## 70_nofallback
##
## DP: Based on patch found in the suse and redhat version, where the
## DP: ext2online fallback to offline resizing is disabled.

--- ext2resize-1.1.19.orig/src/ext2online.c
+++ ext2resize-1.1.19/src/ext2online.c
@@ -507,7 +507,13 @@
 	 */
 	if (ext2_ioctl(fs, EXT2_IOC_GROUP_EXTEND, &size))
 		fs->flags |= FL_IOCTL;
-	else if (errno != ENOTTY)
+	else /* if (errno != ENOTTY) */
+	  /*
+	   * Disable fallback to offline resizing.  This change was
+	   * found in the Fedora/RedHat package, and was explained
+	   * with "resize2fs is incompatible with online resize, and
+	   * can result in corrupt filesystems."  Use resize2fs instead.
+	   */
 		return 0;
 
 	ra = fs->newblocks - size;

[ext2resize] [PATCH] More endian-fixes (from fedora patch)

[Petter R. <pe...@hu...>]

I've read through the 01_endianess-fixes-fedora patch from the debian
package, and compared it to the current CVS source.  These are the
changes I believe are left to apply.  Can anyone have a look at let me
know if it seem correct?

The change to ext2_fs.h seem to be mostly irrelevant, just document
more of the blocks content.  The rest look relevant to this change.
Should I commit the changes to the ext2_super_block struct, or just
drop that part?

I do not have a big-endian machine to test on, so I have no idea if
this actually work there or not.

Index: src/ext2_fs.h
===================================================================
RCS file: /cvsroot/ext2resize/ext2resize/src/ext2_fs.h,v
retrieving revision 1.8
diff -u -3 -p -u -r1.8 ext2_fs.h
--- src/ext2_fs.h	3 Jul 2002 17:52:24 -0000	1.8
+++ src/ext2_fs.h	10 Jun 2006 06:09:01 -0000
@@ -459,8 +459,16 @@ struct ext2_super_block {
 	__u32	s_journal_inum;		/* inode number of journal file */
 	__u32	s_journal_dev;		/* device number of journal file */
 	__u32	s_last_orphan;		/* start of list of inodes to delete */
+	__u32	s_hash_seed[4];		/* HTREE hash seed */
+	__u8	s_def_hash_version;	/* Default hash version to use */
+	__u8	s_jnl_backup_type; 	/* Default type of journal backup */
+	__u16	s_reserved_word_pad;
+	__u32	s_default_mount_opts;
+	__u32	s_first_meta_bg;	/* First metablock group */
+	__u32	s_mkfs_time;		/* When the filesystem was created */
+	__u32	s_jnl_blocks[17]; 	/* Backup of the journal inode */
 
-	__u32	s_reserved[197];	/* Padding to the end of the block */
+	__u32	s_reserved[172];	/* Padding to the end of the block */
 };
 
 /*
Index: src/ext2.h
===================================================================
RCS file: /cvsroot/ext2resize/ext2resize/src/ext2.h,v
retrieving revision 1.25
diff -u -3 -p -u -r1.25 ext2.h
--- src/ext2.h	9 Jun 2006 21:25:47 -0000	1.25
+++ src/ext2.h	10 Jun 2006 06:09:01 -0000
@@ -238,6 +238,9 @@ struct ext2_fs *ext2_mkfs(struct ext2_de
 /* resize */
 int ext2_resize_fs(struct ext2_fs *fs);
 
+/* fs byte-swap */
+void ext2fs_swab_group_desc(struct ext2_fs *fs, struct ext2_group_desc *gdp);
+
 /* unix I/O */
 loff_t ext2_llseek(unsigned int fd, loff_t offset, unsigned int whence);
 struct ext2_dev_handle *ext2_make_dev_handle_from_file(char *dev, char *dir,
Index: src/ext2.c
===================================================================
RCS file: /cvsroot/ext2resize/ext2resize/src/ext2.c,v
retrieving revision 1.32
diff -u -3 -p -u -r1.32 ext2.c
--- src/ext2.c	9 Jun 2006 21:25:47 -0000	1.32
+++ src/ext2.c	10 Jun 2006 06:09:01 -0000
@@ -35,6 +35,9 @@ static const char _ext2_c[] = "$Id: ext2
 
 unsigned char _bitmap[8] = {0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80};
 
+static void ext2_swab_inode(struct ext2_fs *fs,
+		     struct ext2_inode *t, struct ext2_inode *f, 
+		     int hostorder);
 
 void ext2_print_version(FILE *outfile, char *progname)
 {
@@ -258,6 +261,7 @@ void ext2_read_inode(struct ext2_fs *fs,
 	bh = ext2_bread(fs, blk);
 	memcpy(inode, bh->data + off, sizeof(struct ext2_inode));
 	ext2_brelse(bh, 0);
+	ext2_swab_inode(fs, inode, inode, 0);
 }
 
 void ext2_set_inode_state(struct ext2_fs *fs, ino_t ino, int state,
@@ -885,17 +889,112 @@ void ext2_swab_super(struct ext2_fs *fs)
 	}
 }
 
+void ext2fs_swab_group_desc(struct ext2_fs *fs, struct ext2_group_desc *gdp)
+{
+	if(fs->flags & FL_SWAB_BYTES) {
+		gdp->bg_block_bitmap = ext2fs_swab32(gdp->bg_block_bitmap);
+		gdp->bg_inode_bitmap = ext2fs_swab32(gdp->bg_inode_bitmap);
+		gdp->bg_inode_table = ext2fs_swab32(gdp->bg_inode_table);
+		gdp->bg_free_blocks_count = ext2fs_swab16(gdp->bg_free_blocks_count);
+		gdp->bg_free_inodes_count = ext2fs_swab16(gdp->bg_free_inodes_count);
+		gdp->bg_used_dirs_count = ext2fs_swab16(gdp->bg_used_dirs_count);
+	}
+}
 void ext2_swab_gds(struct ext2_fs *fs)
 {
 	if(fs->flags & FL_SWAB_BYTES) {
     		int group;
 		for(group = 0; group < fs->gdblocks; group++) {
-		    fs->gd[group].bg_block_bitmap = ext2fs_swab32(fs->gd[group].bg_block_bitmap);
-		    fs->gd[group].bg_inode_bitmap = ext2fs_swab32(fs->gd[group].bg_inode_bitmap);
-		    fs->gd[group].bg_inode_table = ext2fs_swab32(fs->gd[group].bg_inode_table);
-		    fs->gd[group].bg_free_blocks_count = ext2fs_swab16(fs->gd[group].bg_free_blocks_count);
-		    fs->gd[group].bg_free_inodes_count = ext2fs_swab16(fs->gd[group].bg_free_inodes_count);
-		    fs->gd[group].bg_used_dirs_count = ext2fs_swab16(fs->gd[group].bg_used_dirs_count);
+			ext2fs_swab_group_desc(fs, &(fs->gd[group]));
+		}
+	}
+}
+
+static inline blk_t ext2fs_inode_data_blocks(struct ext2_fs *fs,
+					     struct ext2_inode *inode)
+{
+       return inode->i_blocks -
+              (inode->i_file_acl ? fs->blocksize >> 9 : 0);
+}
+
+#define LINUX_S_IFMT	00170000
+#define LINUX_S_IFLNK	00120000
+#define LINUX_S_ISLNK(m)	(((m) & LINUX_S_IFMT) == LINUX_S_IFLNK)
+
+static void ext2_swab_inode(struct ext2_fs *fs,
+		     struct ext2_inode *t, struct ext2_inode *f, 
+		     int hostorder)
+{
+	if(fs->flags & FL_SWAB_BYTES) {
+		unsigned i;
+		int islnk = 0;
+	
+		if (hostorder && LINUX_S_ISLNK(f->i_mode))
+			islnk = 1;
+		t->i_mode = ext2fs_swab16(f->i_mode);
+		if (!hostorder && LINUX_S_ISLNK(t->i_mode))
+			islnk = 1;
+		t->i_uid = ext2fs_swab16(f->i_uid);
+		t->i_size = ext2fs_swab32(f->i_size);
+		t->i_atime = ext2fs_swab32(f->i_atime);
+		t->i_ctime = ext2fs_swab32(f->i_ctime);
+		t->i_mtime = ext2fs_swab32(f->i_mtime);
+		t->i_dtime = ext2fs_swab32(f->i_dtime);
+		t->i_gid = ext2fs_swab16(f->i_gid);
+		t->i_links_count = ext2fs_swab16(f->i_links_count);
+		t->i_blocks = ext2fs_swab32(f->i_blocks);
+		t->i_flags = ext2fs_swab32(f->i_flags);
+		t->i_file_acl = ext2fs_swab32(f->i_file_acl);
+		t->i_dir_acl = ext2fs_swab32(f->i_dir_acl);
+		if (!islnk || ext2fs_inode_data_blocks(fs, t)) {
+			for (i = 0; i < EXT2_N_BLOCKS; i++)
+				t->i_block[i] = ext2fs_swab32(f->i_block[i]);
+		} else if (t != f) {
+			for (i = 0; i < EXT2_N_BLOCKS; i++)
+				t->i_block[i] = f->i_block[i];
+		}
+		t->i_generation = ext2fs_swab32(f->i_generation);
+		t->i_faddr = ext2fs_swab32(f->i_faddr);
+
+		switch (fs->sb.s_creator_os) {
+		case EXT2_OS_LINUX:
+			t->osd1.linux1.l_i_reserved1 =
+				ext2fs_swab32(f->osd1.linux1.l_i_reserved1);
+			t->osd2.linux2.l_i_frag = f->osd2.linux2.l_i_frag;
+			t->osd2.linux2.l_i_fsize = f->osd2.linux2.l_i_fsize;
+			t->osd2.linux2.i_pad1 = ext2fs_swab16(f->osd2.linux2.i_pad1);
+			t->osd2.linux2.l_i_uid_high =
+				ext2fs_swab16 (f->osd2.linux2.l_i_uid_high);
+			t->osd2.linux2.l_i_gid_high =
+				ext2fs_swab16 (f->osd2.linux2.l_i_gid_high);
+			t->osd2.linux2.l_i_reserved2 =
+				ext2fs_swab32(f->osd2.linux2.l_i_reserved2);
+			break;
+		case EXT2_OS_HURD:
+			t->osd1.hurd1.h_i_translator =
+				ext2fs_swab32 (f->osd1.hurd1.h_i_translator);
+			t->osd2.hurd2.h_i_frag = f->osd2.hurd2.h_i_frag;
+			t->osd2.hurd2.h_i_fsize = f->osd2.hurd2.h_i_fsize;
+			t->osd2.hurd2.h_i_mode_high =
+				ext2fs_swab16 (f->osd2.hurd2.h_i_mode_high);
+			t->osd2.hurd2.h_i_uid_high =
+				ext2fs_swab16 (f->osd2.hurd2.h_i_uid_high);
+			t->osd2.hurd2.h_i_gid_high =
+				ext2fs_swab16 (f->osd2.hurd2.h_i_gid_high);
+			t->osd2.hurd2.h_i_author =
+				ext2fs_swab32 (f->osd2.hurd2.h_i_author);
+			break;
+		case EXT2_OS_MASIX:
+			t->osd1.masix1.m_i_reserved1 =
+				ext2fs_swab32(f->osd1.masix1.m_i_reserved1);
+			t->osd2.masix2.m_i_frag = f->osd2.masix2.m_i_frag;
+			t->osd2.masix2.m_i_fsize = f->osd2.masix2.m_i_fsize;
+			t->osd2.masix2.m_pad1 = ext2fs_swab16(f->osd2.masix2.m_pad1);
+			t->osd2.masix2.m_i_reserved2[0] =
+				ext2fs_swab32(f->osd2.masix2.m_i_reserved2[0]);
+			t->osd2.masix2.m_i_reserved2[1] =
+				ext2fs_swab32(f->osd2.masix2.m_i_reserved2[1]);
+			break;
 		}
 	}
 }
Index: src/ext2online.c
===================================================================
RCS file: /cvsroot/ext2resize/ext2resize/src/ext2online.c,v
retrieving revision 1.24
diff -u -3 -p -u -r1.24 ext2online.c
--- src/ext2online.c	30 Sep 2004 14:12:01 -0000	1.24
+++ src/ext2online.c	10 Jun 2006 06:09:01 -0000
@@ -238,10 +238,12 @@ static int ext2_check_one_rsv(struct ext
 		unsigned int three = 1, five = 5, seven = 7;
 		unsigned int group;
 		int last = 0;
-
-		if (dindir_buf[gdb_num % apb] != pri_blk) {
+		blk_t dblk;
+		
+		dblk = le32_to_cpu(dindir_buf[gdb_num % apb]);
+		if (dblk != pri_blk) {
 			fprintf(stderr, "found %d not %d at %d[%d]\n",
-				dindir_buf[gdb_num % apb], pri_blk,
+				dblk, pri_blk,
 				fs->resize.i_block[EXT2_DIND_BLOCK],
 				gdb_num % apb);
 			ret = 0;
@@ -253,16 +255,17 @@ static int ext2_check_one_rsv(struct ext
 		while ((group = ext2_list_backups(fs, &three, &five, &seven)) <
 		       fs->numgroups) {
 			__u32 *pri_buf = (__u32 *)(pri_bh->data);
-			blk_t bku_blk;
+			blk_t bku_blk, pblk;
 
 			bku_blk = pri_blk + group * fs->sb.s_blocks_per_group;
 
 			if (fs->flags & FL_DEBUG)
 				printf("checking for group block %d in Bond\n",
 				       bku_blk);
-			if (pri_buf[last] != bku_blk) {
+			pblk = le32_to_cpu(pri_buf[last]);
+			if (pblk != bku_blk) {
 				fprintf(stderr, "found %d not %d at %d[%d]\n",
-					pri_buf[last], bku_blk, pri_blk, last);
+					pblk, bku_blk, pri_blk, last);
 				ext2_brelse(pri_bh, 0);
 				ret = 0;
 				goto exit_dind;
@@ -340,6 +343,7 @@ static blk_t ext2_make_group(struct ext2
 	}
 	gdp = (struct ext2_group_desc *)bh->data +
 	      (group % (fs->blocksize/sizeof(struct ext2_group_desc)));
+	ext2fs_swab_group_desc(fs, gdp);
 
 	gdp->bg_block_bitmap = start + new_bb;
 	gdp->bg_inode_bitmap = start + new_ib;

Re: [ext2resize] Is the ext2resize project still alive?

[Andreas D. <ad...@cl...>]

On Jun 10, 2006  00:09 +0200, Petter Reinholdtsen wrote:
> [Andreas Dilger]
> > You've been added as a developer, so you are free to merge in all of
> > the RH and Debian patches to CVS.
> 
> Thank you.  I've commited the obvious ones from the debian package,
> and prepared the source for release.  'make distcheck' now work.
> 
> The remaining ones are the byteorder and resize_inode patches, as well
> as the patches disabling offline resizing (patches
> 01_endianess-fixes-fedora, 02_noresize-bigendian, 05_ext3newformat
> and70_nofallback).  I'm not sure which of these have equivalent
> patches commited already, and which should be commited as they are.
> Will need to investigate more.

I'm not sure.  I agree we want the new-format resize inode change
(there was a patch for this by Takashi Sato posted to ext2-devel)
and the endianness changes, but I don't know if the latter is in
CVS yet or not.

> Sounds reasonable to me, but I do not have the knowledge about ext2
> and ext3 file systems to do it myself, and am unlikely to find time to
> study the topic any time soon.  Would such change work with online
> resizing too?  Until resize2fs is modified to do what it takes to
> handle online resizing on any ext2 and ext3 file system, I believe
> ext2prepare still have its place.

I believe the latest resize2fs can already do the ioctls necessary
to run online resizing, but it can't do the prepare step.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

Re: [ext2resize] Is the ext2resize project still alive?

[Petter R. <pe...@hu...>]

[Andreas Dilger]
> You've been added as a developer, so you are free to merge in all of
> the RH and Debian patches to CVS.

Thank you.  I've commited the obvious ones from the debian package,
and prepared the source for release.  'make distcheck' now work.

The remaining ones are the byteorder and resize_inode patches, as well
as the patches disabling offline resizing (patches
01_endianess-fixes-fedora, 02_noresize-bigendian, 05_ext3newformat
and70_nofallback).  I'm not sure which of these have equivalent
patches commited already, and which should be commited as they are.
Will need to investigate more.

Any of you know more?

> I agree.  My preference would be to modify e2fsprogs resize2fs to
> allow it to prepare filesystems.  In essence the prepare step is
> mostly just a filesystem resize (i.e. possibly moving the inode
> table and bitmaps to allow a bigger group descriptor table), and as
> a last step adding the resize inode (with e2fsck can already do).  I
> don't _think_ it would be a huge amount of work, I just never have
> time to work on it.

Sounds reasonable to me, but I do not have the knowledge about ext2
and ext3 file systems to do it myself, and am unlikely to find time to
study the topic any time soon.  Would such change work with online
resizing too?  Until resize2fs is modified to do what it takes to
handle online resizing on any ext2 and ext3 file system, I believe
ext2prepare still have its place.

> Your happiness is entirely in your hands now.  Not too often you are
> given this opportunity :-).

Hehe.  :)

Friendly,
-- 
Petter Reinholdtsen

Re: [ext2resize] Is the ext2resize project still alive?

[Andreas D. <ad...@cl...>]

On Jun 04, 2006  13:33 +0200, Petter Reinholdtsen wrote:
> Hm.  I hope someone will find time to at least commit the trivial
> fixes I have submitted patches for and release a new version, to
> reduce the amount of modifications I have to do the Debian package and
> thus make it easier for me to maintain ext2resize in Debian.  I could
> commit the trivial patches myself, but then I need to get write access
> to the repository.  I'm 'pere' on sourceforge.

You've been added as a developer, so you are free to merge in all of
the RH and Debian patches to CVS.

> > I think the ext2resize development is frozen now because developers
> > are busy with their jobs as Andreas Dilger and I am.  And ext2resize
> > became less important as it used to be after resize2fs from
> > e2fsprogs was released as free software.
> 
> Sure, ext2resize isn't very important anymore, but the ext2prepare
> program is still needed (until all ext2/ext3 file systems include the
> resize_inode), and because of this I spend some time on the package.
> Online resize is required for Linux to become a reasonable alternative
> as a large scale file server, and I want that to happen. :)

I agree.  My preference would be to modify e2fsprogs resize2fs to allow
it to prepare filesystems.  In essence the prepare step is mostly just
a filesystem resize (i.e. possibly moving the inode table and bitmaps
to allow a bigger group descriptor table), and as a last step adding the
resize inode (with e2fsck can already do).  I don't _think_ it would be
a huge amount of work, I just never have time to work on it.

> Thank you.  If only I could release a version 1.1.20-1 without any
> debian specific patches, I would be truly happy. :)

Your happiness is entirely in your hands now.  Not too often you are
given this opportunity :-).

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

Re: [ext2resize] Is the ext2resize project still alive?

[Petter R. <pe...@hu...>]

[Coywolf Qi Hunt]
> The last commits were made by me.  However there's some deeper
> design problem which prevents me from fixing it cleanly and
> completely.

Hm.  I hope someone will find time to at least commit the trivial
fixes I have submitted patches for and release a new version, to
reduce the amount of modifications I have to do the Debian package and
thus make it easier for me to maintain ext2resize in Debian.  I could
commit the trivial patches myself, but then I need to get write access
to the repository.  I'm 'pere' on sourceforge.

> I think the ext2resize development is frozen now because developers
> are busy with their jobs as Andreas Dilger and I am.  And ext2resize
> became less important as it used to be after resize2fs from
> e2fsprogs was released as free software.

Sure, ext2resize isn't very important anymore, but the ext2prepare
program is still needed (until all ext2/ext3 file systems include the
resize_inode), and because of this I spend some time on the package.
Online resize is required for Linux to become a reasonable alternative
as a large scale file server, and I want that to happen. :)

> I just saw your debian 1.1.19-6 release, so reply. Thanks for your work.

Thank you.  If only I could release a version 1.1.20-1 without any
debian specific patches, I would be truly happy. :)

Friendly,
-- 
Petter Reinholdtsen

Re: [ext2resize] ext2prepare corrupts ext3 file systems

[Petter R. <pe...@hu...>]

[Coywolf Qi Hunt]
> Those patches were done by *me*. There's a reason why I don't merge
> them.  You may feel free to take them in your debian package.

I did, and hope the extra testing the patch will receive make you more
confident that it is working.  I do not know the inner working of ext2
and ext3, so I did not check the logic in the patch, but it did get
rid of the warning from e2fsck.

Friendly,
-- 
Petter Reinholdtsen

Re: [ext2resize] ext2prepare corrupts ext3 file systems

[Coywolf Qi H. <qi...@fc...>]

On Tue, May 23, 2006 at 09:21:28AM +0200, Petter Reinholdtsen wrote:
> [Andreas Dilger]
> > That's because ext2prepare was never updated to support the "new"
> > ext3 resize inode format.  There was actually a patch posted on
> > ext2-devel which may fix this from Takashi Sato, but I haven't had
> > time to look at it yet:
> 
> Aha.  Thank you for the tip.  I fetched the patch (had to apply it
> manually as I failed to find a mailing list archive with the original
> email (aka the non-HTML version), and gave it a go.  It fixed the
> problem.  e2fsck no longer reports errors when I run it after
> ext2prepare.
> 
> I hope you find time to look at it soon.  I consider including it in
> the Debian package for now, but would love to have others opinion on
> it first.

Those patches were done by *me*. There's a reason why I don't merge them.
You may feel free to take them in your debian package.
-- 
Coywolf Qi Hunt

Re: [ext2resize] Where is the current ext2resize source repository?

[Petter R. <pe...@hu...>]

[Andreas Dilger]
> The ext2resize repo has not moved.  Unfortunately, it is a case of
> too much other work and family responsibilities is preventing me
> from working on ext2resize anymore.

OK.  Good to know your status.  What about the other registered
ext2resize developers?

> If you are interested in
> becoming a maintainer and updating CVS and making a new release I'd
> be happy to do so.

Sure, go ahead.  I am pere on sourceforge.

I can at least commit the low-hanging fruits, though I do not really
have deep knowledge about ext2 and ext3, and thus will be fumbling in
the dark with the hard bugs.

Friendly,
-- 
Petter Reinholdtsen

Re: [ext2resize] Where is the current ext2resize source repository?

[Andreas D. <ad...@cl...>]

On May 23, 2006  12:01 +0200, Petter Reinholdtsen wrote:
> Is the Sourceforge CVS the current source repository for ext2resize?
> I've posted a few patches from the Debian package which is not
> commited there yet, so I wonder if it was moved when the Sourceforge
> CVS was down the last time.

The ext2resize repo has not moved.  Unfortunately, it is a case of too
much other work and family responsibilities is preventing me from
working on ext2resize anymore.  If you are interested in becoming a
maintainer and updating CVS and making a new release I'd be happy to
do so.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

Re: [ext2resize] Is the ext2resize project still alive?

[Coywolf Qi H. <qi...@fc...>]

On Sat, May 20, 2006 at 10:21:57AM +0200, Petter Reinholdtsen wrote:
> 
> Is the ext2resize project still alive?  No activity on the mailing
> list since my last email a month ago, and no commits to the
> Sourceforge CVS since 2006-02-20 make me wonder.

The last commits were made by me.  However there's some deeper design
problem which prevents me from fixing it cleanly and completely.

I think the ext2resize development is frozen now because developers are busy
with their jobs as Andreas Dilger and I am.  And ext2resize became less important
as it used to be after resize2fs from e2fsprogs was released as free software.
BTW, ext2resize consumes less memory than resize2fs.

I just saw your debian 1.1.19-6 release, so reply. Thanks for your work.

-- qiyong

> 
> Anyone know more?  I maintain the Debian package and would love to
> have a working ext2prepare tool available in Debian until all ext2 and
> ext3 filesystems support the resize_inode option. :)
> 
> Friendly,
> -- 
> Petter Reinholdtsen

[ext2resize] Where is the current ext2resize source repository?

[Petter R. <pe...@hu...>]

Is the Sourceforge CVS the current source repository for ext2resize?
I've posted a few patches from the Debian package which is not
commited there yet, so I wonder if it was moved when the Sourceforge
CVS was down the last time.

Friendly,
-- 
Petter Reinholdtsen

Re: [ext2resize] ext2prepare corrupts ext3 file systems

[Petter R. <pe...@hu...>]

[Andreas Dilger]
> That's because ext2prepare was never updated to support the "new"
> ext3 resize inode format.  There was actually a patch posted on
> ext2-devel which may fix this from Takashi Sato, but I haven't had
> time to look at it yet:

Aha.  Thank you for the tip.  I fetched the patch (had to apply it
manually as I failed to find a mailing list archive with the original
email (aka the non-HTML version), and gave it a go.  It fixed the
problem.  e2fsck no longer reports errors when I run it after
ext2prepare.

I hope you find time to look at it soon.  I consider including it in
the Debian package for now, but would love to have others opinion on
it first.

Friendly,
-- 
Petter Reinholdtsen

Re: [ext2resize] ext2prepare corrupts ext3 file systems

[Andreas D. <ad...@cl...>]

On May 21, 2006  08:58 +0200, Petter Reinholdtsen wrote:
> When using ext2prepare to make sure a ext3 file system is online
> resizable, e2fsck find errors in the file system after the conversion.
> Anyone know what is going on here?

That's because ext2prepare was never updated to support the "new" ext3
resize inode format.  There was actually a patch posted on ext2-devel
which may fix this from Takashi Sato, but I haven't had time to look
at it yet:

[Ext2-devel] [RFC][17/21]ext2resize fix resize_inode format

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

[ext2resize] ext2prepare corrupts ext3 file systems

[Petter R. <pe...@hu...>]

When using ext2prepare to make sure a ext3 file system is online
resizable, e2fsck find errors in the file system after the conversion.
Anyone know what is going on here?

This problem is reported in debian, <URL:http://bugs.debian.org/348778>.

The following commands demonstrate the problem (assuming LVM volume
gorup intern_vg and more than 150 MiB free space on the volume group):

  lvcreate -L150 -ntest_lv intern_vg
  mke2fs -j /dev/intern_vg/test_lv
  ext2prepare /dev/intern_vg/test_lv 500m
  e2fsck -y -f /dev/intern_vg/test_lv

This is the output from e2fsck:

# e2fsck -y -f /dev/vg_system/lv_test
e2fsck 1.37 (21-Mar-2005)
Resize inode not valid.  Recreate? yes

Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -3 +4389 -8195 -24579 -40963 -57347 -73731
Fix? yes

Free blocks count wrong for group #0 (3803, counted=3804).
Fix? yes

Free blocks count wrong for group #1 (7931, counted=7932).
Fix? yes

Free blocks count wrong for group #3 (7931, counted=7932).
Fix? yes

Free blocks count wrong for group #5 (7931, counted=7932).
Fix? yes

Free blocks count wrong for group #7 (7931, counted=7932).
Fix? yes

Free blocks count wrong for group #9 (7931, counted=7932).
Fix? yes

Free blocks count wrong (146599, counted=146605).
Fix? yes


/dev/vg_system/lv_test: ***** FILE SYSTEM WAS MODIFIED *****
/dev/vg_system/lv_test: 11/38912 files (0.0% non-contiguous), 9043/155648 blocks
#

Friendly,
-- 
Petter Reinholdtsen

[ext2resize] Is the ext2resize project still alive?

[Petter R. <pe...@hu...>]

Is the ext2resize project still alive?  No activity on the mailing
list since my last email a month ago, and no commits to the
Sourceforge CVS since 2006-02-20 make me wonder.

Anyone know more?  I maintain the Debian package and would love to
have a working ext2prepare tool available in Debian until all ext2 and
ext3 filesystems support the resize_inode option. :)

Friendly,
-- 
Petter Reinholdtsen

[ext2resize] New release of ext2resize?

[Petter R. <pe...@hu...>]

Is there a new release of ext2resize planned anytime soon?  Will it
fix the problem with ext2prepare reported on
<URL:http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=ext2resize>?  If
so, are the patches to fix it available from somewhere?

Friendly,
-- 
Petter Reinholdtsen

Re: [ext2resize] [PATCH] Endless loop in ext2_move_blocks()?

[Petter R. <pe...@hu...>]

[Andreas Dilger]
> Actually, loop should be from num-1 to 0 (i.e. copy 'num' blocks in
> reverse order), and your change would make this from num to 1.  The
> change is correct, just your description is slightly wrong...

Right.  Sorry about the confusion introduced.

> This seems fine.

Great.  I hope a new version can be released soon, to fix the problems
with the current package.  The broken ext2prepare is the most
important problem for me as the Debian maintainer, but I would love to
have more of the Debian and RedHat patches included in the official
version.

> That really depends on how many such errors there are, and how easy
> or hard it is to fix them.  I don't disagree in principle, but it
> would be bad to miss important warnings in a flood of unimportant
> ones.

In my experience, it is not very hard to write correct programs which
compiles without warnings, and all the new warnings showing up
normally indicate some problem.

Friendly,
-- 
Petter Reinholdtsen

Re: [ext2resize] ext2resize on big endian, corrupt file systems and crashes?

[Andreas D. <ad...@cl...>]

On Mar 17, 2006  08:24 +0100, Petter Reinholdtsen wrote:
> [Andreas Dilger]
> > As good a place as any.  I'm actually somewhat interested in getting
> > rid of ext2resize itself and just merging the functionality into
> > e2fsprogs as RH has done, just to avoid duplication of maintenance
> > effort.
> 
> As far as I could see, the e2fsprogs souce RPM from redhat include the
> source for both e2fsprogs and ext2resize, and isn't a merge of
> functionallity.  So they still include ext2resize, but it does not
> seem that way from the list of RPMs.
> 
> But I would love to only have one package to maintain, so if e2fsprogs
> is up for the job, I am more than willing to drop ext2resize. :)

Ted Ts'o just announced he had added ext2online functionality to
resize2fs.  The only remaining holdout is ext2prepare (which doesn't
work for ext3 in any case, AFAIR, as it hasn't been updated to use
the ext3-style resize inode).

I think (without having looked) that it should be possible to modify
resize2fs to do a "resize" of the filesystem to the desired maximum
size (moving files, itable, etc out of the way of the group descriptor
table), but leaving the end of the filesystem alone.  Then, all it
would need to do is change s_reserved_gdt_blocks, and allocate the
reserved group descriptor blocks into the resize inode in the right order.

> > I'm also considering if we should at least install the ext2online
> > binary as ext3online and maybe have an (sym)link for compatibility.
> > It actually will not work on ext2 filesystems any more.
> 
> It does not?  Perhaps that is why I could not get the byteorder patch
> to work?  Please tell me more.

Well, the ext2online code in RH will not try the old ext2 "write to
block device from userspace" method (c.f. "disable-fallback" patch,
or similar).  To be honest, having ext3 do this work with the help of
the journal is much safer.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

[ext2resize] Re: [Ext2-devel] Re: [patch] ext2fs_allocate_group_table cleanup

[Andreas D. <ad...@cl...>]

On Mar 17, 2006  13:00 -0500, Theodore Ts'o wrote:
> > As for ext2prepare, that is really just resize2fs that doesn't extend
> > the end of the filesystem, and creates/modifies the resize inode.  I
> > believe that e2fsck already handles the resize inode, so combining the
> > parts is all that's needed.
> 
> Not really.  You *can* do it using some somewhat obscure debugfs,
> followed by running e2fsck -f and answering yes to a whole bunch of
> scary questions, and in some cases it still might not work.  So we
> still need to enhance either resize2fs or write some new program if we
> want ext2prepare functionality.

Hmm, I'd think the basic functionality is mostly the same.  Use resize2fs
to move the inode bitmaps as if you were really going to resize the filesystem
and needed more group descriptor blocks.  Then "allocate" the reserved
group descriptor blocks to the resize inode.  What more is needed?  The
hard part of the operation (moving the itable, and file data blocks) is
already implemented in resize2fs.

> One thing I have thought about doing is simply enhacing
> /usr/src/linux/fs/ext3/resize.c to support metablock groups, and
> automatically switching to use meta blockgroups once there are no more
> reserved gdt blocks.  This means you no longer need ext2prepare, and
> aside from some conservative stick-in-the-mud types running RHEL 3 or
> other distro's with 2.4 kernels (heck, even Debian has finally gotten
> off of 2.4), all modern Linux systems will support the metablock group
> feature anyway.  This will allow us to do resizing without needing to
> use ext2prepare, or needing to reserve blocks at all.  

I believe that this is already implemented by Glauber de Oliveira Costa
<go...@br...> and posted to ext2-devel a month ago, see:
"[PATCH] Online Resizing - New attempt".  Sadly, I haven't yet looked
at it.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

[ext2resize] Re: [Ext2-devel] Re: [patch] ext2fs_allocate_group_table cleanup

[Theodore Ts'o <ty...@mi...>]

On Fri, Mar 17, 2006 at 10:19:44AM -0700, Andreas Dilger wrote:
> On Mar 17, 2006  10:21 -0500, Theodore Ts'o wrote:
> > I've been meaning to ask you.... now that I have online resizing
> > support integrated into resize2fs, is there any other features in
> > ext2resize that isn't in resize2fs?  (Aside from ext2prepare, of
> > course.)
> 
> What???  I didn't know that was done.  Since when did you do that?
> Excellent news.

Last night, around 1am.  :-)  

It's not yet checked into mercurial yet, but it's working.  I still
need to quickly update the man page and decide whether or not provide
a command-line compatible version of ext2online or just try to tell
users/scripts to recode to use resize2fs instead. 

> As for ext2prepare, that is really just resize2fs that doesn't extend
> the end of the filesystem, and creates/modifies the resize inode.  I
> believe that e2fsck already handles the resize inode, so combining the
> parts is all that's needed.

Not really.  You *can* do it using some somewhat obscure debugfs,
followed by running e2fsck -f and answering yes to a whole bunch of
scary questions, and in some cases it still might not work.  So we
still need to enhance either resize2fs or write some new program if we
want ext2prepare functionality.

One thing I have thought about doing is simply enhacing
/usr/src/linux/fs/ext3/resize.c to support metablock groups, and
automatically switching to use meta blockgroups once there are no more
reserved gdt blocks.  This means you no longer need ext2prepare, and
aside from some conservative stick-in-the-mud types running RHEL 3 or
other distro's with 2.4 kernels (heck, even Debian has finally gotten
off of 2.4), all modern Linux systems will support the metablock group
feature anyway.  This will allow us to do resizing without needing to
use ext2prepare, or needing to reserve blocks at all.  

						- Ted

[ext2resize] Re: [Ext2-devel] Re: [patch] ext2fs_allocate_group_table cleanup

[Andreas D. <ad...@cl...>]

On Mar 17, 2006  10:21 -0500, Theodore Ts'o wrote:
> I've been meaning to ask you.... now that I have online resizing
> support integrated into resize2fs, is there any other features in
> ext2resize that isn't in resize2fs?  (Aside from ext2prepare, of
> course.)

What???  I didn't know that was done.  Since when did you do that?
Excellent news.

As for ext2prepare, that is really just resize2fs that doesn't extend
the end of the filesystem, and creates/modifies the resize inode.  I
believe that e2fsck already handles the resize inode, so combining the
parts is all that's needed.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.