Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Moving and resizing software RAID1 partitions [solved]
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks
View previous topic :: View next topic  
Author Message
Cartroo
n00b
n00b


Joined: 04 Aug 2004
Posts: 41

PostPosted: Sun Oct 07, 2007 4:53 pm    Post subject: Moving and resizing software RAID1 partitions [solved] Reply with quote

I have a system installed on a set of software RAID1 partitions. Unfortunately I've discovered I made the /usr and /var partitions rather too big, and I'd like to shrink them and allocate the space to a partition elsewhere on the disk.

As far as I can tell this is going to involve shrinking those partitions, shuffling all the intermediate partitions upwards and then expanding the later partition to fill the new space. However, I've unsure of the best way to proceed with this.

I was wondering about setting the partitions I want to change as faulty in the RAID array, then manipulate them and then try to re-add them. This seems like it probably wouldn't work, though, because when I re-add them they'll be smaller than the ones in the existing array, and I suspect that's probably not going to work.

The only other alternative I can think of is to take the entire second disk offline, repartition it from scratch and build new RAID arrays, then reboot into a rescue disk and rsync the old partitions into the new ones, then reboot into the new set of partitions (de-graded and only running on one disk), re-create the new structure on the first disk and then add it to the new array again. This is a bit unfortunate, though, since it takes the system offline for quite awhile, and I'm not sure about this idea of rsyncing across - not sure if it's going to fail to copy things like named pipes, etc.

Or it's just occurred to me, I could take one disk offline, use parted to do the fiddling, then reboot into that set as a de-graded mirror and re-do the first disk. That avoids the need for the rsync. Does anybody know how reliable parted is at resizing and moving software RAID partitions? Presumably I'll need to resize the filesystem myself first, and then use mdadm -G to resize the software RAID, and then use parted for the partition itself?

Does anybody have any clever ideas, or comments on whether any of the above ideas would work? Any help gratefully received!

This is not a system I have physical access to, so I'm looking for reassurance I haven't missed any obvious problems, really!


Last edited by Cartroo on Mon Oct 08, 2007 1:20 pm; edited 2 times in total
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Sun Oct 07, 2007 5:15 pm    Post subject: Reply with quote

Cartroo,

I would take one disk offline, so the system is running in degraded mode, repartition it (the offline drive) the way you like, and make new raid sets on it in degraded mode. Now copy the data from the old part of the raid. Reboot in the new raid in degraded mode and test.

When you are happy you have a properly working new degraded raid, repartition the old degraded raid and add its partitions to the running syatem.

This approach does mean that your /dev/mdX numbers will change as both degraded raid sets will exist for a period.

I don't really trust filesystem and partition resizing myself.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Cartroo
n00b
n00b


Joined: 04 Aug 2004
Posts: 41

PostPosted: Sun Oct 07, 2007 5:20 pm    Post subject: Reply with quote

Thanks for the prompt response!

NeddySeagoon wrote:
I would take one disk offline, so the system is running in degraded mode, repartition it (the offline drive) the way you like, and make new raid sets on it in degraded mode. Now copy the data from the old part of the raid. Reboot in the new raid in degraded mode and test.


Yeah, this does seem like the safest method, as long as I'm careful. I have my root partition on software RAID too, but I should be able to leave that alone since it's before the ones I want to manipulate, so I should get some sort of system to boot OK. The partitions on the old set I can set to a type other than RAID autodetect, so hopefully they shouldn't interfere in any way...

You reckon that either tar or rsync will be adequate to the job of making a perfect copy of a partition? Logically I know it's all just a bunch of files at the end of the day, but I'm just paranoid! :)

Quote:
This approach does mean that your /dev/mdX numbers will change as both degraded raid sets will exist for a period.


Yeah, I was a bit worried about the entries in fstab being wrong. I guess if I'm careful to manually set the preferred minor numbers in the new RAID partitions to something different to those I already use, and update the fstab in the new partitions only to match, it all should be OK.

Quote:
I don't really trust filesystem and partition resizing myself.


No, me neither! I guess I should stop looking for shortcuts and just do things the safe way :)

Thanks for the advice!
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Sun Oct 07, 2007 5:26 pm    Post subject: Reply with quote

Cartroo,

Theres lots of ways of doing the copy, You mention tar and rsync. cp -a should work too.

Don't change the partition types away from raid autodetect. Its an unnesaccary complication.
You can use new mdX numbers and hove both sets in fstab while you test.

You rally don't care about the minor numbers as the kernel will hide them from you.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Cartroo
n00b
n00b


Joined: 04 Aug 2004
Posts: 41

PostPosted: Mon Oct 08, 2007 1:18 pm    Post subject: Reply with quote

I've successfully migrated to the new setup - thanks for the help.

