ext2resize-devel Mailing List for GNU ext2resize (Page 10)
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: Shea A M. <sno...@ho...> - 2001-04-28 09:40:01
|
I am trying to use ext2resize to shrink my hda3. When I installed Storm
Linux 2 yrs ago, I chose to have hda1 2GB (/), hda2 (swap) 126MB, and
hda3 (/home)17.7GB.
now hda3 is no where near being full, in fact less than a GB is used. I
want to make it about 10GB, and then add a new partition.
as root :
umount /home
ext2resize -v /dev/hda3 10g
looks like something is happening, as ext2resize gives output.
when I go into fdisk, I see that nothing has changed. I tried changing
10g to 6g or 1000000 or whatever, but nothing changes in fdisk. I have
tried dos fdisk and the fdisk which comes with potatoe.
I get this message when I start up linux's fdisk:
"The number of cylinders for this disk is set to 2482.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)"
should I worry about that???
when I run 'parted' I get
Warning: The operating system thinks the geometry on /dev/hda is
2482/255/63.
You should check that this matches the BIOS geometry before using this
program.
should I worry about this???
Please help me, as I has assumed this would be a simple operation.
--
Shea Martin
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Elbows out...
...stick on the ice! \_.
|
|
From: Dave W. <da...@xs...> - 2001-03-23 21:52:07
|
On 22 March, 2001 at 21:25:33 +1100, Andrew Clausen <cl...@gn...> wrote: > > GNU Parted's ext2 resizer (which forked from ext2resize) supports > big-endian machines. It is stable, i.e. has gone through a > stable release, and has been available as such for about half a year. I downloaded the latest source (1.4.10) but it doesn't seem to recognize my partitions, even on a normal scsi drive (no LVM). See the difference between the parted output and good old fdisk. Am I missing something? (parted) print Disk geometry for /dev/sda: 0.000-8637.337 megabytes Disk label type: loop Minor Start End Filesystem Flags 1 0.000 8637.337 ext2 (parted) Command (m for help): p Disk /dev/sda (Sun disk label): 27 heads, 133 sectors, 4924 cylinders Units = cylinders of 3591 * 512 bytes Device Flag Start End Blocks Id System /dev/sda1 0 1426 2560316+ 83 Linux native /dev/sda2 1426 2852 2560383 83 Linux native /dev/sda3 0 4924 8841042 5 Whole disk /dev/sda4 2852 3423 1025230+ 83 Linux native /dev/sda5 3423 3716 526081+ 82 Linux swap /dev/sda6 3716 3774 104139 83 Linux native /dev/sda7 3774 3832 104139 83 Linux native Command (m for help): -Dave -- Dave Wapstra da...@xs... |
|
From: Andreas D. <ad...@tu...> - 2001-03-23 06:08:33
|
Dave Wapstra writes:
> On 21 March, 2001 at 14:14:58 -0700, Andreas Dilger <ad...@tu...> wrote:
> Well, maybe I should say Volume Group instead of filesystem. Here's what I did:
>
> Created logical volume, made ext2 filesytem, extended logical volume)
>
> [/root]# pvscan
> pvscan -- reading all physical volumes (this may take a while...)
> pvscan -- ACTIVE PV "/dev/sdb" of VG "ftp" [8.43 GB / 0 free]
> pvscan -- ACTIVE PV "/dev/sdc" of VG "ftp" [8.43 GB / 0 free]
> pvscan -- ACTIVE PV "/dev/sdd" of VG "ftp" [8.43 GB / 0 free]
> pvscan -- ACTIVE PV "/dev/sde" of VG "ftp" [8.43 GB / 72 MB free]
> pvscan -- total: 4 [33.74 GB] / in use: 4 [33.74 GB] / in no VG: 0 [0]
>
> [/root]# ext2resize /dev/ftp/lvol1 33g
> ext2resize v1.1.15 - 2000/08/08 for EXT2FS 0.5b
> ext2resize: ext2_open: invalid superblock
> ext2resize: can't open /dev/ftp/lvol1
> [/root]# pvscan
> pvscan -- reading all physical volumes (this may take a while...)
> pvscan -- ACTIVE PV "/dev/sdb" is associated to an unknown VG (run vgscan)
> pvscan -- ACTIVE PV "/dev/sdc" is associated to an unknown VG (run vgscan)
> pvscan -- ACTIVE PV "/dev/sdd" is associated to an unknown VG (run vgscan)
> pvscan -- ACTIVE PV "/dev/sde" is associated to an unknown VG (run vgscan)
> pvscan -- total: 4 [33.74 GB] / in use: 4 [33.74 GB] / in no VG: 0 [0]
>
> Note: this output is edited, but does show the problem. After this, I get
>
> vgcreate -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
>
> and have to do dd if=/dev/zero of=/dev/sd<x> to clear all the tables
> and do a reboot to clean up the VGDA in the kernel
It may very well be that this is an LVM problem. As you can see, ext2resize
doesn't even succeed in opening the filesystem, so I don't see how it can
corrupt the LVM (actually, it is impossible that writing into /dev/ftp/lvol1
would corrupt LVM metadata (without an LVM bug), because the LVM metadata
is outside the LV itself.
I see you are using Ultrasparc - you need basically todays -ac kernel (or
the Ultrasparc patch from LVM CVS) in order to have LVM work properly on
Ultrasparc. You also need current CVS LVM kernel patches to have anything
resembling a useful LVM system (I also do a lot of LVM development). Even
so, I don't think this has seen a lot of testing yet.
Please see if the above (omitted) steps cause LV corruption without any
ext2resize involved. Please post any findings to the LVM mailing list
lin...@li... (you need to subscribe first). It would be
useful to see what you have cut out of your process here.
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: Dave W. <da...@xs...> - 2001-03-22 19:54:44
|
On 21 March, 2001 at 14:14:58 -0700, Andreas Dilger <ad...@tu...> wrote: > > Dave Wapstra writes: > > After messing up the filesystem a couple of times, I finally noticed > > the little TODO list for ext2resize: > > I'm surprised you were even able to mess up the filesystem!!! It should > have failed when checking the EXT2_MAGIC in the superblock, because of > endian issues (at least that's what I assumed). I will have to ensure > that we refuse to do anything on big-endian machines until this works > properly. Well, maybe I should say Volume Group instead of filesystem. Here's what I did: Created logical volume, made ext2 filesytem, extended logical volume) [/root]# pvscan pvscan -- reading all physical volumes (this may take a while...) pvscan -- ACTIVE PV "/dev/sdb" of VG "ftp" [8.43 GB / 0 free] pvscan -- ACTIVE PV "/dev/sdc" of VG "ftp" [8.43 GB / 0 free] pvscan -- ACTIVE PV "/dev/sdd" of VG "ftp" [8.43 GB / 0 free] pvscan -- ACTIVE PV "/dev/sde" of VG "ftp" [8.43 GB / 72 MB free] pvscan -- total: 4 [33.74 GB] / in use: 4 [33.74 GB] / in no VG: 0 [0] [/root]# ext2resize /dev/ftp/lvol1 33g ext2resize v1.1.15 - 2000/08/08 for EXT2FS 0.5b ext2resize: ext2_open: invalid superblock ext2resize: can't open /dev/ftp/lvol1 [/root]# pvscan pvscan -- reading all physical volumes (this may take a while...) pvscan -- ACTIVE PV "/dev/sdb" is associated to an unknown VG (run vgscan) pvscan -- ACTIVE PV "/dev/sdc" is associated to an unknown VG (run vgscan) pvscan -- ACTIVE PV "/dev/sdd" is associated to an unknown VG (run vgscan) pvscan -- ACTIVE PV "/dev/sde" is associated to an unknown VG (run vgscan) pvscan -- total: 4 [33.74 GB] / in use: 4 [33.74 GB] / in no VG: 0 [0] Note: this output is edited, but does show the problem. After this, I get vgcreate -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan and have to do dd if=/dev/zero of=/dev/sd<x> to clear all the tables and do a reboot to clean up the VGDA in the kernel I'll give GNU parted a try. -Dave -- Dave Wapstra da...@xs... |
|
From: Andrew C. <cl...@gn...> - 2001-03-22 10:27:57
|
Dave Wapstra wrote: > I recently installed LVM on a Sun E450 and was experimenting with > ext2resize. After extending the logical volume, I extended my ext2 > filesystem, at least that was they idea. > > After messing up the filesystem a couple of times, I finally noticed > the little TODO list for ext2resize: > > misc todo > --------- > make it work on big-endian systems. GNU Parted's ext2 resizer (which forked from ext2resize) supports big-endian machines. It is stable, i.e. has gone through a stable release, and has been available as such for about half a year. ftp.gnu.org/gnu/parted Parted can't do online resizing. Also, you will probably want to read the section on LVM in the manual... Andrew Clausen |
|
From: Andreas D. <ad...@tu...> - 2001-03-21 21:15:07
|
Dave Wapstra writes:
> I recently installed LVM on a Sun E450 and was experimenting with
> ext2resize. After extending the logical volume, I extended my ext2
> filesystem, at least that was they idea.
>
> After messing up the filesystem a couple of times, I finally noticed
> the little TODO list for ext2resize:
>
> misc todo
> ---------
> make it work on big-endian systems.
I'm surprised you were even able to mess up the filesystem!!! It should
have failed when checking the EXT2_MAGIC in the superblock, because of
endian issues (at least that's what I assumed). I will have to ensure
that we refuse to do anything on big-endian machines until this works
properly.
> I would like to work on making ext2resize work on big-endian (specifically
> (ultra)sparc), but although I can hack a little C code, I have no idea
> where to start on making ext2resize big-endian compliant.
There are two ways to do this, and I'm not sure which is best:
1) leave the superblock and all on-disk data in little-endian format,
and convert to machine endianness as needed. This is done in the kernel,
but it may be because they are directly mapping on-disk data and have
no control over when it is written to disk.
2) Convert the superblock and all on-disk data to machine endianness when
it is read from disk. This would require new routines for read_super,
read_GDT, read_inode, etc. This is what's done in the e2fsprogs
libext2fs. There are a few cases (with data that isn't repeatedly
accessed, like directory entries) where it keeps the data little-endian.
It is worthwhile to hear from Andrew Clausen (parted author and user of
a divergent libext2resize) to see what he has done in this regard. We
could merge the endianness changes back into libext2resize.
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: Dave W. <da...@xs...> - 2001-03-21 19:48:27
|
Hi all, I recently installed LVM on a Sun E450 and was experimenting with ext2resize. After extending the logical volume, I extended my ext2 filesystem, at least that was they idea. After messing up the filesystem a couple of times, I finally noticed the little TODO list for ext2resize: misc todo --------- make it work on big-endian systems. Hmm.... not really supported yet. I would like to work on making ext2resize work on big-endian (specifically (ultra)sparc), but although I can hack a little C code, I have no idea where to start on making ext2resize big-endian compliant. Any pointers for starting to make this util work on big-endian are appreciated. -Dave -- Dave Wapstra da...@xs... |
|
From: Mrutyunjaya D. <mun...@re...> - 2000-12-07 08:38:06
|
Dear sir,
I want to subscribe into the mailing list.
Thanks & Regards,
M Dash.
_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com
Participate in crazy auctions at http://auctions.rediff.com/auctions/
|
|
From: Mrutyunjaya D. <mun...@re...> - 2000-12-07 08:37:48
|
Dear sir,
I want to subscribe into the mailing list.
_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com
Participate in crazy auctions at http://auctions.rediff.com/auctions/
|
|
From: Andreas D. <ad...@tu...> - 2000-11-30 17:08:40
|
Jan, you write:
> I got reproducible corruptions while doing the following:
>
> lvcreate -n test -L 100M vg1
> mke2fs -b 1024 /dev/vg1/test
> ext2prepare -v /dev/vg1/test 50G
> mount /dev/vg1/test /mnt/test/
>
> at the same time, do:
>
> cp -a /usr/src/linux /mnt/test/linux
> cp -a /mnt/test/linux /mnt/test/linux2
> cp -a /mnt/test/linux2 /mnt/test/linux3
> ...
>
> and
> e2fsadm -L+90M /dev/vg1/test
> e2fsadm -L+90M /dev/vg1/test
> ... whenever necessary
>
> The corrupted files contain blocks of other files or directory information
> on 1024k boundaries.
This sounds _very_ similar to the problems that people on linux-kernel
are having... They were getting duplicate blocks when copying lots of
files. Did you apply the one-line fix that moved the "head" initialization
inside the loop (this is an IDE problem)? Sorry, I don't recall the exact
patch, but a quick search of l-k should find it.
> Once I even got fs metadata corruptions, but data corruption seems to occur
> more often (but that may be caused by the amount of data vs. metadata)
>
> Kernel version is 2.4.0-test12-pre3 with current ext2-compat and online-ext2
> patches.
>
> Is this a known problem? I read on linux-kernel that there are some problems
> with 1k blocksized filesystems, but I did test it with the same configuration
> without resizing and got no corruptions.
I have never had problems while doing a resize. I sometimes run random
resizes while copying data into the filesystem and never see this. Most
of my testing is under 2.2, however.
In any case - if you follow through what the ext2online and kernel
patch really does, there is really nowhere that it could introduce
data corruption. The only parts of the disk it writes to are:
- block/inode bitmaps, inode table _after the end of the current filesystem_.
- _unused_ group descriptor entries. Even if it somehow (I don't know how
it would happen) wrote "old" data over the top of the current group
descriptors, the worst that would happen is "df" would be out a bit, and
you may get an ENOSPC error finding a free block in a group without any.
- reserved inode #7 (resize inode). Again, if it makes a mistake and
overwrites the whole block of inodes (can't _really_ happen) it would
only affect the first 8 inodes (first 32 on a 4k filesystem). For a 1k
filesystem, the only possibility would be the root inode.
So because of this, I _think_ it's the same kernel bug as others are having.
That, and the fact that nobody else has previously reported a bug like this.
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: Jan N. <ja...@go...> - 2000-11-30 12:42:23
|
Hello! I got reproducible corruptions while doing the following: lvcreate -n test -L 100M vg1 mke2fs -b 1024 /dev/vg1/test ext2prepare -v /dev/vg1/test 50G mount /dev/vg1/test /mnt/test/ at the same time, do: cp -a /usr/src/linux /mnt/test/linux cp -a /mnt/test/linux /mnt/test/linux2 cp -a /mnt/test/linux2 /mnt/test/linux3 ... and e2fsadm -L+90M /dev/vg1/test e2fsadm -L+90M /dev/vg1/test ... whenever necessary The corrupted files contain blocks of other files or directory information on 1024k boundaries. Once I even got fs metadata corruptions, but data corruption seems to occur more often (but that may be caused by the amount of data vs. metadata) Kernel version is 2.4.0-test12-pre3 with current ext2-compat and online-ext2 patches. Is this a known problem? I read on linux-kernel that there are some problems with 1k blocksized filesystems, but I did test it with the same configuration without resizing and got no corruptions. Jan |
|
From: Andreas D. <ad...@tu...> - 2000-11-27 22:55:56
|
Hello all, attached is an updated patch for online ext2 resizing with the latest 2.4 kernel (2.4.0-test11-pre7). It is not significantly different from the 2.2 kernel patch or the previous 2.3 kernel patch, with the exception of some changes to where the superblock lock is held. I've tested it some, but 2.4 kernels don't run well on my laptop, and my other systems are all running ext3 which doesn't work with 2.4 yet. Please report any problems to ext...@li.... The online-ext2-2.4.0.diff kernel patch needs to be applied AFTER the linux-2.4.0-test11-ext2compat.diff patch, which fixes some problems with the kernel trying to mount filesystems it doesn't understand. These patches are attached here, and the latest versions are also available from CVS for the ext2resize project at http://sourceforge.net/projects/ext2resize/ As with previous versions of online resizing, you need to have the user tools from the ext2resize package (also at sourceforge). The latest version of the user tools is 1.1.15. These tools only work on i386 systems right now. With the newest version of the LVM user tools, the e2fsadm tool will call ext2online if the filesystem is mounted when the LV is resized. Cheers, Andreas -- Andreas Dilger TurboLabs filesystem development |
|
From: Andreas D. <ad...@tu...> - 2000-11-08 17:02:53
|
Anders, you write:
> I'm using ext2resize and LVM under kernel 2.4.0-test10, and it works fine.
> But I would like the ext2online to work as well, and there is no patch for
> my kernel. I've tried to apply the most recent 2.3.x patch, but that didn't
> work.
Yes, unfortunately there have been a lot of changes to the ext2 code
between 2.3.99 and 2.4.0-test11, despite the small change in version
numbers. This is _despite_ Ted Ts'o, Alan Cox, and Linus telling me
that "ext2 is too important to change at this late stage in kernel
code freeze, please wait until 2.5" and the fact that the ext2online
code only is only used during mounting and when resize is done, unlike
the other filesystem corrupting changes in recent 2.4 kernels.
> Will there be a 2.4.0-patch available, or are there anything else I can do
> to make online size-changing work?
Yes, I think that the 2.4.0 ext2 changes have finally slowed down a bit
and I will begin working on a new 2.4 patch. Unfortunately, the locking
for ext2 has totally changed and I'm sure this will give me a lot of
grief. It's high on my to-do list, so it may even be available in the
next week or so, but since I haven't run a 2.4 kernel since 2.3.99, I
may have other problems to work out first.
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: Anders W. <an...@ba...> - 2000-11-08 08:38:26
|
I'm using ext2resize and LVM under kernel 2.4.0-test10, and it works fine. But I would like the ext2online to work as well, and there is no patch for my kernel. I've tried to apply the most recent 2.3.x patch, but that didn't work. Will there be a 2.4.0-patch available, or are there anything else I can do to make online size-changing work? -- -------------------------------------------- Anders Westrup <an...@ba...> http://taket.barbanet.com/~anders/ +46 46 184285 |
|
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 |
|
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 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 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 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: 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-06-17 21:15:52
|
Tobias Quinn wrote: > I'm having a slight problem understanding how ext2resize works, is it > not meant to rewrite the partition table as well as resize the actual > partition. Use GNU Parted. It's ext2 code is basically ext2resize, but it also writes out partition tables. ftp.gnu.org/gnu/parted BTW, there's a Parted boot disk image: ftp.gnu.org/gnu/parted/bootdisk Andrew Clausen |
|
From: Andreas D. <ad...@tu...> - 2000-06-17 20:44:51
|
Tobias, you write:
> I'm having a slight problem understanding how ext2resize works, is it
> not meant to rewrite the partition table as well as resize the actual
> partition. I am using it to upgrade a Linux Mandrake 7.0 disk to Linux
> Mandrake 7.1 so I want to increase the size of my / partition and
> decrease the size of the /home partition. So I thought I'd resize /home
> to be 2Gb smaller, then install Mandrake in the free space (a minimal
> install) so I can umount / and then resize the / partition to be +1Gb
> and then remove the new install of Mandrake, and increase /home by 1Gb.
> But, when I do an fdisk after resizing the /home partition it reports
> the partition is still using the same number of blocks on the drive
> which I think means I can't add a partition to do the new install. I
> suppose I could solve this by using a floppy version of linux but I
> can't seem to find one that runs with libc6 (Does anyone know of one? or
> how to compile ext2resize to work with libc5?).
You will need to resize the partition manually. Ext2resize really works
best with LVM, but failing that, you can shrink the filesystem and then
manually change the partitions with fdisk. You will have to make the
partition AT LEAST as big as the filesystem, so what you might do is
shrink the filesystem much smaller than needed, and then change the
partition with fdisk, and then grow the filesystem to fit the new partition.
NOTE - you cannot move the start of a filesystem with ext2resize - you can
only change the end of the filesystem. If you need to move the start, you
need to back up the filesystem, or move the data to a new partition that will
hold your filesystem, and then you can delete the old one.
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: Tobias Q. <tob...@bi...> - 2000-06-17 18:38:57
|
Hi, I'm having a slight problem understanding how ext2resize works, is it not meant to rewrite the partition table as well as resize the actual partition. I am using it to upgrade a Linux Mandrake 7.0 disk to Linux Mandrake 7.1 so I want to increase the size of my / partition and decrease the size of the /home partition. So I thought I'd resize /home to be 2Gb smaller, then install Mandrake in the free space (a minimal install) so I can umount / and then resize the / partition to be +1Gb and then remove the new install of Mandrake, and increase /home by 1Gb. But, when I do an fdisk after resizing the /home partition it reports the partition is still using the same number of blocks on the drive which I think means I can't add a partition to do the new install. I suppose I could solve this by using a floppy version of linux but I can't seem to find one that runs with libc6 (Does anyone know of one? or how to compile ext2resize to work with libc5?). Many thanks in advance, tobias. |
|
From: weafon <we...@ms...> - 2000-04-05 06:51:57
|
confirm 197627 |
|
From: Andreas D. <ad...@ho...> - 2000-03-31 04:20:21
|
Hello all, a new release of ext2resize is available, which should fix the problems with sparse superblocks, and missing configurations in the ext2online patch. It does not yet fix the problem with preparing or offline resizing a filesystem with the mke2fs RAID stride option, although I DID test this with ext2online, and it appears to work properly. However, this means you couldn't online resize a filesystem past the group block limit. If you have any problems with this release, can you please submit a bug report at sourceforge, rather than through private email, so that we can track it easier. You need to get a sourceforge login ID, and then go to: https://sourceforge.net/bugs/?func=addbug&group_id=3834 (or simply follow the "bug" URL from http://ext2resize.sourceforge.net/). Cheers, Andreas & Lennert -- 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 |
5 messages has been excluded from this view by a project administrator.
