public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Raid 0 Swap?
Date: Tue, 05 Sep 2006 19:44:30 -0400	[thread overview]
Message-ID: <44FE0BDE.40309@tmr.com> (raw)
In-Reply-To: <44FBD08A.1080600@tls.msk.ru>

Michael Tokarev wrote:
> Marc Perkel wrote:
>> If I have two drives and I want swap to be fast if I allocate swap spam
>> on both drives does it break up the load between them? Or would it run
>> faster if I did a Raid 0 swap?
> 
> Don't do that - swap on raid0.  Don't do that.  Unless you don't care
> about your data, ofcourse.  Seriously.

Please don't spread FUD. Particularly when there are valid technical 
arguments to be made. RAID0 does increase the chance of any error, but 
it is still a very small chance. With drive failures measured in years, 
it's misleading to make it sound as if going RAID0 will result in a 
rapid failure.
> 
> If something with swap space goes wrong, God only knows what will break.

The same thing that will go wrong if your one and only swap drive goes 
bad. You get a disk error, the kernel copes with it well or badly, the 
system grinds to a halt or crashes. Flames do not come out and your cat 
will NOT get pregnant (at least from swap failure).

> It is trivial to break userspace data this way, when an app is swapped
> out and there's an error reading it from swap, its data file very likely
> to be corrupt, especially when it is interrupted during file update.
> It is probably possible to corrupt the whole filesystem this way too,
> when some kernel memory has been swapped out and is needed to write some
> parts of filesystem, but it can't be read back.

More FUD.
> 
> Ie, your swap space must be reliable.  At least not worse than your memory.
> And with striping, you've much more chances of disk failure...

You roughly double your chance, which still leaves the chances of a 
failure in one every few years. But wait, there more! Unless you use the 
drive just for swapping, the chances are that an error will happen 
somewhere else on the disk.
> 
> Yes it sounds very promising at first, to let kernel stripe swap space,
> for faster operations.  But hell, first, try to avoid swappnig in the
> first place, by installing appropriate amount memory which is cheap
> nowadays, so there will be just no need for swapping.  And when it's
> done, it's not relevant anymore whenever your swap space is fast or
> not.  But make it *reliable*.

The truth is that striping may not make swap faster, because (a) the 
transfer rate may or may not be faster, but (b) the seek time will be 
the slowest seek on any drive used. There's a good technical reason, 
RAID0 may not help.

However, RAID1 will help, again not because it's more reliable, but 
because when you do a swap in (that's where you really feel swap delay), 
you increase the chance that there will be a copy of your data on a 
drive which isn't busy.

So the correct answer is not related to reliability problems, which are 
rare, but performance problems, which is why you did the RAID in the 
first place.

Final note: if you are building a really reliable system, PAID6 on all 
data, redundant power supplies (the highest point of total failure), 
then you should go to RAID0 for swap, on multiple controllers, 
preferably one drives in different enclosures. RAID6 for swap sucks 
rocks off the bottom of the ocean, three way RAID1 performs well even 
after a one drive failure.

-- 
Bill Davidsen <davidsen@tmr.com>
   Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.

  parent reply	other threads:[~2006-09-05 23:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-03 22:43 Raid 0 Swap? Marc Perkel
2006-09-04  0:16 ` Bernd Eckenfels
2006-09-04  7:06 ` Michael Tokarev
2006-09-04  9:47   ` Helge Hafting
2006-09-04 10:29     ` Michael Tokarev
2006-09-04 10:46       ` Jan Engelhardt
2006-09-18  9:50         ` Denis Vlasenko
     [not found]           ` <e1a7ee0c0612272106y5e22dd21uc3f2fde567ab7532@mail.gmail.com>
2006-12-28  9:13             ` Jan Engelhardt
2007-01-01  2:08               ` Bill Davidsen
2006-09-04 15:29   ` Valdis.Kletnieks
2006-09-04 20:06     ` Bernd Eckenfels
2006-09-05 13:37       ` Helge Hafting
2006-09-05 23:44   ` Bill Davidsen [this message]
2006-09-06  6:53     ` Michael Tokarev
2006-09-06 17:21     ` Kyle Moffett
     [not found] <6R8WW-70v-7@gated-at.bofh.it>
     [not found] ` <6RgKP-1OA-9@gated-at.bofh.it>
2006-09-04 13:21   ` Bodo Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44FE0BDE.40309@tmr.com \
    --to=davidsen@tmr.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjt@tls.msk.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox