On Thu, Jul 09, 2009 at 02:19:44AM -0600, lee wrote: > On Thu, Jul 09, 2009 at 03:33:01PM +1000, Alex Samad wrote: > > > > Creating a swap partition on a software RAID device isn't ideal. > > > > what happens if there is something important swapped out and that drive > > dies ? I could understand not wanting to put it on lvm and then raid1. > > When the swap partition quits working, the system might stop > working. So the question is what's more important, increased > reliability or faster swap.
I am not sure that raid1 is noticeable slower than raid0 (or jbod), raid
5 maybe or any other parity raid
>
> Personally, I'd feel awkward about having swap partitions on
> a software RAID, but when setting up something like a server to
> provide important services for a company, I would insist on using a
> good hardware RAID controller and likely put the swap partition onto
> the RAID.
Depends on how much you are going to spend on the controller and weather
or not you are going to have battery backed up cache - if you not you
might aswell go software raid (only talking raid1 here).
If you do spend the money and have multiple machines then you might as
well go for a san......
I would suggest for most commercial situations a software raid setup or
2 raid 1 disk is a far better solution that a proprietary hardware raid
controller
>
> > > BTW, wouldn't you rather create a partitionable RAID from the whole
> > > disks and then partition that? If not, why not? (Letting aside where
> > > to put the swap partition ...)
> >
> > I have had to rescue machines and having a simple boot + / make like a
> > lot simpler - why make life hard
>
> Aren't you making it hard by having to partition all the disks
> involved and then creating RAIDs from the partitions? It's more work
> when setting it up, and it can turn into a disaster when something
> with discovering the RAID goes wrong.
sfdisk -d <master device> > raidlayout.out
sfdisk <new raid device> < raidlayout.out
you could wrap it inside a for loop if you want
>
> For example, when I put the disks containing my RAID-1 into another
> computer and installed the raid tools, I was asked questions about
> starting the raid and answered that I wanted to start the RAID arrays
> when booting. I had the disks partitioned and had created RAID arrays
> from the partitions.
>
> The result was that the RAID was started immediately (which I consider
> as a bug) instead when booting, before I had any chance to check and
but you said above you gave the okay to start all raid devices, so why
complain when it does it ?
> to configure the RAID arrays correctly so that they would be detected
> as they should. It started resyncing the md devices in a weird way. I
> was only lucky that it didn't go wrong. If it had gone wrong, I could
> have lost all my data.
And this why we have backups
>
> Now when I got new disks, I created the RAID arrays from the whole
> disks. In this case, I didn't partition the RAID array, but even if I
> did, the number of md devices was reduced from the three I had before
> to only one. The lower the number of md devices you have, the less
> likely it seems that something can go wrong with discovering them,
> simply because there aren't so many.
I don't think you are going to have overflow problems with number of
raid devices
>
> To me, it seems easier to only have one md device and to partition
> that, if needed, than doing it the other way round. However, I went
> the easiest way in that I have another disk with everything on it but
> /home. If that disk fails, nothing is lost, and if there are problems,
well except for /etc/
> a single disk is the simplest to deal with. --- I might have done it
> otherwise, but it has been impossible to install on SATA disks because
> the modules required to access SATA disks are not available to the
if you have a look at the latest installer i think you will find it has
all the necessary modules now
> installer. Maybe that has been fixed by now; if it hasn't, it really
> should be fixed.
I was suggesting to put / on its own partition as well as /boot. boot I
do out of habit from long time ago, with busybox you can access the
system even if the other partition as corrupted and still try and
salvage stuff
The suggest I have made are for reducing risk, the gain made by having a
separate root and boot in my mind a re worth it.
In a production environment you have change management procedures or
at least some documentation.
>
>
> In which way having many md devices made it easier for you to perform
> rescue operations? Maybe there are advantages I'm not thinking of but
> which would be good to know. I want to get rid of that IDE disk and
> might have a chance to, so I'm going to have to decide if I want to
> install on a RAID. If it's better to partition the disks rather than
> the RAID, I should do it that way.
You have missed the point the advantage is have a separate / and a
separate /boot to protect them you can even mount /boot as ro.
All the partitions are raided again for protection. If you are worried
about a little complexity then managing HA and/or production system
might not be up your alley.
>
>
Having said all that, there is no golden rule, each situation needs to
be addresses individually weighing you the risks compared to the gains
For me as a creature of habit I usually follow the layout I specified
before - because it has worked and it has save me time and it is very
flexible, your mileage might vary.
Alex
--
"Kosovians can move back in."
- George W. Bush
04/09/1999
CNN interview
signature.asc
Description: Digital signature
