- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
How To Resize ext3 Partitions Without Losing Data
This article is about resizing ext3 partitions without losing data. It shows how to shrink and enlarge existing ext3 partitions and how to merge two ext3 partitions. This can be quite useful if you do not use LVM and you realize that your existing partitioning does not meet your actual needs anymore. |
|
|
Comments (28)
8 earlier comments in the full thread.
> Would it be smart to take one drive out and setup a 5-disk RAID5 so that I can swap out a faulty drive? Or can I use all 6 drives and temporarily run on 5 drives when one dies until I find a replacement?
If I remember right, Google's recent paper on drive reliability showed it was more common in practice than previously believed that two in the set can fail in the same window, so having a hot spare to minimize that window might not be a bad idea.
> Is that possible with hardware RAID too? (probably depends on the hardware...)
Depends on the hardware - check the product info for something talking about hot spares.
> * Grub's limitation to RAID1 only applies to software RAID (mdadm) right?
Yeah, software RAID, fakeraid/ataraid, etc. will be problems, but with real RAID where the controller is appearing as a drive at the hardware level, there'll be no problems.
If I remember right, Google's recent paper on drive reliability showed it was more common in practice than previously believed that two in the set can fail in the same window, so having a hot spare to minimize that window might not be a bad idea.
> Is that possible with hardware RAID too? (probably depends on the hardware...)
Depends on the hardware - check the product info for something talking about hot spares.
> * Grub's limitation to RAID1 only applies to software RAID (mdadm) right?
Yeah, software RAID, fakeraid/ataraid, etc. will be problems, but with real RAID where the controller is appearing as a drive at the hardware level, there'll be no problems.
Thanks :-)
A few other questions if you don't mind, this time regarding Xen.
* Debian/etch has -xen and -vserver-xen packages but their descriptions are the same. What's the difference (if any)? Is one for dom0 and the other for domU? or is the first without and the second with hardware VT support?
* I saw that you need to specify the ammount of RAM for domU guests. Have you got any rules of thumb about how much this needs to be? Can the sum of all DomU's be bigger than the physical RAM (e.g. 3 domU's of 512 MiB RAM running on 1 GiB physical RAM)?
* Related, lot's of tutorials about Xen show very low amounts of RAM for domU's (32 or 64 megs for a Sarge domU in some cases). Do domU's simply use less RAM than a regular system or are those tutorials too conservative/old?
A few other questions if you don't mind, this time regarding Xen.
* Debian/etch has -xen and -vserver-xen packages but their descriptions are the same. What's the difference (if any)? Is one for dom0 and the other for domU? or is the first without and the second with hardware VT support?
* I saw that you need to specify the ammount of RAM for domU guests. Have you got any rules of thumb about how much this needs to be? Can the sum of all DomU's be bigger than the physical RAM (e.g. 3 domU's of 512 MiB RAM running on 1 GiB physical RAM)?
* Related, lot's of tutorials about Xen show very low amounts of RAM for domU's (32 or 64 megs for a Sarge domU in some cases). Do domU's simply use less RAM than a regular system or are those tutorials too conservative/old?
> Debian/etch has -xen and -vserver-xen packages but their descriptions are the same. What's the difference (if any)?
They apparently allow that domU kernel to act as a Virtuozzo/OpenVZ (vserver) kernel as well (a different virtualization system). Not really sure who would want to do that other than hosting companies that sell vservers but want to virtualize their own infrastructure. I'd just ignore the -vserver-xen ones.
> I saw that you need to specify the ammount of RAM for domU guests. Have you got any rules of thumb about how much this needs to be?
However much you'd normally give such a system, considering the workload you intend for it. A rule of thumb would be, if you're running out of memory, you didn't give it enough. :) Remember to leave some space for filesystem cache/buffer memory as well. It's really easy to change, and can be done live as well, so it's not critical to have that planned out in detail in advance.
> Can the sum of all DomU's be bigger than the physical RAM (e.g. 3 domU's of 512 MiB RAM running on 1 GiB physical RAM)?
No, you can't overcommit ram on Xen.
> Related, lot's of tutorials about Xen show very low amounts of RAM for domU's (32 or 64 megs for a Sarge domU in some cases). Do domU's simply use less RAM than a regular system or are those tutorials too conservative/old?
They use the same amount of ram (or at least close enough to not be worth thinking about) as a regular system. They might have been talking about dom0 which you can shrink down if you're just going to use it for management like on a headless server (disable pretty much everything else running to save ram and reduce security risks, make sure no periodic processes are going to run that eat ram, etc.). If you're partitioning services into security contexts, like having BIND run on its own, you might also want to plan out a stripped down domU with little memory allocation, but otherwise, 32MiB isn't going to leave with with a very useful domU.
They apparently allow that domU kernel to act as a Virtuozzo/OpenVZ (vserver) kernel as well (a different virtualization system). Not really sure who would want to do that other than hosting companies that sell vservers but want to virtualize their own infrastructure. I'd just ignore the -vserver-xen ones.
> I saw that you need to specify the ammount of RAM for domU guests. Have you got any rules of thumb about how much this needs to be?
However much you'd normally give such a system, considering the workload you intend for it. A rule of thumb would be, if you're running out of memory, you didn't give it enough. :) Remember to leave some space for filesystem cache/buffer memory as well. It's really easy to change, and can be done live as well, so it's not critical to have that planned out in detail in advance.
> Can the sum of all DomU's be bigger than the physical RAM (e.g. 3 domU's of 512 MiB RAM running on 1 GiB physical RAM)?
No, you can't overcommit ram on Xen.
> Related, lot's of tutorials about Xen show very low amounts of RAM for domU's (32 or 64 megs for a Sarge domU in some cases). Do domU's simply use less RAM than a regular system or are those tutorials too conservative/old?
They use the same amount of ram (or at least close enough to not be worth thinking about) as a regular system. They might have been talking about dom0 which you can shrink down if you're just going to use it for management like on a headless server (disable pretty much everything else running to save ram and reduce security risks, make sure no periodic processes are going to run that eat ram, etc.). If you're partitioning services into security contexts, like having BIND run on its own, you might also want to plan out a stripped down domU with little memory allocation, but otherwise, 32MiB isn't going to leave with with a very useful domU.
Thanks for all the help! I'm starting the install now, so fingers crossed :-)
To swbrown:
When talking about the 'modern way', you should actually use the EVMS 'interface' to manage RAID and LVM(2). It's what I did. EVMS is made by IBM, open source (free software as far as I know, though not fully sure), and it means "Enterprise Volume Management System". The manual is really, really long, but all things which can be done with EVMS, and almost all situation an employer which handles volumes can ever encounter are probably described in the manual. EVMS is rather modular, and uses lots of plugins. For example, filesystems are plugins, so new filesystems can be implemented rather easily. Also, things like snapshot features are a plugin, and so on.
http://evms.sourceforge.net/user_guide/
You might ask me: Why? Well, mainly because it has a GUI, which in this case, is a good thing. When working with rather difficult schemes, it may be a very daunting task to just use the CLI, and even an ncurses interface wont' do. With the EVMS gui, you can extend one partition with free space without even unmounting, with only a few mouseclicks! No need to use the rather nasty LVM-commands vg/pvcreate (I used them in the past, this is rather a hassle), just clicking through a few gtk-menus! I once thought about writing an article about this (I also had hardware encryption layered over it at that time) and creating some kivio-schemes, because only reading text is just too hard. Here's my current scheme:
There's hda1 (300MB) for / (root), hda2 (2GB) for swap/Windows (note: 2GB seemed right for an OS to me at the time of creation, but Windows XP takes far and far more than that) and hda3 (74GB) for a RAID-array. Then, there's hdb1 (300MB) for a kind of mirror of /root, hdb2 (2GB) also for Windows, and hdb3 (74GB) for the RAID array again. Grub and the kernel are on hda1, which will finally also include small dirs like /etc, /lib, /bin, /root and /sbin. 300MB actually is enough for this. Nothing is done to hda2 and hdb2, though hda2 might be set up as (encrypted) swap. After that, hda3 (74GB) and hdb3 (74GB) are added to RAID arryay 0, which is called md0 (evms handles this for you, so no need to use the mdadm-command). MD0 now consists of 148 GB. After that, I created an LVM-container c0 of 148 GB on MD0. All stuff, not needed when booting, is made to EVMS volumes on container c0. So, c0 contains the volumes /dev/evms/usr, /dev/evms/var, /dev/evms/tmp, /dev/evms/opt, /dev/evms/home, it might contain /dev/evms/swap. To make things more easy, hda1, the / (root) partition, is also converted to a evms volume: /dev/evms/root (this is mounted at / , not to be confused with /root, which is part of it). The device-mapper (dev-map) makes this seem like normal partitions to Linux, but actually they are nested. You can create file systems with a few clicks on the EVMS volumes. If you want, you could create an 'LVM compatible volume' /dev/evms/dm/home_unencr (I hope that's the right path, don't have it anymore), which is an unencrypted home partition. On top of this, you could create an encrypted filesystem dm/home_encrypted using cryptsetup-luks. At the time I used this, cryptsetup wasn't in EVMS (people were invited to write it themselves back then), but it might be today. If I have the time, and can find some batteries for my mouse, I might upload some EVMS-GUI screenshots showing #evmsgui and my setup.
Please note, I use a patch for my kernel, because EVMS volumes can't be mounted if non-EVMS volumes are mounted, and the other way around. This actually is a feature in the Linux kernel, but you can turn it of. The patch is hard to find on the internet (oh, I searched and searched for it!), but it is, very handy, just in /usr/share/doc/evms-((version))/kernel/2.{4/6}/ Just so you don't have to search it for hours...
Anyway, let me know about your complex nested setups, I would be glad to read more real life experience with it, since my setup is not the smartest way to set things up. After waiting more than half an hour before my RAID0 array was created, I found out evms can also use the stripe-feature of LVM2, after the LVM volumes are created. This would mean, instead of the way described above, I could also have made 2 LVM containers, hda3 to c0 and hdb3 to c1, and then just 'stripe' my EVMS volumes on c0 and c1. If I did so, I wouldn't have that md0 of 148GB, which is much too large to handle properly (I actually want to shrink it, to make room for other distro's/ OSes. Imagine the horror, if a 'to be shrunk' RAID0 array contains an LVM volume, which contains EVMS volumes, which contain different file-systems).
After that, managing the bootloader becomes quite chaotic: (Grub line) title Gentoo Linux kernel (hd0,0)/boot/2.6.16-gentoo-r7 root=/dev/hda1
(fstab line) /dev/evms/root / ext3 noatime 0 1
The patch is needed to make these differences work, but it can probably be done in different ways too.
If somebody wants an article about it with a plethora of EVMS-screenshots and a nice Kivio-graphic showing the 'graph' of how my setup works, let me know. I thought people wouldn't be interested, since some EVMS-howto's describe this complex stuff very well, though are a bit difficult to grasp at first. Therefore, if I would be to write an article about nested filesystems including RAID, encrypted harddrives etc., it would be one aimed at beginners.
BTW I can't tell anything about Xen, since I never worked with it and hardly knows what it is, and why I would need it. If somebody can explain in simple terms why I would need Xen or what it can do for me on my one year old AMD proc without Pacifica virtualization hardware in it, please be my guest and do so. I'm interested in trying different distro's, and maybe even write a nice review about it.
When talking about the 'modern way', you should actually use the EVMS 'interface' to manage RAID and LVM(2). It's what I did. EVMS is made by IBM, open source (free software as far as I know, though not fully sure), and it means "Enterprise Volume Management System". The manual is really, really long, but all things which can be done with EVMS, and almost all situation an employer which handles volumes can ever encounter are probably described in the manual. EVMS is rather modular, and uses lots of plugins. For example, filesystems are plugins, so new filesystems can be implemented rather easily. Also, things like snapshot features are a plugin, and so on.
http://evms.sourceforge.net/user_guide/
You might ask me: Why? Well, mainly because it has a GUI, which in this case, is a good thing. When working with rather difficult schemes, it may be a very daunting task to just use the CLI, and even an ncurses interface wont' do. With the EVMS gui, you can extend one partition with free space without even unmounting, with only a few mouseclicks! No need to use the rather nasty LVM-commands vg/pvcreate (I used them in the past, this is rather a hassle), just clicking through a few gtk-menus! I once thought about writing an article about this (I also had hardware encryption layered over it at that time) and creating some kivio-schemes, because only reading text is just too hard. Here's my current scheme:
There's hda1 (300MB) for / (root), hda2 (2GB) for swap/Windows (note: 2GB seemed right for an OS to me at the time of creation, but Windows XP takes far and far more than that) and hda3 (74GB) for a RAID-array. Then, there's hdb1 (300MB) for a kind of mirror of /root, hdb2 (2GB) also for Windows, and hdb3 (74GB) for the RAID array again. Grub and the kernel are on hda1, which will finally also include small dirs like /etc, /lib, /bin, /root and /sbin. 300MB actually is enough for this. Nothing is done to hda2 and hdb2, though hda2 might be set up as (encrypted) swap. After that, hda3 (74GB) and hdb3 (74GB) are added to RAID arryay 0, which is called md0 (evms handles this for you, so no need to use the mdadm-command). MD0 now consists of 148 GB. After that, I created an LVM-container c0 of 148 GB on MD0. All stuff, not needed when booting, is made to EVMS volumes on container c0. So, c0 contains the volumes /dev/evms/usr, /dev/evms/var, /dev/evms/tmp, /dev/evms/opt, /dev/evms/home, it might contain /dev/evms/swap. To make things more easy, hda1, the / (root) partition, is also converted to a evms volume: /dev/evms/root (this is mounted at / , not to be confused with /root, which is part of it). The device-mapper (dev-map) makes this seem like normal partitions to Linux, but actually they are nested. You can create file systems with a few clicks on the EVMS volumes. If you want, you could create an 'LVM compatible volume' /dev/evms/dm/home_unencr (I hope that's the right path, don't have it anymore), which is an unencrypted home partition. On top of this, you could create an encrypted filesystem dm/home_encrypted using cryptsetup-luks. At the time I used this, cryptsetup wasn't in EVMS (people were invited to write it themselves back then), but it might be today. If I have the time, and can find some batteries for my mouse, I might upload some EVMS-GUI screenshots showing #evmsgui and my setup.
Please note, I use a patch for my kernel, because EVMS volumes can't be mounted if non-EVMS volumes are mounted, and the other way around. This actually is a feature in the Linux kernel, but you can turn it of. The patch is hard to find on the internet (oh, I searched and searched for it!), but it is, very handy, just in /usr/share/doc/evms-((version))/kernel/2.{4/6}/ Just so you don't have to search it for hours...
Anyway, let me know about your complex nested setups, I would be glad to read more real life experience with it, since my setup is not the smartest way to set things up. After waiting more than half an hour before my RAID0 array was created, I found out evms can also use the stripe-feature of LVM2, after the LVM volumes are created. This would mean, instead of the way described above, I could also have made 2 LVM containers, hda3 to c0 and hdb3 to c1, and then just 'stripe' my EVMS volumes on c0 and c1. If I did so, I wouldn't have that md0 of 148GB, which is much too large to handle properly (I actually want to shrink it, to make room for other distro's/ OSes. Imagine the horror, if a 'to be shrunk' RAID0 array contains an LVM volume, which contains EVMS volumes, which contain different file-systems).
After that, managing the bootloader becomes quite chaotic: (Grub line) title Gentoo Linux kernel (hd0,0)/boot/2.6.16-gentoo-r7 root=/dev/hda1
(fstab line) /dev/evms/root / ext3 noatime 0 1
The patch is needed to make these differences work, but it can probably be done in different ways too.
If somebody wants an article about it with a plethora of EVMS-screenshots and a nice Kivio-graphic showing the 'graph' of how my setup works, let me know. I thought people wouldn't be interested, since some EVMS-howto's describe this complex stuff very well, though are a bit difficult to grasp at first. Therefore, if I would be to write an article about nested filesystems including RAID, encrypted harddrives etc., it would be one aimed at beginners.
BTW I can't tell anything about Xen, since I never worked with it and hardly knows what it is, and why I would need it. If somebody can explain in simple terms why I would need Xen or what it can do for me on my one year old AMD proc without Pacifica virtualization hardware in it, please be my guest and do so. I'm interested in trying different distro's, and maybe even write a nice review about it.
> ...If somebody can explain in simple terms why I would need Xen or what it can do for me...
Xen, like VMware, lets you run virtual machines on your real machine. This allows you to experiment with new OS'es and the like without touching your physical hardware, and to run multiple OS'es at the same time.
Xen, like VMware, lets you run virtual machines on your real machine. This allows you to experiment with new OS'es and the like without touching your physical hardware, and to run multiple OS'es at the same time.
After a little experimentation I managed to get everything setup correctly. I'll probably write an artcie in the short future about how I did it and what problems I encountered. Some remarks/tips:
* turns out I had two 18.2 Gb and four 36.4 Gb drives so I couldn't make everything into one RAID5. I made a RAID5 and RAID1 and joined them using LVM. * Setting up LVM from the Debian Installer is poorly documented and confusing if you have never done it before. * installing xen 3.0.3 on Debian doesn't setup bridging for you. I had to manually create a xenbr0 bridge in /etc/network/interfaces. * You need the -pae version of Xen if your system supports more then 4Gb RAM, even if you have less than 4Gb actually installed. * xen-create-image only creates a base system for you. You want to run "dpkg-reconfigure locales" and "tasksel --new-install" on a new image. Then create a new user and set "PermitRootLogin" to "no" in /etc/ssh/sshd_config. * When Debian dom0 shuts down I get an error message that the LVM volume group cannot be shut down because there are open volumes. This is most likely caused by the fact that both the root and the swap partition of dom0 are in the LVM volume group as well. Only it's /boot partition isn't.
All-in-all I'm pretty pleased with the setup :-) Thanks for all the tips!
* turns out I had two 18.2 Gb and four 36.4 Gb drives so I couldn't make everything into one RAID5. I made a RAID5 and RAID1 and joined them using LVM. * Setting up LVM from the Debian Installer is poorly documented and confusing if you have never done it before. * installing xen 3.0.3 on Debian doesn't setup bridging for you. I had to manually create a xenbr0 bridge in /etc/network/interfaces. * You need the -pae version of Xen if your system supports more then 4Gb RAM, even if you have less than 4Gb actually installed. * xen-create-image only creates a base system for you. You want to run "dpkg-reconfigure locales" and "tasksel --new-install" on a new image. Then create a new user and set "PermitRootLogin" to "no" in /etc/ssh/sshd_config. * When Debian dom0 shuts down I get an error message that the LVM volume group cannot be shut down because there are open volumes. This is most likely caused by the fact that both the root and the swap partition of dom0 are in the LVM volume group as well. Only it's /boot partition isn't.
All-in-all I'm pretty pleased with the setup :-) Thanks for all the tips!
> what it can do for me on my one year old AMD proc without Pacifica virtualization hardware in it
The thing that makes Xen stand out from other virtualization techniques is that it can run at near normal speeds even without hardware virtualization. The only downside is that you have to run a modified kernel to do it (which means that it cannot run Windows for example. Only Free OS'es). If you do have hardware virtualization then Xen can run unmodified kernels (including Windows).
And I imagine that live migration is very nice, especially for system administrators. Imagine that you buy a new computer. You can then move your OS from one machine to the other without even rebooting it and only 30-100ms of downtime. Sweet :-)
The thing that makes Xen stand out from other virtualization techniques is that it can run at near normal speeds even without hardware virtualization. The only downside is that you have to run a modified kernel to do it (which means that it cannot run Windows for example. Only Free OS'es). If you do have hardware virtualization then Xen can run unmodified kernels (including Windows).
And I imagine that live migration is very nice, especially for system administrators. Imagine that you buy a new computer. You can then move your OS from one machine to the other without even rebooting it and only 30-100ms of downtime. Sweet :-)
OK, thanks for the Xen info. I am going to try it, when there's some spare time (not soon).
Sander: I also had that problem with LVM sometimes, but it disappeared as I switched to EVMS. As far as I know, it is caused by not unmounted filesystems, which could be nested.
Sander: I also had that problem with LVM sometimes, but it disappeared as I switched to EVMS. As far as I know, it is caused by not unmounted filesystems, which could be nested.
Ok, I'm still trying to understand Xen and just how it functions.
I understand the basics of virtualization in general (I've used vmware, vmware server, qemu).
But as I understand it Xen is even more advanced?
Assuming use of a CPU with virtualization support (is there a list of which ones these are?), is it possible to say, run a base *nix host (bsd/gentoo/debian/whatever), and then run multiple virtualized OSs on it simultaneously (i.e. a Winders session and a *nix session) and switch between them at will without stopping one and starting another?
How is the hardware support?
I.E. would things like 3d support work for games or whatnot in the installs?
Thanks. Once I get my head around all this maybe I'll get a chance to try it out on something.
Thanks. Once I get my head around all this maybe I'll get a chance to try it out on something.
> When talking about the 'modern way', you should actually use the EVMS
> 'interface' to manage RAID and LVM(2).
EVMS stalled out many years ago when it was rejected by the kernel team. I don't see it as alive enough to be something safe to use at the moment.
EVMS stalled out many years ago when it was rejected by the kernel team. I don't see it as alive enough to be something safe to use at the moment.
Quoting:Assuming use of a CPU with virtualization support (is there a list of which ones these are?), is it possible to say, run a base *nix host (bsd/gentoo/debian/whatever), and then run multiple virtualized OSs on it simultaneously (i.e. a Winders session and a *nix session) and switch between them at will without stopping one and starting another?
Exactly. And if you don't plan on running Windows as a guest OS then you don't even need a chip with hardware virtualization support. Any CPU will do.
Quoting:How is the hardware support? I.E. would things like 3d support work for games or whatnot in the installs?
Look at http://wiki.xensource.com/xenwiki/XenFaq#head-d5a7a247a51685... Technically it's possible to give one (and only one) guest system access to the hardware, but the (closed source) drivers cannot handle it (yet).
> Technically it's possible to give one (and only one) guest system access to the hardware,
You can partition access based on PCI identifiers as well and hand them out to various guests, but it's not something really useful for the average user.
You can partition access based on PCI identifiers as well and hand them out to various guests, but it's not something really useful for the average user.
>not something really useful for the average user.
I'm pretty sure Xen isn't 'useful for the average user'. Eventually, maybe? Right now it's useful for professional servers, and of course, geeks at play.
I'm pretty sure Xen isn't 'useful for the average user'. Eventually, maybe? Right now it's useful for professional servers, and of course, geeks at play.
Quoting:You can partition access based on PCI identifiers as well and hand them out to various guests, but it's not something really useful for the average user.
Does that mean that if you have a board with 2 graphics cards and two processors, either dual core or two physical processors, you can have two operating systems running, each with their own video card and processor?
If so that would be cool.
> I'm pretty sure Xen isn't 'useful for the average user'. Eventually, maybe? Right now it's useful for professional servers, and of course, geeks at play.
I haven't played with Xen, so I can't speak for it. As far as I can tell, VMware player IS pretty much ready for the average user, assuming a virtual image exists which does what they want.
I haven't played with Xen, so I can't speak for it. As far as I can tell, VMware player IS pretty much ready for the average user, assuming a virtual image exists which does what they want.
We'll see when the first Distro's with Xen as an option in the installer start shipping.
> I'm pretty sure Xen isn't 'useful for the average user'. Eventually, maybe? Right now it's useful for professional servers, and of course, geeks at play.
It depends on your definition of 'average user'. I can see it having much broader appeal once you could do something like alt+tab between Windows and Linux (I don't mean windowed, I mean like a KVM), but that would require a lot of driver replacement on the Windows side. VMWare has been trying to do that, but it's still a long way away. Probably, the only driver layer you absolutely would need to replace would be the video layer (X wouldn't be difficult to have reinitialize, Windows I dunno how it works).
It depends on your definition of 'average user'. I can see it having much broader appeal once you could do something like alt+tab between Windows and Linux (I don't mean windowed, I mean like a KVM), but that would require a lot of driver replacement on the Windows side. VMWare has been trying to do that, but it's still a long way away. Probably, the only driver layer you absolutely would need to replace would be the video layer (X wouldn't be difficult to have reinitialize, Windows I dunno how it works).
> It depends on your definition of 'average user'.
Very true. I think your assessment is a lot higher than mine :)
Very true. I think your assessment is a lot higher than mine :)
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
A few questions:
* Would it be smart to take one drive out and setup a 5-disk RAID5 so that I can swap out a faulty drive? Or can I use all 6 drives and temporarily run on 5 drives when one dies until I find a replacement? I read that with Debian's software RAID you can designate one drive as a spare which will be used when another disk fails. Is that possible with hardware RAID too? (probably depends on the hardware...)
* Grub's limitation to RAID1 only applies to software RAID (mdadm) right? All grub will see of my RAID5 is plain old /dev/sda? Or should I setup a 256MB RAID1 on all disks for dom0 /boot anyway in hardware RAID?