ext2resize-devel Mailing List for GNU ext2resize (Page 3)
Status: Inactive
Brought to you by:
adilger
Menu
▾
▴
ext2resize-devel
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: Theodore Ts'o <ty...@mi...> - 2006-03-17 15:21:51
|
On Fri, Mar 17, 2006 at 01:12:36AM -0700, Andreas Dilger wrote: > While good in theory, I don't think any such guarantee can be made. There > is no restriction on bitmap placement, and things like resize2fs can change > the location of the bitmaps after mke2fs has been run. > > I think ext2resize needs to do its best with whatever it finds, and if > the last group is not the same as the others then it just needs to be > handled as well as possible. Hey Andreas, 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.) Regards, - Ted |
|
From: Andreas D. <ad...@cl...> - 2006-03-17 08:12:47
|
On Mar 17, 2006 14:54 +0800, Coywolf Qi Hunt wrote: > 2006/3/17, Andreas Dilger <ad...@us...>: > > On Mar 17, 2006 10:45 +0800, Coywolf Qi Hunt wrote: > > > Cleanup the fake 'if' statement because of (a % b) <= (b - 1). > > > Conceptually, this fix classifies that with stride, BM < IT impossible. > > > It is for ext2resize bug fix. > > > > > > Signed-off-by: Coywolf Qi Hunt <qi...@fc...> > > > --- > > > > > > diff -r 8991ece34224 lib/ext2fs/alloc_tables.c > > > --- a/lib/ext2fs/alloc_tables.c Fri Mar 10 21:39:40 2006 -0500 > > > +++ b/lib/ext2fs/alloc_tables.c Fri Mar 17 10:30:33 2006 +0800 > > > @@ -51,8 +51,6 @@ errcode_t ext2fs_allocate_group_table(ex > > > start_blk = group_blk + fs->inode_blocks_per_group; > > > start_blk += ((fs->stride * group) % > > > (last_blk - start_blk)); > > > - if (start_blk > last_blk) > > > - start_blk = group_blk; > > > } else > > > start_blk = group_blk; > > > > Hi, > > could you please explain a bit more about this? My thought would be that > > you are correct in saying that this is a "fake 'if' statement", because > > we know the start_blk will always be less than last_blk in any case. > > > > I'm a bit confused about how it relates to a bug in ext2resize however. > > Currently in ext2resize the IT offset is no correct. In order to fix it, > I'd first make sure that in any case, with stride, mke2fs will never > put BM before IT in a group. While good in theory, I don't think any such guarantee can be made. There is no restriction on bitmap placement, and things like resize2fs can change the location of the bitmaps after mke2fs has been run. I think ext2resize needs to do its best with whatever it finds, and if the last group is not the same as the others then it just needs to be handled as well as possible. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. |
|
From: Andreas D. <ad...@cl...> - 2006-03-17 08:07:45
|
On Mar 16, 2006 08:21 +0100, Petter Reinholdtsen wrote: > As i is unsigned, it will always be 0 or higher, and this the else > block is an endless loop. > > What is the best way to fix this? My suggestion is to run i from num > to 0 instead of trying to run from num-1 to -1: 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... > --- ext2resize-1.1.19.orig/src/ext2.c > +++ ext2resize-1.1.19/src/ext2.c > @@ -131,8 +131,8 @@ > for (i = 0; i < num; i++) > ext2_copy_block(fs, src + i, dest + i); > else > - for (i = num - 1; i >= 0; i--) > - ext2_copy_block(fs, src + i, dest + i); > + for (i = num; i > 0; i--) > + ext2_copy_block(fs, src + i - 1, dest + i - 1); This seems fine. > Can the default build be changed to include -W in addition to -Wall? > It show quite a lot of signed/unsigned issues, and I suspect it is > better to expose those to more people. I suggest adding code like > this to configure.in just before the "dnl Checks for libraries." line. > > if eval "test x$GCC = xyes"; then > CFLAGS="$CFLAGS -W -Wall" > fi 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. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. |
|
From: Petter R. <pe...@hu...> - 2006-03-17 07:25:10
|
[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. :) > I'd be supportive of this if Coywolf is interested to merge in the > Fedora and debian patches, after some inspection of course. Great. > In a brief review of the patches, one I can't understand is the use > of a custom canonicalize() function instead of the realpath() glibc > function? The rest of them seem to be reasonable. This patch is already in 1.1.19, I believe. > 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. |
|
From: Andreas D. <ad...@cl...> - 2006-03-17 07:08:47
|
On Mar 16, 2006 07:30 +0100, Petter Reinholdtsen wrote: > Btw, is this a good place to post patches? I found a few patches in > Debian relative to version 1.1.19, and suspect they should be applied > upstream as well. No way to check if they already made it into the > CVS, as described above. 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. > I made the current debian patches available from > <URL:http://developer.skolelinux.no/~pere/debian/ext2resize-debian/>, > and the fedora patches available from > <URL:http://developer.skolelinux.no/~pere/debian/e2fsprogs-fedora/>. > > Please have a look and include the ones that seem good to the next > release of ext2resize. :) > > Is a new release of ext2resize planned in the near future? I'd be supportive of this if Coywolf is interested to merge in the Fedora and debian patches, after some inspection of course. In a brief review of the patches, one I can't understand is the use of a custom canonicalize() function instead of the realpath() glibc function? The rest of them seem to be reasonable. 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. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. |
|
From: Coywolf Qi H. <co...@gm...> - 2006-03-17 06:54:32
|
2006/3/17, Andreas Dilger <ad...@us...>: > On Mar 17, 2006 10:45 +0800, Coywolf Qi Hunt wrote: > > Cleanup the fake 'if' statement because of (a % b) <=3D (b - 1). > > Conceptually, this fix classifies that with stride, BM < IT impossible. > > It is for ext2resize bug fix. > > > > Signed-off-by: Coywolf Qi Hunt <qi...@fc...> > > --- > > > > diff -r 8991ece34224 lib/ext2fs/alloc_tables.c > > --- a/lib/ext2fs/alloc_tables.c Fri Mar 10 21:39:40 2006 -0500 > > +++ b/lib/ext2fs/alloc_tables.c Fri Mar 17 10:30:33 2006 +0800 > > @@ -51,8 +51,6 @@ errcode_t ext2fs_allocate_group_table(ex > > start_blk =3D group_blk + fs->inode_blocks_per_group; > > start_blk +=3D ((fs->stride * group) % > > (last_blk - start_blk)); > > - if (start_blk > last_blk) > > - start_blk =3D group_blk; > > } else > > start_blk =3D group_blk; > > Hi, > could you please explain a bit more about this? My thought would be that > you are correct in saying that this is a "fake 'if' statement", because > we know the start_blk will always be less than last_blk in any case. > > I'm a bit confused about how it relates to a bug in ext2resize however. Currently in ext2resize the IT offset is no correct. In order to fix it, I'd first make sure that in any case, with stride, mke2fs will never put BM before IT in a group. -- Coywolf Qi Hunt |
|
From: Andreas D. <ad...@us...> - 2006-03-17 06:39:35
|
On Mar 17, 2006 10:45 +0800, Coywolf Qi Hunt wrote: > Cleanup the fake 'if' statement because of (a % b) <= (b - 1). > Conceptually, this fix classifies that with stride, BM < IT impossible. > It is for ext2resize bug fix. > > Signed-off-by: Coywolf Qi Hunt <qi...@fc...> > --- > > diff -r 8991ece34224 lib/ext2fs/alloc_tables.c > --- a/lib/ext2fs/alloc_tables.c Fri Mar 10 21:39:40 2006 -0500 > +++ b/lib/ext2fs/alloc_tables.c Fri Mar 17 10:30:33 2006 +0800 > @@ -51,8 +51,6 @@ errcode_t ext2fs_allocate_group_table(ex > start_blk = group_blk + fs->inode_blocks_per_group; > start_blk += ((fs->stride * group) % > (last_blk - start_blk)); > - if (start_blk > last_blk) > - start_blk = group_blk; > } else > start_blk = group_blk; Hi, could you please explain a bit more about this? My thought would be that you are correct in saying that this is a "fake 'if' statement", because we know the start_blk will always be less than last_blk in any case. I'm a bit confused about how it relates to a bug in ext2resize however. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. |
|
From: Coywolf Qi H. <qi...@fc...> - 2006-03-17 02:45:11
|
Hello, Cleanup the fake 'if' statement because of (a % b) <= (b - 1). Conceptually, this fix classifies that with stride, BM < IT impossible. It is for ext2resize bug fix. Signed-off-by: Coywolf Qi Hunt <qi...@fc...> --- diff -r 8991ece34224 lib/ext2fs/alloc_tables.c --- a/lib/ext2fs/alloc_tables.c Fri Mar 10 21:39:40 2006 -0500 +++ b/lib/ext2fs/alloc_tables.c Fri Mar 17 10:30:33 2006 +0800 @@ -51,8 +51,6 @@ errcode_t ext2fs_allocate_group_table(ex start_blk = group_blk + fs->inode_blocks_per_group; start_blk += ((fs->stride * group) % (last_blk - start_blk)); - if (start_blk > last_blk) - start_blk = group_blk; } else start_blk = group_blk; -- Coywolf Qi Hunt |
|
From: Petter R. <pe...@hu...> - 2006-03-16 08:54:57
|
I found this patch in the debian version of ext2resize, fixing the mail address of Joey. Please include it in a future version of ext2resize. --- ext2resize-1.1.19.orig/THANKS +++ ext2resize-1.1.19/THANKS @@ -28,7 +28,7 @@ Andrew Grechko <a_...@so...> Eric Gustavsson <cy...@al...> Michael Harris <mic...@wc...> -Joey Hess <jo...@ma...> +Joey Hess <jo...@de...> Martin Hinner <mh...@li...> Rolf Jakob <rj...@du...> Glenn McGrath <Gle...@jc...> |
|
From: Petter R. <pe...@hu...> - 2006-03-16 07:21:24
|
When building ext2resize 1.1.19 with -W and -Wall, I see this warning:
ext2.c: I funktionen 'ext2_move_blocks':
ext2.c:137: advarsel: comparison of unsigned expression >= 0 is always true
This is the code in question:
blk_t i;
[...]
} else if (src > dest)
for (i = 0; i < num; i++)
ext2_copy_block(fs, src + i, dest + i);
else
for (i = num - 1; i >= 0; i--)
ext2_copy_block(fs, src + i, dest + i);
As i is unsigned, it will always be 0 or higher, and this the else
block is an endless loop.
What is the best way to fix this? My suggestion is to run i from num
to 0 instead of trying to run from num-1 to -1:
--- ext2resize-1.1.19.orig/src/ext2.c
+++ ext2resize-1.1.19/src/ext2.c
@@ -131,8 +131,8 @@
for (i = 0; i < num; i++)
ext2_copy_block(fs, src + i, dest + i);
else
- for (i = num - 1; i >= 0; i--)
- ext2_copy_block(fs, src + i, dest + i);
+ for (i = num; i > 0; i--)
+ ext2_copy_block(fs, src + i - 1, dest + i - 1);
}
void ext2_read_blocks(struct ext2_fs *fs, void *ptr, blk_t block, blk_t num)
Can the default build be changed to include -W in addition to -Wall?
It show quite a lot of signed/unsigned issues, and I suspect it is
better to expose those to more people. I suggest adding code like
this to configure.in just before the "dnl Checks for libraries." line.
if eval "test x$GCC = xyes"; then
CFLAGS="$CFLAGS -W -Wall"
fi
Friendly,
--
Petter Reinholdtsen
|
|
From: Petter R. <pe...@hu...> - 2006-03-16 06:31:02
|
[Coywolf Qi Hunt] >> #354025: ext2resize: ex2resize segfaults on ext3 > > I think I've fixed this one in the CVS. But it's not fully fixed yet > with stride I'm afraid. Ah, nice. I try to get it from the sourceforge CVS, but am unable to reach the pserver service, and viewcvs seem to be down as well. Can anyone send me the patch by email? > > #328691: ext2resize: Wrong version number in output > > Fixed. Great. Btw, is this a good place to post patches? I found a few patches in Debian relative to version 1.1.19, and suspect they should be applied upstream as well. No way to check if they already made it into the CVS, as described above. I made the current debian patches available from <URL:http://developer.skolelinux.no/~pere/debian/ext2resize-debian/>, and the fedora patches available from <URL:http://developer.skolelinux.no/~pere/debian/e2fsprogs-fedora/>. Please have a look and include the ones that seem good to the next release of ext2resize. :) Is a new release of ext2resize planned in the near future? |
|
From: Coywolf Qi H. <co...@gm...> - 2006-03-16 05:39:12
|
2006/3/15, Petter Reinholdtsen <pe...@hu...>: > > Hi > > On Debian, there are a few bug reports related to ext2resize. The > complete list and details are available from > <URL:http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=3Dext2resize>. > Here is a summary of the ones I believe are unrelated to the debian > packaging, and might be present in all versions of ext2resize: > > #285257: ext2resize - invalid superblock on BE machines > > Claims that offline resizing fails/corrupts the file system on big > endian machines. > > #348778: ext2prepare corrupts the file system > > Claims running ext2prepare on an error-free file system make fsck > start complaining, and fear data loss and corrupt file system. > fsck log included. > > #354025: ext2resize: ex2resize segfaults on ext3 I think I've fixed this one in the CVS. But it's not fully fixed yet with stride I'm afraid. > > #328691: ext2resize: Wrong version number in output Fixed. > > Well, the title says it all for both of these. > > Are the bugs reported well known and fixed in later versions of > ext2resize? -- Coywolf Qi Hunt |
|
From: Petter R. <pe...@hu...> - 2006-03-15 12:43:05
|
[Petter Reinholdtsen] > Are the bugs reported well known and fixed in later versions of > ext2resize? I had a look at the fedora version of ext2resize (part of the e2fsprogs package), and found several patches which seem to be missing from the upstream version: ext2resize-1.1.17.tar.bz2 ext2resize-byteorder.patch ext2resize-canonicalise.patch ext2resize-compiler-warning-fixes.patch ext2resize-cvs-20040419.patch ext2resize-gcc34-fixes.patch ext2resize-nofallback.patch ext2resize-nowrite.patch ext2resize-printf-format-fixes.patch At least the byteorder patch seem to be relevant for the bug list I mentioned. I used <URL:ftp://ftp.uio.no/linux/Fedora/core/4/SRPMS/e2fsprogs-1.37-4.src.rpm>, not sure if that is the latest fedora version. |
|
From: Petter R. <pe...@hu...> - 2006-03-15 12:20:56
|
Hi On Debian, there are a few bug reports related to ext2resize. The complete list and details are available from <URL:http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=ext2resize>. Here is a summary of the ones I believe are unrelated to the debian packaging, and might be present in all versions of ext2resize: #285257: ext2resize - invalid superblock on BE machines Claims that offline resizing fails/corrupts the file system on big endian machines. #348778: ext2prepare corrupts the file system Claims running ext2prepare on an error-free file system make fsck start complaining, and fear data loss and corrupt file system. fsck log included. #354025: ext2resize: ex2resize segfaults on ext3 #328691: ext2resize: Wrong version number in output Well, the title says it all for both of these. Are the bugs reported well known and fixed in later versions of ext2resize? Please CC me on replies, as I am not on this list. Friendly, -- Petter Reinholdtsen |
|
From: Coywolf Qi H. <co...@gm...> - 2006-02-19 01:49:13
|
2006/2/15, Andreas Dilger <ad...@cl...>: > On Feb 13, 2006 17:04 +0100, Cristina Tanzi Tolenti wrote: > > on Fedora Core 1 (kernel 2.4.22-1.2199.5.legacy.nptl) I would like to > > resize my root partition, I use lvm. > > > > [root@theta root]# ext2online -d -v /dev/Volume00/LogVol00 > > group 2 inode table has offset 2, not 4 > [snip] > > group 78 inode table has offset 2, not 4 > > ext2online: group 0, block 2 not reserved > > > > ext2online: unable to resize /dev/Volume00/LogVol00 > > This means that you are trying to resize your partition past a 16GB > boundary, and that is not possible without an offline preparation step. > > > I don't patched the kernel (I don't understand how, excuse me for my > > ignorance) > > Also, if you haven't patched the kernel then online resizing won't work. > The online resizing is part of the 2.6.9-RHEL4 and 2.6.12+ kernels. 2.6.10+ -- Coywolf Qi Hunt |
|
From: Andreas D. <ad...@cl...> - 2006-02-15 07:35:57
|
On Feb 13, 2006 17:04 +0100, Cristina Tanzi Tolenti wrote: > on Fedora Core 1 (kernel 2.4.22-1.2199.5.legacy.nptl) I would like to > resize my root partition, I use lvm. > > [root@theta root]# ext2online -d -v /dev/Volume00/LogVol00 > group 2 inode table has offset 2, not 4 [snip] > group 78 inode table has offset 2, not 4 > ext2online: group 0, block 2 not reserved > > ext2online: unable to resize /dev/Volume00/LogVol00 This means that you are trying to resize your partition past a 16GB boundary, and that is not possible without an offline preparation step. > I don't patched the kernel (I don't understand how, excuse me for my > ignorance) Also, if you haven't patched the kernel then online resizing won't work. The online resizing is part of the 2.6.9-RHEL4 and 2.6.12+ kernels. You likely need to boot to a rescue CD and then do an offline resize with ext2resize or resize2fs. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. |
|
From: Coywolf Qi H. <co...@gm...> - 2006-02-14 05:39:56
|
2006/2/14, Cristina Tanzi Tolenti <cri...@pr...emona.= it>: > Hi, > > on Fedora Core 1 (kernel 2.4.22-1.2199.5.legacy.nptl) I would like to > resize my root partition, I use lvm. > > I have this error: > > [root@theta root]# ext2online -d -v /dev/Volume00/LogVol00 > group 2 inode table has offset 2, not 4 ... > group 78 inode table has offset 2, not 4 > ext2online: group 0, block 2 not reserved > > ext2online: unable to resize /dev/Volume00/LogVol00 > > I don't patched the kernel (I don't understand how, excuse me for my > ignorance) > > Help me, please!! Old vanilla kernels doesn't support online resize. The kernel patch for online resize was merged in 2.6 days. So use a newer kernel, like the comming 2.6.16. -- Coywolf Qi Hunt |
|
From: Cristina T. T. <cri...@pr...> - 2006-02-13 16:04:37
|
Hi, on Fedora Core 1 (kernel 2.4.22-1.2199.5.legacy.nptl) I would like to resize my root partition, I use lvm. I have this error: [root@theta root]# ext2online -d -v /dev/Volume00/LogVol00 group 2 inode table has offset 2, not 4 group 4 inode table has offset 2, not 4 group 6 inode table has offset 2, not 4 group 8 inode table has offset 2, not 4 group 10 inode table has offset 2, not 4 group 11 inode table has offset 2, not 4 group 12 inode table has offset 2, not 4 group 13 inode table has offset 2, not 4 group 14 inode table has offset 2, not 4 group 15 inode table has offset 2, not 4 group 16 inode table has offset 2, not 4 group 17 inode table has offset 2, not 4 group 18 inode table has offset 2, not 4 group 19 inode table has offset 2, not 4 group 20 inode table has offset 2, not 4 group 21 inode table has offset 2, not 4 group 22 inode table has offset 2, not 4 group 23 inode table has offset 2, not 4 group 24 inode table has offset 2, not 4 group 26 inode table has offset 2, not 4 group 28 inode table has offset 2, not 4 group 29 inode table has offset 2, not 4 group 30 inode table has offset 2, not 4 group 31 inode table has offset 2, not 4 group 32 inode table has offset 2, not 4 group 33 inode table has offset 2, not 4 group 34 inode table has offset 2, not 4 group 35 inode table has offset 2, not 4 group 36 inode table has offset 2, not 4 group 37 inode table has offset 2, not 4 group 38 inode table has offset 2, not 4 group 39 inode table has offset 2, not 4 group 40 inode table has offset 2, not 4 group 41 inode table has offset 2, not 4 group 42 inode table has offset 2, not 4 group 43 inode table has offset 2, not 4 group 44 inode table has offset 2, not 4 group 45 inode table has offset 2, not 4 group 46 inode table has offset 2, not 4 group 47 inode table has offset 2, not 4 group 48 inode table has offset 2, not 4 group 50 inode table has offset 2, not 4 group 51 inode table has offset 2, not 4 group 52 inode table has offset 2, not 4 group 53 inode table has offset 2, not 4 group 54 inode table has offset 2, not 4 group 55 inode table has offset 2, not 4 group 56 inode table has offset 2, not 4 group 57 inode table has offset 2, not 4 group 58 inode table has offset 2, not 4 group 59 inode table has offset 2, not 4 group 60 inode table has offset 2, not 4 group 61 inode table has offset 2, not 4 group 62 inode table has offset 2, not 4 group 63 inode table has offset 2, not 4 group 64 inode table has offset 2, not 4 group 65 inode table has offset 2, not 4 group 66 inode table has offset 2, not 4 group 67 inode table has offset 2, not 4 group 68 inode table has offset 2, not 4 group 69 inode table has offset 2, not 4 group 70 inode table has offset 2, not 4 group 71 inode table has offset 2, not 4 group 72 inode table has offset 2, not 4 group 73 inode table has offset 2, not 4 group 74 inode table has offset 2, not 4 group 75 inode table has offset 2, not 4 group 76 inode table has offset 2, not 4 group 77 inode table has offset 2, not 4 group 78 inode table has offset 2, not 4 ext2online: group 0, block 2 not reserved ext2online: unable to resize /dev/Volume00/LogVol00 I don't patched the kernel (I don't understand how, excuse me for my ignorance) Help me, please!! -- ------------------------------------------------- Cristina Tanzi Tolenti CED - Provincia di Cremona C.so V.Emanuele II, 17 - 26100 Cremona tel. 0372/406362 e-mail cri...@pr... ------------------------------------------------- |
|
From: Andreas D. <ad...@cl...> - 2005-12-22 23:20:15
|
On Dec 22, 2005 17:39 -0500, Soon Wong wrote:
> here's what syslog has:
>
> Dec 22 22:36:19 ppstest13 kernel: ioctl32(ext2online:3175): Unknown cmd
> fd(5) cmd(80046607){00} arg(ffffe80c) on /
This indicates that there is some issue in the 64/32 bit ioctl compatibility
code. This means that the e2fsprogs need to be rebuilt with 64-bit support,
or see if the ioctl32() handler is already fixed in a newer kernel (I recall
work being done for the ext3 ioctl code).
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
|
|
From: Coywolf Qi H. <co...@gm...> - 2005-12-21 08:45:19
|
2005/12/21, Coywolf Qi Hunt <co...@gm...>: > Hello, > > In ext2.c::ext2_block_iterate(), there is "int count"; but i_blocks is > u32. count overflows when (i_blocks >=3D 1 << 31). I'd fix count to u64. > Comments? Ignore it. No problem, no overflow for now, since we don't handle triple-indirect blocks. > > > -- coywolf > |
|
From: Coywolf Qi H. <co...@gm...> - 2005-12-21 03:04:58
|
Hello, In ext2.c::ext2_block_iterate(), there is "int count"; but i_blocks is u32. count overflows when (i_blocks >=3D 1 << 31). I'd fix count to u64. Comments? -- coywolf |
|
From: Jacques \(TS\) D. <Jac...@st...> - 2005-12-20 14:55:39
|
Hi, If the list is so quiet I hope it is because the filesystem is stable=20 -----Original Message----- From: ext...@li... [mailto:ext...@li...]On Behalf Of ext...@li... Sent: 19 d=E9cembre, 2005 23:24 To: ext...@li... Subject: ext2resize-devel digest, Vol 1 #97 - 1 msg Send ext2resize-devel mailing list submissions to ext...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/ext2resize-devel or, via email, send a message with subject or body 'help' to ext...@li... You can reach the person managing the list at ext...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of ext2resize-devel digest..." Today's Topics: 1. greetings and some cvs commits (Coywolf Qi Hunt) --__--__-- Message: 1 Date: Mon, 19 Dec 2005 13:56:00 +0800 From: Coywolf Qi Hunt <co...@gm...> To: ext...@li... Cc: ad...@us... Subject: [ext2resize] greetings and some cvs commits Hello all, This list seems so quiet. I've just joined you, thanks to Andreas = Dilger. buytenh seems not responding. And there're also Stephen C. Tweedie and Robert Walsh. I think you are all on this mailing list and also cvs commit mailing list, no? I've done some commits and you should have received notice mails. They are: Makefile and src/Makefile, doc/Makefile are removed from the cvs = repository=3D . BLKGETSIZE64 re-fixed. get over 2TB fix, 2TB: 12+29=3D3D41 ext2resize usage fix If I made any mistakes, _complain_ _loudly_ please. (btw, adilger, I can't close bug reports so I just ignored them.) -- Coywolf --__--__-- _______________________________________________ ext2resize-devel mailing list ext...@li... https://lists.sourceforge.net/lists/listinfo/ext2resize-devel End of ext2resize-devel Digest |
|
From: Coywolf Qi H. <co...@gm...> - 2005-12-19 05:56:04
|
Hello all, This list seems so quiet. I've just joined you, thanks to Andreas Dilger. buytenh seems not responding. And there're also Stephen C. Tweedie and Robert Walsh. I think you are all on this mailing list and also cvs commit mailing list, no? I've done some commits and you should have received notice mails. They are: Makefile and src/Makefile, doc/Makefile are removed from the cvs repository= . BLKGETSIZE64 re-fixed. get over 2TB fix, 2TB: 12+29=3D41 ext2resize usage fix If I made any mistakes, _complain_ _loudly_ please. (btw, adilger, I can't close bug reports so I just ignored them.) -- Coywolf |
|
From: Andreas D. <ad...@cl...> - 2005-09-06 06:32:04
|
On Sep 05, 2005 23:12 +0100, Richard J Moore wrote: > I have used ext3resize to shrink /dev/hda2 from 55GB to 9GB, but the > partition table has not been updated and so the free space is not > accessible. > If I run: ext2resize /dev/hda2 9GB > a second time I am told that the size is already 9GB. If I reboot my system > and dump the partition table under fdisk the size is unaltered at 55GB. > If I run KDiskFree it report 9.2GB as the partition size. > The version of ext2resize I am using is 1.1.18 and I'm running having > booted the Fedora core 4 rescue disc. > > Anyone have any ideas on how to get the partition table updated? ext2resize does not do anything to the partition tables itself. It is intented for use in environments with LVM or RAID systems which themselves allow devices to be resized. If you have already resized the filesystem down, then you can manually edit the partition table yourself to split hda2 into two separate partitions (be aware that this will rename your other partitions). Alternately, you can use a tool like GNU parted which also handles the DOS partition part of filesystem resizing. Cheers, Andreas -- Andreas Dilger |
|
From: Brian J. M. <br...@in...> - 2005-09-06 00:59:47
|
On Mon, 2005-09-05 at 23:12 +0100, Richard J Moore wrote: >=20 >=20 >=20 > I have used ext3resize to shrink /dev/hda2 from 55GB to 9GB, but the > partition table has not been updated and so the free space is not > accessible. > If I run: ext2resize /dev/hda2 9GB > a second time I am told that the size is already 9GB. If I reboot my syst= em > and dump the partition table under fdisk the size is unaltered at 55GB. > If I run KDiskFree it report 9.2GB as the partition size. > The version of ext2resize I am using is 1.1.18 and I'm running having > booted the Fedora core 4 rescue disc. >=20 > Anyone have any ideas on how to get the partition table updated? ext2resize only resizes the filesystem on a device. it does not resize the device (partition in your case) itself. you need to use another tool to do that. you could use something like parted, or even cfdisk or fdisk. my recommendation would be to make the partition slightly (but most definitely -- don't try to guess and be too close) larger than you have resized your filesystem to and then resize it again not specifying a size. that will cause the filesystem to be slightly expanded to the actual size of the partition. good luck. and it goes without saying, always make sure you have backups before you start mucking with resizing disks and repartitioning and so forth. b. --=20 My other computer is your Microsoft Windows server. Brian J. Murrell |
5 messages has been excluded from this view by a project administrator.
