This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Date: Mon, 29 Mar 2004 13:55:31 -0800 (PST)
From: John Greene <john@grumpet.net>
To: Balug-talk@balug.org
Subject: [Balug-talk] partition resizing
Does anyone know of a utility for resizing partitions that will save me
from having to re-install? I have googled around some, but I can't find
anything really useful.
This would be for an EXT3 filesystem (2 disks - RAID 1). I am hoping for
a "boot to a live cd and run foo" kind of solution, because reinstalling
wouldn't be _that_ painful.
===
Date: Mon, 29 Mar 2004 14:15:29 -0800
From: Jeffrey Siegal <jbs@quiotix.com>
To: Balug-talk@balug.org
Subject: Re: [Balug-talk] partition resizing
John Greene wrote:
> Does anyone know of a utility for resizing partitions that will save me
> from having to re-install? I have googled around some, but I can't find
> anything really useful.
>
> This would be for an EXT3 filesystem (2 disks - RAID 1). I am hoping for
> a "boot to a live cd and run foo" kind of solution, because reinstalling
> wouldn't be _that_ painful.
Parted can do this: http://www.gnu.org/software/parted/parted.html
Also, resize2fs can do it.
Most rescue boot CDs should have one or both of these
===
Date: Mon, 29 Mar 2004 16:36:21 -0800 (PST)
From: John Greene <john@grumpet.net>
To: Balug-talk@balug.org
Subject: Re: [Balug-talk] partition resizing
Jeffrey Siegal wrote:
> John Greene wrote:
> > Does anyone know of a utility for resizing partitions that will save me
> > from having to re-install? I have googled around some, but I can't find
> > anything really useful.
> >
> > This would be for an EXT3 filesystem (2 disks - RAID 1). I am hoping for
> > a "boot to a live cd and run foo" kind of solution, because reinstalling
> > wouldn't be _that_ painful.
> >
> > Thanks in advance!
>
> Parted can do this: http://www.gnu.org/software/parted/parted.html
>
> Also, resize2fs can do it.
>
> Most rescue boot CDs should have one or both of these
>
Thank you Jeffrey. I'm not sure resize2fs will work for me: (from the
resize2fs man page) "The resize2fs program does not manipulate the size of
partitions."
I'll have a deeper look at the parted documentation.
====
Subject: Re: [Balug-talk] partition resizing
From: Ivan Poddubny <ivan@inviosoftware.com>
To: John Greene <john@grumpet.net>
Date: Mon, 29 Mar 2004 16:48:02 -0800
John Greene wrote:
> Jeffrey Siegal wrote:
> > John Greene wrote:
> > > Does anyone know of a utility for resizing partitions that will save me
> > > from having to re-install? I have googled around some, but I can't find
> > > anything really useful.
> > >
> > > This would be for an EXT3 filesystem (2 disks - RAID 1). I am hoping for
> > > a "boot to a live cd and run foo" kind of solution, because reinstalling
> > > wouldn't be _that_ painful.
> > >
> > > Thanks in advance!
> >
> > Parted can do this: http://www.gnu.org/software/parted/parted.html
> >
> > Also, resize2fs can do it.
> >
> > Most rescue boot CDs should have one or both of these
> Thank you Jeffrey. I'm not sure resize2fs will work for me: (from the
> resize2fs man page) "The resize2fs program does not manipulate the size of
> partitions."
>
> I'll have a deeper look at the parted documentation.
PartitionMagic. but this will cost you about $70
===
Date: Mon, 29 Mar 2004 16:52:50 -0800
From: Jeffrey Siegal <jbs@quiotix.com>
To: Balug-talk@balug.org
Subject: Re: [Balug-talk] partition resizing
John Greene wrote:
> Jeffrey Siegal wrote:
>>John Greene wrote:
>>>Does anyone know of a utility for resizing partitions that will save me
>>>from having to re-install? I have googled around some, but I can't find
>>>anything really useful.
>>>
>>>This would be for an EXT3 filesystem (2 disks - RAID 1). I am hoping for
>>>a "boot to a live cd and run foo" kind of solution, because reinstalling
>>>wouldn't be _that_ painful.
>>>
>>>Thanks in advance!
>>
>>Parted can do this: http://www.gnu.org/software/parted/parted.html
>>
>>Also, resize2fs can do it.
>>
>>Most rescue boot CDs should have one or both of these
> Thank you Jeffrey. I'm not sure resize2fs will work for me: (from the
> resize2fs man page) "The resize2fs program does not manipulate the size of
> partitions."
I think you misunderstood. What you do is use fdisk to change the size
of the partition first (but leave the starting position of the partition
alone) and then use resize2fs to modify the file system to fill the new
size of the partition.
===
Date: Mon, 29 Mar 2004 17:21:57 -0800
From: David Stillion <dave@zone64.net>
To: Balug-talk@balug.org
Subject: Re: [Balug-talk] partition resizing
Cc:
Ivan Poddubny wrote:
>John Greene wrote:
>>Jeffrey Siegal wrote:
>>>John Greene wrote:
>>>>Does anyone know of a utility for resizing partitions that will save me
>>>>from having to re-install? I have googled around some, but I can't find
>>>>anything really useful.
>>>>
>>>>This would be for an EXT3 filesystem (2 disks - RAID 1). I am hoping for
>>>>a "boot to a live cd and run foo" kind of solution, because reinstalling
>>>>wouldn't be _that_ painful.
>>>Parted can do this: http://www.gnu.org/software/parted/parted.html
>>>
>>>Also, resize2fs can do it.
>>>
>>>Most rescue boot CDs should have one or both of these
>>Thank you Jeffrey. I'm not sure resize2fs will work for me: (from the
>>resize2fs man page) "The resize2fs program does not manipulate the size of
>>partitions."
>>
>>I'll have a deeper look at the parted documentation.
>PartitionMagic. but this will cost you about $70
I did similar research a few months ago and came up with a product call
Paragon Hard Disk Manager. This is a collection
of utilities to do a variety of things and you may not want the whole
package. The entire package is $70.00 but the partition
manager can be purchased separately for $40.00 the last time I checked.
===
Date: Mon, 29 Mar 2004 18:29:42 -0800
From: Michael Paoli <mp@rawbw.com>
To: Balug-talk@balug.org
Subject: Re: [Balug-talk] partition resizing
Quoting Jeffrey Siegal <jbs@quiotix.com>:
> John Greene wrote:
> > Jeffrey Siegal wrote:
> >>John Greene wrote:
> >>>Does anyone know of a utility for resizing partitions that will save me
> >>>from having to re-install? I have googled around some, but I can't find
> >>>anything really useful.
> >>>This would be for an EXT3 filesystem (2 disks - RAID 1). I am hoping for
> >>>a "boot to a live cd and run foo" kind of solution, because reinstalling
> >>>wouldn't be _that_ painful.
> >>Parted can do this: http://www.gnu.org/software/parted/parted.html
> >>Also, resize2fs can do it.
> >>Most rescue boot CDs should have one or both of these
> > Thank you Jeffrey. I'm not sure resize2fs will work for me: (from the
> > resize2fs man page) "The resize2fs program does not
> > manipulate the size of partitions."
> I think you misunderstood. What you do is use fdisk to change the size
> of the partition first (but leave the starting position of the partition
> alone) and then use resize2fs to modify the file syste to fill the new
> size of the partition.
>
> Backup first.
Of course backing up first (and always/frequently, and periodically
verifying, and covering off-site backups, etc.) is generally always good
advice. In addition to that ...
To shrink a partition containing a filesystem:
0. Backup
1. Shrink the filesystem:
1A. Cleanly unmount the filesystem (umount, or shutdown)
1B. Shrink the filesystem (e.g. resize2fs or ext2resize)
2. Shrink the partition (do not change the start of the partition, reduce
the size (ending location) - DO NOT reduce the partition below the
size the filesystem has been reduced to.
Some other random notes:
Some tools (e.g. parted) may be useful in combining the work of
shrinking the filesystem and the partition.
some partitioning utilities (e.g. sfdisk) may provide option to save
partition change data in a reversible manner (so, for example, one could
shrink the partition, saving the data changes, do a read-only verify of
filesystem integrity (e.g. fsck -n), etc. - and if any problems were
discovered before doing any disk writes subsequent to the partition
change, the partition change could be backed out (note that to be
guaranteed to be able to back out a partition change, one needs to write
out sector(s) written by the partition change - merely setting up the
same partition layout may be insufficient (as partition data may be
written to what were data blocks within filesystem(s)).
RAID, LVM, etc. may provide additional options (and/or complications)
(e.g. split the mirror (preserving old mirror), shrink now unmirrored
current partition, test, if all's well, shrink partition on other disk
and remirror, otherwise restore partition size and remirror from the
older preserved/untouched mirror.)
If you're not altering the root (/) filesystem, the changes can
typically be made from single user mode (the more critical resize
utilities are usually in /sbin) ... for some filesystems, it may even be
feasible to resize the filesystem(s) and partition(s) in multi-user
mode. Note also that there can be some potential hazards if the kernel
has a stale notion of what a disk's partitioning looks like.
Shrinking the partition before shrinking the filesystem can result in
filesystem corruption in certain circumstances - I'd always recommend
shrinking the filesystem before shrinking the partition.
Beware when resizing/moving Microsoft type filesystems and when dealing
with Microsoft operating systems - there are some extra gotchas (like
Microsoft sometimes believing the filesystem header more about where the
filesystem is located, than the partition table - Yow!).
===
Date: Mon, 29 Mar 2004 18:49:10 -0800
From: Nick Moffitt <nick@zork.net>
To: Balug-talk@balug.org
Subject: Re: [Balug-talk] partition resizing
begin Michael Paoli quotation:
> Of course backing up first (and always/frequently, and periodically
> verifying, and covering off-site backups, etc.) is generally always
> good advice. In addition to that ...
>
> To shrink a partition containing a filesystem:
> 0. Backup
> 1. Shrink the filesystem:
> 1A. Cleanly unmount the filesystem (umount, or shutdown)
> 1B. Shrink the filesystem (e.g. resize2fs or ext2resize)
> 2. Shrink the partition (do not change the start of the partition,
> reduce the size (ending location) - DO NOT reduce the partition
> below the size the filesystem has been reduced to.
Here's a simpler mechanism:
0. Backup
1. Repartition
2. Restore from backups.
See? Resizing partitions is easy, and doesn't require any
fancy new resizing programs!
===
Date: Mon, 29 Mar 2004 18:52:10 -0800
From: Jeffrey Siegal <jbs@quiotix.com>
To: Michael.Paoli@cal.berkeley.edu
Subject: Re: [Balug-talk] partition resizing
Cc: Balug-talk@balug.org
Michael Paoli wrote:
> Shrinking the partition before shrinking the filesystem can result in
> filesystem corruption in certain circumstances - I'd always recommend
> shrinking the filesystem before shrinking the partition.
I agree with that 100%. My earlier messages was unclear on this -- I
was referring to the original request to increase the size of the
partition, but I definitely should have been clearer that the shrink
case is different.
===
Date: Tue, 30 Mar 2004 13:46:22 -0800
To: Balug-talk@balug.org
Subject: Re: [Balug-talk] partition resizing
From: Rick Moen <rick@linuxmafia.com>
Quoting John Greene (john@grumpet.net):
> Does anyone know of a utility for resizing partitions that will save me
> from having to re-install?
Sure! It's called an LNX-BBC disk.
Boot the LNX-BBC. Use it to replicate your filesystem onto a second
host on the same LAN. Verify that everything's safely arrived, there.
Now, umount the original filesystem, use /sbin/fdisk to blow it away,
and then make a replacement of the desired type and size. mkfs the
thing, mount it, and copy the stored replica of your files back across
the LAN.
Into the bargain, you get a data backup set.
===
Date: Tue, 30 Mar 2004 14:50:43 -0800 (PST)
From: John Greene <john@grumpet.net>
To: Balug-talk@balug.org
Subject: Re: [Balug-talk] partition resizing
Nick Moffitt wrote:
> Here's a simpler mechanism:
>
> 0. Backup
> 1. Repartition
> 2. Restore from backups.
>
> See? Resizing partitions is easy, and doesn't require any
> fancy new resizing programs!
>
>
I like the simplicity of this, so I will try it. So here's a potentially
stupid question: making a tarball of the existing filesystem,
repartitioning, and deploying the tarball, are there any files that should
be omitted? Anything that will create a conflict? /proc/kcore?
Anything in /dev?
===
Date: Tue, 30 Mar 2004 15:01:27 -0800
To: Balug-talk@balug.org
Subject: Re: [Balug-talk] partition resizing
From: Rick Moen <rick@linuxmafia.com>
Quoting John Greene (john@grumpet.net):
> I like the simplicity of this, so I will try it. So here's a potentially
> stupid question: making a tarball of the existing filesystem,
> repartitioning, and deploying the tarball, are there any files that should
> be omitted? Anything that will create a conflict? /proc/kcore?
> Anything in /dev?
1. You'll want to avoid picking up /proc at all.
2. A filesystem replica is potentially less problematic than a tarball,
for a couple of reasons:
a. Your copy[ies] of tar may not be LFS-compliant, and thus not be
able to process tarballs bigger than 2 GB.
b. Need to inspect a few files in your backup set? OK, would you
rather just cd in and look, or have to untar first?
Suggestion: Just "export RSYNC_RSH=/usr/bin/ssh", and then do
"rsync -ax olddirectory username@newhost:newdirectory" for each
filesystem of interest.
The "x" keeps you from inadvertantly recursing across filesystem
boundaries, e.g., catching /proc by mistake when copying the root
filesystem. You can add "z" if you want gzip compression on the fly.
===
Date: Tue, 30 Mar 2004 15:18:27 -0800
From: Nick Moffitt <nick@zork.net>
To: Balug-talk@balug.org
Subject: Re: [Balug-talk] partition resizing
begin John Greene quotation:
> Nick Moffitt wrote:
> > 0. Backup
> > 1. Repartition
> > 2. Restore from backups.
>
> I like the simplicity of this, so I will try it. So here's a
> potentially stupid question: making a tarball of the existing
> filesystem, repartitioning, and deploying the tarball, are there any
> files that should be omitted? Anything that will create a conflict?
> /proc/kcore? Anything in /dev?
Typically I omit /dev and /proc altogether. If you're using a
2.6 kernel, you'll want to omit /sys as well.
The one thing you should grab from /dev is the MAKEDEV script,
and you should run it just after you unpack. The sad fact is that you
do want your /dev files backed up; but tar isn't smart enough to know
that they're special files, so it just starts reading the data out of
them.
As Rick Moen suggested earlier, I recommend the LNX-BBC (and
not just because I work on that project). It's a good tiny bootable
CD image that'll fit on a wallet-sized blank. You can download the
50MB ISO in a short time and burn it to a normal-sized CD-R if you
need to.
It's probably a good idea to do all of your backup work from
a live CD system, since that will ensure that you don't have processes
writing to files while your backup tool reads them (potentially
creating a "smear" of the file).
Finally, remember that you'll need to mkfs and mount any new
partitions before unpacking your tarball again.
===
Date: Tue, 30 Mar 2004 15:20:18 -0800
From: Nick Moffitt <nick@zork.net>
To: Balug-talk@balug.org
Subject: Re: [Balug-talk] partition resizing
begin Rick Moen quotation:
> Suggestion: Just "export RSYNC_RSH=/usr/bin/ssh", and then do
> "rsync -ax olddirectory username@newhost:newdirectory" for each
> filesystem of interest.
Bonus with rsync is that rsync -a understands device files,
and does The Right Thing with them.
===
Date: Tue, 30 Mar 2004 15:46:08 -0800 (PST)
From: John Greene <john@grumpet.net>
To: Balug-talk@balug.org
Subject: Re: [Balug-talk] partition resizing
Nick Moffitt wrote:
> begin Rick Moen quotation:
> > Suggestion: Just "export RSYNC_RSH=/usr/bin/ssh", and then do
> > "rsync -ax olddirectory username@newhost:newdirectory" for each
> > filesystem of interest.
>
> Bonus with rsync is that rsync -a understands device files,
> and does The Right Thing with them.
actually, I added a -v to rsync and watched most of /dev being skipped
(not a regular file). alot of broken links in the /dev backup, looks
like. I'm not sure if it's just not finished with that directory yet or
what.
===
Date: Tue, 30 Mar 2004 15:30:16 -0800
From: Nick Moffitt <nick@zork.net>
To: Balug-talk@balug.org
Subject: Re: [Balug-talk] partition resizing
begin John Greene quotation:
> Nick Moffitt wrote:
> > Bonus with rsync is that rsync -a understands device files,
> > and does The Right Thing with them.
>
> actually, I added a -v to rsync and watched most of /dev being skipped
> (not a regular file). alot of broken links in the /dev backup, looks
> like. I'm not sure if it's just not finished with that directory yet or
> what.
Sorry, that should have been -D, not -a!
===
Date: Tue, 30 Mar 2004 15:42:14 -0800
To: Balug-talk@balug.org
Subject: Re: [Balug-talk] partition resizing
From: Rick Moen <rick@linuxmafia.com>
Quoting Nick Moffitt (nick@zork.net):
> Sorry, that should have been -D, not -a!
Good point -- though both flags can usefully be used. Note that "D"
works only with root authority (for obvious reasons).
===
Date: Tue, 30 Mar 2004 16:03:59 -0800 (PST)
From: John Greene <john@grumpet.net>
To: Balug-talk@balug.org
Subject: Re: [Balug-talk] partition resizing
Rick Moen wrote:
> Quoting Nick Moffitt (nick@zork.net):
>
> > Sorry, that should have been -D, not -a!
>
> Good point -- though both flags can usefully be used. Note that "D"
> works only with root authority (for obvious reasons).
>
>
interestingly, even with the -D option it skips /dev files:
skipping non-regular file "dev/sdgd"
===
Date: Tue, 30 Mar 2004 16:06:18 -0800
To: Balug-talk@balug.org
Subject: Re: [Balug-talk] partition resizing
From: Rick Moen <rick@linuxmafia.com>
Cc:
Quoting John Greene (john@grumpet.net):
> interestingly, even with the -D option it skips /dev files:
>
> skipping non-regular file "dev/sdgd"
rick@cthulhu:~$ su
Password:
cthulhu:/home/rick# cd /tmp
cthulhu:/tmp# mkdir devfiles
cthulhu:/tmp# rsync -axD /dev /tmp/devfiles
cthulhu:/tmp# ls -al /tmp/devfiles/dev | more
total 84
drwxr-xr-x 7 root root 24576 Mar 28 10:57 .
drwxr-xr-x 3 root root 4096 Mar 28 16:44 ..
lrwxrwxrwx 1 root root 13 Mar 28 16:44 MAKEDEV -> /sbin/MAKEDEV
crw-rw---- 1 root audio 14, 14 Mar 23 11:23 admmidi0
crw-rw---- 1 root audio 14, 30 Mar 23 11:23 admmidi1
crw-rw---- 1 root audio 14, 46 Mar 23 11:23 admmidi2
crw-rw---- 1 root audio 14, 62 Mar 23 11:23 admmidi3
lrwxrwxrwx 1 root root 10 Mar 28 16:44 adsp -> /dev/adsp0
crw-rw---- 1 root audio 14, 12 Mar 23 11:23 adsp0
crw-rw---- 1 root audio 14, 28 Mar 23 11:23 adsp1
crw-rw---- 1 root audio 14, 44 Mar 23 11:23 adsp2
crw-rw---- 1 root audio 14, 60 Mar 23 11:23 adsp3
crw-rw---- 1 root video 10, 175 Aug 9 2001 agpgart
crw-rw---- 1 root audio 116, 0 Mar 23 11:23 aloadC0
crw-rw---- 1 root audio 116, 32 Mar 23 11:23 aloadC1
crw-rw---- 1 root audio 116, 64 Mar 23 11:23 aloadC2
crw-rw---- 1 root audio 116, 96 Mar 23 11:23 aloadC3
crw-rw---- 1 root audio 116, 1 Mar 23 11:23 aloadSEQ
lrwxrwxrwx 1 root root 11 Mar 28 16:44 amidi -> /dev/amidi0
crw-rw---- 1 root audio 14, 13 Mar 23 11:23 amidi0
crw-rw---- 1 root audio 14, 29 Mar 23 11:23 amidi1
crw-rw---- 1 root audio 14, 45 Mar 23 11:23 amidi2
crw-rw---- 1 root audio 14, 61 Mar 23 11:23 amidi3
crw-rw---- 1 root audio 14, 11 Mar 23 11:23 amixer0
crw-rw---- 1 root audio 14, 27 Mar 23 11:23 amixer1
crw-rw---- 1 root audio 14, 43 Mar 23 11:23 amixer2
crw-rw---- 1 root audio 14, 59 Mar 23 11:23 amixer3
crw-rw---- 1 root root 10, 134 Mar 12 04:55 apm_bios
crw------- 1 root root 10, 3 Apr 14 2001 atibm
lrwxrwxrwx 1 root root 11 Mar 28 16:44 audio -> /dev/audio0
crw-rw---- 1 root audio 14, 4 Mar 23 11:23 audio0
crw-rw---- 1 root audio 14, 20 Mar 23 11:23 audio1
crw-rw---- 1 root audio 14, 36 Mar 23 11:23 audio2
crw-rw---- 1 root audio 14, 52 Mar 23 11:23 audio3
crw-rw---- 1 root audio 14, 7 Apr 14 2001 audioctl
brw-rw---- 1 root cdrom 29, 0 Apr 14 2001 aztcd0`
[...]
cthulhu:/tmp# whoami
root
cthulhu:/tmp#
===