changing partition size.
galapogos
i have several partitions on a hard drive, let's call it sdb. I want
to copy them all to a larger drive, let's call it sdc. I want to
expand sdb1/sdc1 to fill up the remaining space while keeping sdb2-8
exactly the same. sdb1 is the boot partition with Linux installed on
an ext2 filesystem.
I've managed to recreate the partitions on sdc as per my requirements,
and I've dd'ed sdb2-8 to sdc2-8. I've also dd'ed the MBR from sdb to
sdc, then modified the MBR partition table values to keep it
consistent with the actual partitions, and fdisk recognizes the
updated sdc paritions correctly. However, when I dd sdb1 to sdc1, this
also seems to change the partition size of sdc1 to that of sdc1 when I
mount sdc1 and check it with df.
How do I change the partition size of sdc1 while having the contents
of sdb1?
Rainer Krienke
> How do I change the partition size of sdc1 while having the contents
> of sdb1?
Perhaps the easiest way is to copy data on file level not on block level.
This avoids changing any partition sizes. The only thing you have to do
then is to reconfigure and reinstall the boot loader if it is on the copied
partition.
Have a nice day
Rainer
Bill Marcum
man resize2fs
David Brown
I'm a great fan of LVM - it lets you change partition sizes on-line
(growing is quick and easy for many file systems, but shrinking is
harder). Of course, that's something to plan /before/ you start
partitioning the new disk...
Nico Kadel-Garcia
LVM doesn't know a file system from a hole in the wall. It's the
filesystem expansion tools that are tricky.
I highly recommend doing a good backup, then using a rescue CD to do
your filesystem changes and transfer material at the file system level.
David Brown
Of course - LVM is at a lower level, and is useful for expansion of the
partition. It's also useful for transferring a file system from one
disk to another - if your original logical partition and file system are
on LVM on one physical disk, you can add a second LVM physical disk to
the group, then remove the first one - LVM will migrate the data while
everything is online. But you only get the benefits of LVM if you've
built your partitions on LVM, obviously.
Resizing file systems (once the partition is extended) is not hard.
ext3 (and ext4), xfs and reiserfs can all be extended quickly and safely
without even unmounting. For reiserfs, it's a matter of two or three
seconds, regardless of the size.
> I highly recommend doing a good backup, then using a rescue CD to do
> your filesystem changes and transfer material at the file system level.
Doing a good backup first is always good advice!
Using a live rescue CD is not necessary for resizing, but it can
certainly be helpful when you want to move over system-critical partitions.
Transferring at a file system level is not necessarily easier - getting
all the non-data files to transfer properly is perfectly possible, but
not necessarily obvious for those not used to this sort of thing. Using
dd to make a raw copy is perhaps simpler, although it will be less
efficient if the file system is not nearly full.
Nico Kadel-Garcia
Necessary? No. But you can tarball up or transfer the filesystem
contents elsewhere, rebuild your filesystems arbitrarily with LVM or a
new RAID set or another drive or a different filesystem or whatever
you want, and transfer the data *back* to the new filesystem. "rsync -
avH --delete" is my very best friend for this operation, by the way,
because it proceeds very well if you interrupt and have to start over.
> Transferring at a file system level is not necessarily easier - getting
> all the non-data files to transfer properly is perfectly possible, but
> not necessarily obvious for those not used to this sort of thing. Using
> dd to make a raw copy is perhaps simpler, although it will be less
> efficient if the file system is not nearly full.
Wait. No. A "dd" copy of a partition is the only way to grab all the
data of a filesystem, and that preserves the partition size at least
as far as the filesystem is concerned. The new partition may or may
not be bigger, but it certainly does not permit *shrinking* the
filesystem, and you still have ot use a separate tool to expand your
new filesystem.
Unfortunately, I've run into way too many smart people over the past
few decades that thought this was trivial, resized their partitions,
and due to mismatched tools and confusing displays of units of "Meg =
1024 * 1024" or "Meg = 1000 * 1000" and other confusion wound up
making their new filesystem slightly *larger* than the partition
allocated, and discovering destruction when they wrote files into the
beginning of the next partition and its next filesystem and blocks got
written by both filesystems. The degree to which this is nasty is
amazing, and it's a bear to diagnose unless you have well-integrated
tools. You *cannot* expect it to work well with the random downloaded
collections of tools found via Google or Slashdot, because they
disagree about how to describe partition and filesystems sizes and
boundaries.
galapogos
So how would I resize the file system to match the new, larger
partition once I've dd'ed the partition data over? resize2fs?
Nico Kadel-Garcia
> So how would I resize the file system to match the new, larger
> partition once I've dd'ed the partition data over? resize2fs?
If you're dd'ing from one partition to another, exactly. And if you're
doing that, dd is amazingly wasteful of your time. You may as well
mount the silly file systems in single user, rescue CD mode and work
from there, because dd copies all the data of even the unused blocks
and takes a bloody longer time more than an 'rsync'.
Doug Freyburger
> galapogos <gois...@gmail.com> wrote:
>
> > So how would I resize the file system to match the new, larger
> > partition once I've dd'ed the partition data over? resize2fs?
>
> If you're dd'ing from one partition to another, exactly.
For either EXT2 or EXT3 I prefer to use ext2online.
> And if you're
> doing that, dd is amazingly wasteful of your time. You may as well
> mount the silly file systems in single user, rescue CD mode and work
> from there, because dd copies all the data of even the unused blocks
> and takes a bloody longer time more than an 'rsync'.
But if you used fdisk to expand a partition in place (trashing
whatever followed it in regular partitions) or used the logical
volume manager to expand it in place, it's already mounted.
As in the case of using dd the activity included keeping the
old filesystem size from the older smaller copy. Mount it,
see it has the old size, time to use a tool that knows how to
resize it while mounted.
David Brown
You don't need to know the exact size of the partition - file system
resize tools find out themselves the size of the target partition
(assuming you are talking about a file system on a physical or logical
partition, rather than something more exotic).
And you don't use a random downloaded tool - you use tools that are part
of your Linux distro, like ext2resize, resizefs, resize_reiserfs, etc.
It's true that starting with dd will not let you shrink the partition,
but that's a far less common operation when moving to a different disk
(new disks are generally bigger).
And it's also true that dd may take longer than rsync or cp (though it
will be faster if the file system is close to full). But with a long
operation like this, that you do on rare occasions, you'll probably let
it run overnight anyway. Does it matter if it finishes at 2 in the
morning, or 8 in the morning? If you feel safer using dd to make sure
all special files and links are exactly as you want without having to
figure out the right flags for cp or rsync, then use dd.
A copy (rsync or cp) will defragment your files during a copy, and will
also let you update the system (such as moving to an ext4 partition).
So there are plenty of good reasons for choosing one way or the other.
galapogos
Thanks everyone. resize2fs worked perfectly. The reason I used dd is
because there is some data on the disk that is not partition/file-
system specific. In fact I had tried using Acronis to clone the
partition but it didn't work. It didn't copy that data over. dd copies
everything sector by sector which is good for my purpose.