ext2resize-devel

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

[Petter R. <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=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

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

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

[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.

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

[Coywolf Qi H. <co...@gm...>]

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

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

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

[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?

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

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

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.

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

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

[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.

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.