# Swap on RAID-0 or individual partitions?

## selig

I have seen a lot of people putting their swap on a RAID-0 device. Why not use several independent partitions and set them up as swap with the same priority? If I understand correctly, kernel will distribute the swapped memory pages among swap partitions with equal priority.

So which setup is really faster / better? I have got no idea how to benchmark swapping...

----------

## schachti

 *selig wrote:*   

> I have seen a lot of people putting their swap on a RAID-0 device. Why not use several independent partitions and set them up as swap with the same priority? If I understand correctly, kernel will distribute the swapped memory pages among swap partitions with equal priority.

 

You understood it correctly - swap on RAID0 is not necessary, it does not give you any advantage.

----------

## bunder

swap on raid is highly discouraged.  if your stripe breaks and the kernel wants to page in/out, you could be in for a nasty surprise (crash, oops, or even panic)

cheers

----------

## monsm

This is all news to me.  I am afraid I am one of those that have swap on a Raid-0 device.  Thing is my machine has 2 hard drives and participate in that stripe.  There is no other hard drive.  So what is should I do? I am after maximising performance on my system.

Why doesn't swap on a raid-0 device help? Swap is for memory swapping isn't it, so why should it matter what sort of HD setup I have?

 Mons

----------

## schachti

 *monsm wrote:*   

> So what is should I do?

 

Look in the first posting in this thread: Instead of using two partitions for a RAID0+swap, use both partitions as a normal swap partition and assign the same priority to them.

 *monsm wrote:*   

> Why doesn't swap on a raid-0 device help?

 

Because the kernel already optimizes swapping if more than one swap partition exists.

 *http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml wrote:*   

> 
> 
> Note: On the one hand, if you want extra stability, consider using raid-1 (or even raid-5) for your swap partition(s) so that a drive failure would not corrupt your swap space and crash applications that are using it. On the other hand, if you want extra performance, just let the kernel use distinct swap partitions as it does striping by default. 
> 
> 

 .

----------

## selig

I think you have to explicitly set the priority in /etc/fstab - otherwise swap will be used in "linear" mode, for example like this:

```

/dev/sda2    swap    swap    pri=5 0 0

/dev/sdb2    swap    swap    pri=5 0 0

```

----------

## NeddySeagoon

bunder,

 *Quote:*   

> ... if your stripe breaks and the kernel wants to page in/out ...

 with your raid0 broken, swap will be the least of your worries

----------

## andreas_st

The only situation where swap on RAID may be useful is for a remotely administrated machine where you want to be sure that your uptime survives a hard disk crash. Then I would put the swap on RAID1 (or another redundant RAID setup) but that doesn't give you any speed advantage. Swap on RAID0 doesn't make any sense for me.

----------

## monsm

Right, so its because how the kernel deal with the swapping that makes this a bit pointless with a raid-0.

There is an inherent risk by using raid-0 (you effectively double your chance of loosing data with 2 harddrives in the stripe as I have).  The chance of a hd crash is still relatively low though, so I am happy to take that chance.  I do run backups regularly just in case   :Wink: 

But back to how this is supposed to be set up.  At the moment my fstab has this line:

```
/dev/mapper/sil_afafejbgajdg8 swap             swap    defaults        0 0
```

So should I now replace this with 2 lines, each pointing to the same partition on each of the 2 harddrives as selig seems to be saying?

Is it safe to use a member of a stripe like that?  This is a Silicon Image SATA RAID-0 by the way.

Mons

----------

## selig

 *monsm wrote:*   