For anybody else attempting the same thing, I ended up doing this following (I've done more reboots than are strictly necessary, because I wanted to check the kernel recognised everything at each stage):


  • Use mdadm --fail and mdadm --remove to remove all of the partitions that needed resizing or moving from the software RAID set. I removed partitions on /dev/sdb, leaving /dev/sda in the existing RAID sets.
  • Use cfdisk to remove the relevant partitions on /dev/sdb, then re-add them in their new layout.
  • Reboot to cause partition table to be re-read (may not be required on all systems).
  • Use mdadm --create /dev/mdX --level=1 --raid-devices=2 /dev/sdbX missing to create the new RAIDed partitions with one disk missing.
  • Create filesystems in the /dev/mdX partitions as normal.
  • Reboot and check the new partitions are auto-detected.
  • Reboot to a rescue disk.
  • Mount old and new software RAID partitions, and use cp -ax to copy files between them.
  • Alter fstab to point to the new RAIDed partitions.
  • Reboot back into newly installed system.
  • Check everything is working and you haven't lost any data. Take your time over this stage!
  • Use mdadm --stop to stop the old RAID arrays (on /dev/sda in this example).
  • Use sfdisk -d /dev/sdb | sfdisk /dev/sda to copy new partition table across (you'll need to boot back into the rescue system to do this if you have any partitions still mounted on /dev/sda).
  • Reboot to cause partition table changes to take effect (may not be required on some systems).
  • CAREFUL! Your /dev/mdX numbers may have changed now! (see below)
  • Use mdadm --add /dev/mdX /dev/sdaX to re-add the new partitions to the existing arrays.
  • Keep an eye on /proc/mdstat, and don't reboot until all the arrays are rebuilt!


The only gotcha was that the minor numbers of my software RAID partitions all changed every time I re-partitioned one of the disks - the kernel seems to re-number them all from zero every time, ignoring what you set in the preferred minor field. This means that whatever you list in fstab might need to change on a reboot. The numbering seems stable once it's settled down for a given partition layout.

So, I originally say I had md0 - md4. Then I create new partitions, which get allocated md5 - md9. So I edit fstab to point to md5 - md9 and reboot - everything works fine. So, I stop all the md0 - md4 arrays, re-partition the first disk and then reboot. When it comes back, what were md5 - md9 have all been automatically re-allocated down to md0 - md4 again! (This wasn't precisely my situation, but you get the idea).

Note: This might well have been some quirk of the rescue system my ISP uses (some network booted standard distribution, not sure which one) - I can't remember offhand what kernel version it is. If in doubt, every time you boot, boot into a rescue system with support for RAID auto-detection first, and double-check what your latest device numbers are from there when you update fstab. In the end, that worked for me.

The official line these days, it seems, is that you shouldn't rely on auto-detection, since support for it has been removed from the most recent superblock version installed by mdadm. I believe you can use kernel parameters and/or a config file to specify yourself which partitions go into which RAID arrays.


Last edited by Cartroo on Tue Oct 23, 2007 5:03 pm; edited 1 time in total
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Mon Oct 08, 2007 5:54 pm    Post subject: Reply with quote

Cartroo,

Does
Quote:
Use sfdisk -d /dev/sdb | sfdisk /dev/sda to copy new partition table across
work if you have logical partitions too ?

... and moved to Documentation Tips and Tricks as its more of a HOWTO now.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Cartroo
n00b
n00b


Joined: 04 Aug 2004
Posts: 41

PostPosted: Mon Oct 08, 2007 7:56 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Does
Quote:
Use sfdisk -d /dev/sdb | sfdisk /dev/sda to copy new partition table across
work if you have logical partitions too ?


Yes, it should work fine, with the obvious caveat that both disks must have identical layouts. It will overwrite the entire partition table of the destination disk, so you'd better make very sure there aren't any differences between the layouts on disk. I have two primary partitions, and one extended partition which contains six logical partitions, and this worked fine for me. The sfdisk -d form is specifically designed to produce commands suitable for piping into another sfdisk invocation.

It might also be worth pointing out that I left several partitions unaltered (the primary and one of the logical), and this invocation of sfdisk overwrite those entries and they still worked fine (i.e. I just left their contents sitting on the disk, and relied on the fact that those entries in the table pointed to the same parts of the disk as before I overwrote the table).

If anybody has doubts, I suggest using cfdisk instead and carefully making sure everything matches. It's certainly an exciting experience running that command on a remote system with important data on it, even if you keep telling yourself you've already got a copy! :-)

I can't promise it will work if you have more than one extended partition, but this should be extremely rare (I'm not even sure it's strictly speaking a valid partition table).
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Mon Oct 08, 2007 10:29 pm    Post subject: Reply with quote

Cartroo,

On PC hardware at least, you may have at most one extended partition
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
likewhoa
l33t
l33t


Joined: 04 Oct 2006
Posts: 778
Location: Brooklyn, New York

PostPosted: Tue Oct 09, 2007 6:03 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Cartroo,

On PC hardware at least, you may have at most one extended partition


some people keep 4 primary partition then setup the last one with lvm2 to handle logical volumes instead of having a bunch og extended partitions.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Tue Oct 09, 2007 8:20 pm    Post subject: Reply with quote

likewhoa,

On a PC you may have at most four primary partitions per disk because thats all the partition table on the MBR can hold.
At most, one of these primary partitions may be an extended partittion.
The extended partition itself occupies zero space on the drive, it serves only as a container for logical partitions.

Like everything else in the PC world, the partition table was a dirty hack to allow the use of hard drives bigger than 32Mb. That was the largest disk space DOS could address in one piece.
The extended partition was another dirty hack to get around the four partition limit. Theres very little in the PC world that was designed to be the way it is today ... it was just patched onto what was already around.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
likewhoa
l33t
l33t


Joined: 04 Oct 2006
Posts: 778
Location: Brooklyn, New York

PostPosted: Wed Oct 10, 2007 12:57 am    Post subject: Reply with quote

yea, that's why i use lvm2 to avoid that hack ;)
i prefer having lvm2 logical volumes instead of the extended/logical partitions in fdisk.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum