Thread: [ext2resize] bug in ext2resize 1.1.14
Status: Inactive
Brought to you by:
adilger
Menu
▾
▴
ext2resize-devel
|
From: Dieter S. <st...@co...> - 2000-09-11 21:03:51
|
while trying to resize my 137Gb partition I got a core.
After analyzing the problem I found a serious bug in
ext2resize 1.1.14 when shrinking a huge partition:
I found a parameter "ext2_max_groups = 1024" from tune.c,
which is capable to handle about 8GB. Although it is adapted
to handle greater partitions if needed by ext2resize.c:main(),
the calculated size needed, however is taken from the (possibly
smaller) size requested, not from the actual size if the file system.
Thus I got a segfault in ext2_determine_itoffset().
Maybe there is a newer version meanwhile, with this problem
resolved; but I just escaped to kill may 137Gb :-( and
I did not find any hint about such a bug anywhere.
I helped me by drastically increasing the parameters from
tune.c for my needs, but I think there should be a better
solution for that.
regards, Dieter.
--
Dieter Stüken, con terra GmbH, Münster
st...@co... st...@qg...
http://www.conterra.de/ http://qgp.uni-muenster.de/~stueken
(0)251-980-2027 (0)251-83-334974
|
|
From: Andrew C. <cl...@gn...> - 2000-09-12 09:00:51
|
Dieter Stueken wrote: > > while trying to resize my 137Gb partition I got a core. > After analyzing the problem I found a serious bug in > ext2resize 1.1.14 when shrinking a huge partition: > > I found a parameter "ext2_max_groups = 1024" from tune.c, > which is capable to handle about 8GB. Although it is adapted > to handle greater partitions if needed by ext2resize.c:main(), > the calculated size needed, however is taken from the (possibly > smaller) size requested, not from the actual size if the file system. > > Thus I got a segfault in ext2_determine_itoffset(). > > Maybe there is a newer version meanwhile, with this problem > resolved; but I just escaped to kill may 137Gb :-( and > I did not find any hint about such a bug anywhere. > > I helped me by drastically increasing the parameters from > tune.c for my needs, but I think there should be a better > solution for that. GNU Parted (www.gnu.org/software/parted) fixes this problem (it dynamically allocates buffers according to the number of groups) GNU Parted was forked off from ext2resize. We were going to keep things in sync, but Lennert seems to be short on time to apply changes I make... Andrew Clausen |
|
From: Andreas D. <ad...@tu...> - 2000-09-12 19:17:46
|
Dieter writes:
> I found a parameter "ext2_max_groups = 1024" from tune.c,
> which is capable to handle about 8GB.
Actually, for such a large filesystem, you are probably using 4k blocks,
so 1024 groups = 32GB... Still too small for your 137GB filesystem.
> Although it is adapted
> to handle greater partitions if needed by ext2resize.c:main(),
> the calculated size needed, however is taken from the (possibly
> smaller) size requested, not from the actual size if the file system.
I will have a look... It shouldn't be too much work to fix this problem,
and it will be a good reason to release my other updates to ext2resize.
Andrew writes:
> GNU Parted was forked off from ext2resize. We were going to keep
> things in sync, but Lennert seems to be short on time to apply
> changes I make...
If you think it would be useful, I can make you an administrator of
the ext2resize project at sourceforge, or you could at least send
patches to the ext2resize-devel mailing list...
It seems relevant to ask if the ext2 support in parted can work without
doing any partition resizing (e.g. on LVM or RAID devices that don't have
a partition)?
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
|
|
From: Andrew C. <cl...@gn...> - 2000-09-12 20:31:58
|
Andreas Dilger wrote: > Andrew writes: > > GNU Parted was forked off from ext2resize. We were going to keep > > things in sync, but Lennert seems to be short on time to apply > > changes I make... > > If you think it would be useful, I can make you an administrator of > the ext2resize project at sourceforge, or you could at least send > patches to the ext2resize-devel mailing list... I don't really have time to do both... I'm already having to heavily prioritize what I do with Parted. I'm not sure what the benefits of maintaining ext2resize separately from Parted are. I think we should try and put all ext2resize functionality into Parted. One problem we might have is Parted's interface is very simple (read: not very expressive). Are there any parameters expert users might want, that Parted can't interface/ > It seems relevant to ask if the ext2 support in parted can work without > doing any partition resizing (e.g. on LVM or RAID devices that don't have > a partition)? It can. 1.3.x has a hack - the "loop" disk label. Best demonstrated: satisfactory:/home/parted/parted-dev/parted# ./parted /dev/hda GNU Parted 1.3.2 (parted) p Disk geometry for /dev/hda: 0.000-2445.679 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 1 0.031 945.000 primary FAT boot 2 945.000 2358.562 primary ext2 3 2358.562 2445.187 primary linux-swap (parted) q satisfactory:/home/parted/parted-dev/parted# ./parted /dev/hda2 Warning: Device /dev/hda2 is neither a SCSI nor IDE drive. GNU Parted 1.3.2 Using /dev/hda2 (parted) p Disk geometry for /dev/hda2: 0.000-1413.562 megabytes Disk label type: loop Minor Start End Filesystem Flags 1 0.000 1413.562 ext2 Andrew Clausen |
|
From: Andreas D. <ad...@tu...> - 2000-09-12 22:06:30
|
Andrew writes:
> I'm not sure what the benefits of maintaining ext2resize separately
> from Parted are. I think we should try and put all ext2resize
> functionality into Parted. One problem we might have is Parted's
> interface is very simple (read: not very expressive). Are there
> any parameters expert users might want, that Parted can't interface?
The real question is whether you can do a filesystem resize without
accessing the interface (i.e. command-line only)? This is important
for tools like e2fsadm or lvmadm. There are very few options to the
ext2resize programs - device, new size (optional), verbose, debug.
> satisfactory:/home/parted/parted-dev/parted# ./parted /dev/hda
> GNU Parted 1.3.2
> (parted) p
> Disk geometry for /dev/hda: 0.000-2445.679 megabytes
> Disk label type: msdos
> Minor Start End Type Filesystem Flags
> 1 0.031 945.000 primary FAT boot
> 2 945.000 2358.562 primary ext2
> 3 2358.562 2445.187 primary linux-swap
> (parted) q
It looks like parted is a complete replacement for fdisk/cfdisk.
Is that correct? Can you use it to simply manipulate partition
tables without resizing the fs, if desired?
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
|
|
From: Andrew C. <cl...@gn...> - 2000-09-12 23:01:54
|
Andreas Dilger wrote: > The real question is whether you can do a filesystem resize without > accessing the interface (i.e. command-line only)? This is important > for tools like e2fsadm or lvmadm. There are very few options to the > ext2resize programs - device, new size (optional), verbose, debug. You can issue parted commands on the command line. There is also a script mode, which means default action is taken on exceptions (errors). > > satisfactory:/home/parted/parted-dev/parted# ./parted /dev/hda > > GNU Parted 1.3.2 > > (parted) p > > Disk geometry for /dev/hda: 0.000-2445.679 megabytes > > Disk label type: msdos > > Minor Start End Type Filesystem Flags > > 1 0.031 945.000 primary FAT boot > > 2 945.000 2358.562 primary ext2 > > 3 2358.562 2445.187 primary linux-swap > > (parted) q > > It looks like parted is a complete replacement for fdisk/cfdisk. > Is that correct? Can you use it to simply manipulate partition > tables without resizing the fs, if desired? Yes and yes :-) It's more high level, than fdisk, though. Which may have draw-backs, since many disk labels how their own low-level Issues (or should I say, ISSUES). So, having fdisk/pdisk or whatever around may still be useful for some problems, but most people will use Parted :-) Of course, we're trying to make Parted deal with all the Issues, but that would require better communication with boot loaders. One thing (on the extremely long TODO list) is to write a libbootload, that allows programs like Parted to manipulate boot loaders. This is something that would be useful for LVM, too. One important point: the current command-line front end is JUST a front end to libparted. There are lots of other possibilities, like automatic partitioning, disk imaging, etc. I recommend you have a look at the API :-) Andrew Clausen |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X