> 
> 
> But back to how this is supposed to be set up.  At the moment my fstab has this line:
> 
> ```
> ...

 

Which devices (partitions) are you using to create the /dev/mapper/sil_afafejbgajdg8 device? You can then substitute the /dev/sda2 and /dev/sdb2 entries in my example above for them. Of course first you need to disable swap and stop the device mapper for your swap partitions.

----------

## NeddySeagoon

monsm,

You are using fakeraid ... if  you only have /dev/mapper/sil_afafejbgajdg you can't changeit.

----------

## Mad Merlin

 *bunder wrote:*   

> swap on raid is highly discouraged.  if your stripe breaks and the kernel wants to page in/out, you could be in for a nasty surprise (crash, oops, or even panic)
> 
> cheers

 

I'm pretty sure the exact same thing will happen with non-RAID striped swap if you lose a drive...

----------

## selig

Yes, but if your system partitions are on RAID-0 then you can have striped swap as well - if a drive crashes then your system will crash anyway with that setup.

----------

## heijs

I used to have my swap partition on RAID1, because it is much more reliable. How often do you guys use your swap?

----------

## monsm

Yes, I do have fakeraid, so I'm a bit nervous about using the harddrive devices directly.  It may upset my Silicon Image chipset...

I am not worried about crashes on this swap partition; If there is a problem with my stripe, my whole system is gone and hopefully I have a recent enough backup to rebuild from.

I am only interested in the performance.  Surely the kernel still needs to use some swap from time to time, It can use my striped swap partition.  It must be better to have this swap, than not to have it...(?)

----------

## schachti

 *monsm wrote:*   

> Surely the kernel still needs to use some swap from time to time, It can use my striped swap partition.  It must be better to have this swap, than not to have it...(?)

 

If you really need the swap sometimes and there is no other way than swap on RAID0 then, then of course you can use it. As was written above, you have no performance gain compared to single swap partitions, and it is more likely to fail - but as long as it works for you...

----------

## monsm

Thanks for that. It clear it up a bit, Schachti.

I guess the chance of my swap partition crashing is no bigger then my root partition which is on another striped one on the same 2 devices (?).

I have 1.5 Gb on my system, if I didn't have the swap partition, what would the kernel do if it run out of memory?  Use the root partition with some swap file, ala windows?  Far as I know, I don't think it uses the swap very often at the moment.

----------

## schachti

 *monsm wrote:*   

> I have 1.5 Gb on my system, if I didn't have the swap partition, what would the kernel do if it run out of memory?

 

It will kill some process to free some memory - search the web for OomKiller to get more information on it.

 *monsm wrote:*   

> Use the root partition with some swap file, ala windows?

 

No. If you do not add swap space by yourself, the kernel won't do that.

----------

## devsk

 *monsm wrote:*   

> Thanks for that. It clear it up a bit, Schachti.
> 
> I guess the chance of my swap partition crashing is no bigger then my root partition which is on another striped one on the same 2 devices (?).
> 
> I have 1.5 Gb on my system, if I didn't have the swap partition, what would the kernel do if it run out of memory?  Use the root partition with some swap file, ala windows?  Far as I know, I don't think it uses the swap very often at the moment.

 don't worry about it. If you have no other disk than the ones in RAID0, its fine to use a partition on RAID0 as your swap. There is nothing wrong with that. I have been running the same setup for over 2 years now without any problems. "Performance advantage is not there" is not the reason enough for not using it. The risk is capped by your using the RAID0 for "/" in the first place. It can't get any more riskier than that.

One more thing: always configure swap even if you have 2GB RAM. Do not rely on OOM killer. In fact, I would encourage you to disable it. You don't really want your firefox to die in the middle of processing a secure online txn, just because OOM thought it was eating too much RAM.

One reason for using a simple disk partition for your swap could be that if you want to use TuxOnIce to suspend to disk in future.

----------

## x22

Disable OOM killer? Doesn't that mean that the whole system will die (kernel panic) on OOM?

Firefox or internet connectivity may die for many other reasons. 

Windows will not create swap file when it is not configured to. It will refuse to allocate (commit) memory when it cannot guarantee enough space in RAM or paging files to store it. 

Linux in default configuration allows such allocations. But when amount of memory really used (not all allocated memory is really used) reaches all swap plus RAM it has to kill some process (or panic).

----------

## monsm

 *devsk wrote:*   

> The risk is capped by your using the RAID0 for "/" in the first place. It can't get any more riskier than that.
> 
> 

 

Thats ok then, I am not too much into this safety hysteria   :Very Happy: 

As an illustration "2 in 2 billion" is twice the risk of "1 in 2 billion", but still not that risky.  So I'm thinking my harddrives are both very reliable anyway (touch wood, cross the fingers).

So back to selig's query then, I guess independent harddrives with equal priority swap partitions are faster.  Although with a good amount of memory you want notice any difference anyway.

Don't know how you would go about bench marking something like that though...

----------

## schachti

 *devsk wrote:*   

> Do not rely on OOM killer. In fact, I would encourage you to disable it. You don't really want your firefox to die in the middle of processing a secure online txn, just because OOM thought it was eating too much RAM.

 

If you do so and run out of memory, you'll get a kernel panic and therefore have a problem anyway. But maybe it is a more clean solution to get a kernel panic and let the system reboot, than just to kill processes more or less randomly.

----------

## devsk

All I said was that you should always configure SWAP and not rely on OOM to bail you out when you run out of memory. If you have enough swap configured, you will not run out of memory on a desktop machine. You will start noticing slow downs because of swapping much more early and can take corrective action before you reach the kernel panic stage. e.g. you can logout of that secure site when you know that your mouse is stuttering and firefox is showing 1.6G usage in 'top', and restart firefox. With 2GB RAM and no swap, firefox will probably die on you soon without you even noticing the symptoms of low memory.

If its a server in your basement, its a different ball game. You would configure sufficient swap, with sufficiency amount determined from your load and the kind of apps you run on your server, in that case too.

----------

## selig

Well I disable swap when I use my laptop on battery - that one has got 768 MB RAM and I have experienced slowdowns when the memory is near-full. Killing the offending task (I had too many big pictures in GIMP open without prior realising the memory limit) took the kernel a while.

I think that you can choose the OOM killer when compiling the kernel - there are two available. One kills the application which tries to allocate more memory and the other will try to choose the "best" task to kill (I have got no idea of how it does that - looks quite random to me).

So killing the task which tries to allocate more memory and not using swap can sometimes be useful.

On normal PCs or servers though, swap is your friend - but you do not need to configure too much swap. When my box with 2GB RAM was using 480 MB swap (on a dedicated disk which is almost never used for data), it was swapping to and from disk constantly, it could not even use more swap.

Unless you are using some memory-hungry applications which load lots of junk which is never used into memory (BEA JRockit), swap size of 512 MB should be more than sufficient.

JRockit can happily eat up 2 GB of swap on a machine with 2 GB of RAM, but it just fills the swap up and later swapping happens only very rarely.

----------

## orlandoreis

Hi all, I'm going to go back to the subject of using raid0 for swap or not.

I have some questions for more advanced users:

If you are using raid0 for a whole system isn't it pointless not to have raid0 for swap (I can imagine gains if its done through hardware)?

What I could figure out off the documentation of tldp http://www.tldp.org/HOWTO/Software-RAID-HOWTO-2.html#ss2.3

/dev/sda2       swap           swap    defaults,pri=1   0 0

/dev/sdb2       swap           swap    defaults,pri=1   0 0

/dev/sdc2       swap           swap    defaults,pri=1   0 0

/dev/sdd2       swap           swap    defaults,pri=1   0 0

...

If the system can recover from a crash after one of the swap areas is lost, doesn't this mean that it is not pure striping but just some sort of load balancing? If it's really stripping its going to write in all disks at the same time. If one would fail you would lost them all?

The reason pointed not for using raid0 was that the system could come up after on the swap areas was lost. So this takes me to the next question:

Imagine the swap areas above all have about 2GB and you are going to write 1GB, this means it’s going to be written only on one off them? 

If we are going to write 7,5 GB of data to swap will it try to write it sequentially?

I’m just trying to have better knowledge of how swap is treated by the kernel.

with regards,

Orlando

----------

## NeddySeagoon

orlandoreis,

If your swap is on the same raid0 set as the rest of the system, when you lose a drive, your system is dead. 

Swap is the least of your problems.

The kernel will manage several swaps at the same priority for itself, it does not need the raid0 driver to do it, so swap on raid0 is a waste of CPU cycles. If you only have swap on raid0, if swap is in use when you lose a drive, the results are unpredictable.

If everything is in the first chunk on the good drive ... nothing has gone. If you lost data then one of your applications has had a lobotomy and with luck, the kernel will kill it when it fails to read its swapped code back in. 

Whenever your want to write large amounts of data to swap, you don't have enough real memory. Think about the write time.

On a single drive, you might get 50Mb/sec, so thats 10 seconds for 500Mb. You really don't want to wait even small fractions of a second for swapping, which soaks up time and contributes nothing to useful program execution. Its just moving data around.

----------

## orlandoreis

Hi NeddySeagoon, thats not what I asked.

My comments in blue

 *NeddySeagoon wrote:*   

> orlandoreis,
> 
> If your swap is on the same raid0 set as the rest of the system, when you lose a drive, your system is dead. 
> 
> Swap is the least of your problems.
> ...

 

That I already know  :Smile: , I wasn't asking, I was stating if the hole system is in raid0 and one off the HD fails you loose everything. 

I was stating if it's in raid0 then it will probably faster to let it stay in raid0, and if it's hardware accelarated then there is no cpu waste (let the scsi raid controller do it's work).

 *NeddySeagoon wrote:*   

> 
> 
> If everything is in the first chunk on the good drive ... nothing has gone. If you lost data then one of your applications has had a lobotomy and with luck, the kernel will kill it when it fails to read its swapped code back in. 
> 
> 

 

Ok, I agree.

 *NeddySeagoon wrote:*   

> 
> 
> Whenever your want to write large amounts of data to swap, you don't have enough real memory. Think about the write time.
> 
> On a single drive, you might get 50Mb/sec, so thats 10 seconds for 500Mb. You really don't want to wait even small fractions of a second for swapping, which soaks up time and contributes nothing to useful program execution. Its just moving data around.
> ...

 

I was not stating it was performant which I know it isn't, what I was asking, was, if those case scenarios happen, what would be the behaviour, how would the kernel handle those swap requests, what would happen?

Therefore I'll ask again, imagine a situation where there are 4 independent swap devices, each with 2GB for simplicity:

a) what would happen when writing 500 MB to swap? 

    -> would it write those 500 MB of data only on one device?

b) what would happen if you wrote 6.5GB for example? 

    -> would it fill those 4 devices in a sequential way?

----------

## zeek

 *orlandoreis wrote:*   

> 
> 
> a) what would happen when writing 500 MB to swap? 
> 
> 

 

The system would be unusable and probably never recover.

 *orlandoreis wrote:*   

> b) what would happen if you wrote 6.5GB for example? 
> 
> 

 

The system would be unusable and would never recover.

Swap IO happens at a fraction of the speed of normal IO.

----------

## orlandoreis

 *zeek wrote:*   

>  *orlandoreis wrote:*   
> 
> a) what would happen when writing 500 MB to swap? 
> 
>  
> ...

 

Zeek did you bother reading the question? I just want to know how does the kernel handle those hypothetical situations, I'm not stating that none of the 4 devices failed.

OK.... for the sake of simplicity...

Imagine the following situation, THIS IS A EXAMPLE, imagine a system that is running perfectly it has 4 swap devices each with 2 GB and with the same priority.

I'm going to ask the same question for the third time (maybe I should be posting this on the kernel development forum),  imagine that for some reason it's physical memory is full and it will need to allocate memory in swap:

A ->  It's going to need to write 500 MB, is this memory going to allocated only on one of the devices???

B ->  It's going to need to write 6.5GB, those 6.5GB are they going to be written sequentially?

[/b]

Please answer the question, don't just say "system is/will unusable", situations like this sometime happen.

With regards,

Orlando

----------

## NeddySeagoon

orlandoreis,

The answer is hardware and low level device driver dependant.

Depending on the above variables, different degrees of parallelism are possible.

----------

## orlandoreis

 *NeddySeagoon wrote:*   

> orlandoreis,
> 
> The answer is hardware and low level device driver dependant.
> 
> Depending on the above variables, different degrees of parallelism are possible.

 

Hi NeedySeagoon can you please provide some more information? that is a litle bit vague/ambiguous.

My question would be if the kernel does pure stripping (and by stripping I mean writes/read's with same block size to multiple devices, like raid0 stripping done through hardware).

With kind regards,

Orlando

----------

## NeddySeagoon

orlandoreis,

The kernel sets up the DMA engines for the transefer ... what happens next depends on the hardware.

With IDE interfaces, only one operation can be in progress on the IDE bus at a time, so access to both devices must be sequential.

Its nothing to do with the kernel, the kernel has done its bit and gone on to something else once its set up the DMA controller.

Some badly designed SATA controllers can only operate one port at a time, so again, the hardware forces sequential access.

If you suppose that PIO is used, the kernel is forced to write every byte sequentially, as the CPU does the transfers

You should not assume that hardware raid does simultainious writes because the raid volume appears as a single device to the kernel.

A hardware raid card is much like a plug in PC for your PC except that its processor is usually not x86. 

With multiple swaps at the same priority, the kernel tries to use them all at the same time, like raid0.

With different priorities, its like linear raid0, so you are in control.

----------

## zeek

 *orlandoreis wrote:*   

> Zeek did you bother reading the question? I just want to know how does the kernel handle those hypothetical situations ...

 

Of course I read the question.  The answer is linux can't use a swapfile to provide Gigs of usable RAM.  It just locks up.  Why don't you just try it?  I guarantee your system will become unstable and lockup hard and never recover.  Lets analyze why it doesn't work!

Back in the day EDO RAM maxed out at 256MB/s and your hard disk xfer was 10MB/s.

Today we're looking at 16 GB/s RAM xfer rate and 60 GB/s hard disk.

RAM speeds have gone up by 60x while hard drives only 6x.  Hard drives did not keep pace with RAM.  As a result swapfiles are now next to useless.  

Another thing to keep in mind is that swap IO is something like 2-5% of your max IO for that device (because its working on pages at a time).

Linux is probably the worst mainstream OS in its handling of low memory situations.  It overcommits memory (allowing malloc to succeed when there isn't sufficient RAM to back it up), the OOM killer terminates random processes (always annoying when it kills sshd), and when under extreme memory pressure it doesn't schedule other tasks (cpu is 99% idle).

----------

## NeddySeagoon

zeek,

What it boils down to is that any system running a process that wants to allocate >500MB of memory when much of it doesn't exist is broken by desigi. Any system that gets into allocating GBs of RAM in he same situation is even more broken. 

The writing swap a page at a time is not the issue it once was as the cache on the (modern) drive will remove much of the latency of the write, so that several 4k pages that were separate kernel writes will be committed to the platter back to back.

----------

## zeek

 *NeddySeagoon wrote:*   

> zeek,
> 
> What it boils down to is that any system running a process that wants to allocate >500MB of memory when much of it doesn't exist is broken by desigi. Any system that gets into allocating GBs of RAM in he same situation is even more broken. 
> 
> The writing swap a page at a time is not the issue it once was as the cache on the (modern) drive will remove much of the latency of the write, so that several 4k pages that were separate kernel writes will be committed to the platter back to back.

 

Thunderbird will use gigs of RAM if its available.  However if you limit the process say via /etc/security/limits.conf to 128 MB it will run just fine and use temp files to hold data.  Actually it runs better using temp files than allocating memory in the swapfile.  I don't consider Thunderbird to be broken.

Swap IO in the latest 2.6 kernel is still ~5% of your maximum IO (best case).

----------

## orlandoreis

 *NeddySeagoon wrote:*   

>  orlandoreis,
> 
> The kernel sets up the DMA engines for the transefer ... what happens next depends on the hardware.
> 
> With IDE interfaces, only one operation can be in progress on the IDE bus at a time, so access to both devices must be sequential.
> ...

 

 Ok, so if it's scsi it's going to write in parallel? hum , I'm unsure that's wright.

The raid controller will receive the data in a serialized way, how it handles it after is usually a black box, and in most cases it is parallel writing depending on the raid type (I don't have to care about the processor architecture).

I'm almost sure most raid controllers after receiving the data will have buffers and internal caches that will the forward that information in a parallel way to the hard drives. 

I don't think the whole industry of scsi raid controllers is myth  :Wink:  that it was invented to sell something that is not useful and faster.

 *NeddySeagoon wrote:*   

> 
> 
> With multiple swaps at the same priority, the kernel tries to use them all at the same time, like raid0.
> 
> With different priorities, its like linear raid0, so you are in control.
> ...

 

Trying is different then achieving. "Like" is not the same as "Equal". I think that this way of working is thought in order to maximize availability, not performance.

If I already don't care about system stability and don't care what happens next, that doesn't it mean I'm just after pure IO performance? 

There is no stripping whatsoever because if there where, if one of the swap devices went broken and the system was using witting to multiple devices it would never come back up (probably kernel panic).

 *zeek wrote:*   

> 
> 
> Of course I read the question. The answer is linux can't use a swapfile to provide Gigs of usable RAM. It just locks up. Why don't you just try it? I guarantee your system will become unstable and lockup hard and never recover. Lets analyze why it doesn't work!
> 
> Back in the day EDO RAM maxed out at 256MB/s and your hard disk xfer was 10MB/s.
> ...

 

Hi Zeek, still not the answer for my questions  :Wink:  but it's ok, I think NeddySeagoon replyed...

 *NeddySeagoon wrote:*   

> zeek,
> 
> What it boils down to is that any system running a process that wants to allocate >500MB of memory when much of it doesn't exist is broken by desigi. Any system that gets into allocating GBs of RAM in he same situation is even more broken. 
> 
> The writing swap a page at a time is not the issue it once was as the cache on the (modern) drive will remove much of the latency of the write, so that several 4k pages that were separate kernel writes will be committed to the platter back to back.

 

I know that, I just wanted to know what would happen if the situation would come to that extreme situation, how would the memory be written to swap  :Smile:  just that, well maybe 6.5 GB of swap is a little to much lolol but ok, it was just a figure of speech.

----------

## NeddySeagoon

orlandoreis,

How swap is managed and read/written is not totally under kernel control.

You cannot ignore the hardware being used when you consider what actually happens.

SCSI hardware raid dates back to the days of 8 bit SCSI buses. Such devices had a single SCSI bus with all the devices daisy chained off the same bus. SCSI allows commands to overlap but as its a bus, data can be transferred on only one disk at a time. Also, SCSI has always demanded the use of DMA, something that was grafted onto IDE much later.

----------

## lmpinto

Hi all, 

 *NeddySeagoon wrote:*   

> orlandoreis,
> 
> How swap is managed and read/written is not totally under kernel control.
> 
> You cannot ignore the hardware being used when you consider what actually happens.
> ...

 

I understand Orlando's question - and it is a question I also would like to know the answer to.

The question is: having n swap partitions, all with the same priority, how will the kernel write data to them? Assuming the kernel has, say, 100Mb to write, in 3 differente 2GB swap areas:

a) Will the kernel write 100MB in one of them, chosen randomly (provided of course there is a 100mb space available in it)? 

b) Will the kernel write some of it in each swap partition, doing some kind of load balancing? 

Of course, I understand that paralell/serialized writes depend on the kind of controller used and is not something kernel adjustable.

If the answer is b), it is clear that it is better not to use raid0 for swap partitions - in the a) case it is not that clear... 

Hope this sheds some light into this...

EDIT: 

Anyhow, I found the question for this (and it is not 42) on swapon(2):

 *Quote:*   

> 
> 
>        Swap pages are allocated from areas in priority order, highest priority first.  For areas with different priorities, a higher-priority area  is  exhausted  before
> 
>        using  a  lower-priority  area.  If two or more areas have the same priority, and it is the highest priority available, pages are allocated on a round-robin basis
> ...

 

Searching asm/page.h and checking the value for PAGE_SIZE we can see that it is 4096, so the kernel (if the swap partitions have explicit priorities) will write a 4096 block  using round-robin in each partition (of course, this is My case - i386, 32bit). YMMV. 

Thanks all  :Smile: 

----------

## orlandoreis

 *lmpinto wrote:*   

> Hi all, 
> 
>  *NeddySeagoon wrote:*   orlandoreis,
> 
> How swap is managed and read/written is not totally under kernel control.
> ...

 

I'm still unsure about this, because, if the system is writing something to swap and that swap device fails, the information that was there will be lost, if this is written in blocks the multiple swap devices won't come up after such a crash.

And the documentation on TLDP about this topic is pretty clear, the system survives crashes, if it survives then it can't be round robin in blocks, but it might allocate those blocks contiguously not in separate devices.

----------

## zeek

 *orlandoreis wrote:*   

> Hi Zeek, still not the answer for my questions  but it's ok, I think NeddySeagoon replyed...

 

Dude ... your question is something like "If I fly my remote control plane to the moon what would happen if ..." and I'm saying STOP!  You can't fly a Wally World plane to the moon!  Anyway continue with this thread.   :Shocked: 

----------

## orlandoreis

 *zeek wrote:*   

>  *orlandoreis wrote:*   Hi Zeek, still not the answer for my questions  but it's ok, I think NeddySeagoon replyed... 
> 
> Dude ... your question is something like "If I fly my remote control plane to the moon what would happen if ..." and I'm saying STOP!  You can't fly a Wally World plane to the moon!  Anyway continue with this thread.  

 

Zeek very mature, thanks... I won't continue with this. 

Neddy and lmpinto I thank you for the answer. I think this now more clear.

If this was designed to support a system where a swap device failed, then it must be not continuous writing on multiple devices, but instead it will be writing to one device until there are no more free blocks, or until what it as to write as finished on that device but this in a continuously fashion. If it's going to stripe information and one device fails, there wont be a way of getting that information back.

BY this and its I mean a load balancing/striping mechanism used for swap writing to the devices.

I started this as proof that you can use raid0 for swap is correct, as far as I can see, I don't see it is faster or slower then using raid0, it might be slower but never faster.

This is my point, from reading the TLDP documentation about swap handling by the kernel. 

http://www.tldp.org/HOWTO/Software-RAID-HOWTO-2.html#ss2.3

"There's no reason to use RAID for swap performance reasons. The kernel itself can stripe swapping on several devices, if you just give them the same priority in the /etc/fstab file"

This is statement that is making me think, and I think it is wrong... specifically "stripe swapping" which doesn't make much sense if this was designed to provide availability not performance. Load balancing ok, swap striping no.

BR to lmpinto and Neddy

Orlando

----------

## selig

I think you misunderstood that section... It discusses the advantages and disadvantages of using RAID for swap.

1. "There's no reason to use RAID for swap performance reasons. The kernel itself can stripe swapping on several devices, if you just give them the same priority in the /etc/fstab file." - clearly they mean RAID-0 (striping)

That is correct. If you lose a disk then, swapped programs will most probably get killed after trying to access the now non-existent memory space (lost swap). However, the rest of the swap space (on other disks than the failed one) will still be available for new swapping. If you lose a disk in RAID-0, swapped programs will get killed but the device will be unusable unless you re-create the RAID again without the failed disk. However, if your root partition is on RAID-0 then the whole system goes down - swap does not matter.

2. "Another reason to use RAID for swap is high availability." - I think this should have been said "Another possible reason to use RAID for swap is high availability".  - they mean RAID-1, RAID-4, RAID-5, RAID-6 or RAID-10 (any level with redundancy)

In this case, if you lose one drive, swap will be fault-tolerant, because the underlying RAID layer will protect it from the failure of one (or more) drives.

So this is the only reason why you would want to have swap on a software RAID device.

I hope it is clearer now.

You can balance performance/reliability by using in-kernel swap-striping and RAID-1 for the file systems. If one of the disks dies, swapped programs will get killed, but the system will remain running (with degraded RAID-1 array and less swap space).

----------

