linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Doug Ledford <dledford@redhat.com>
To: Roberto Spadim <roberto@spadim.com.br>
Cc: Linux-RAID <linux-raid@vger.kernel.org>
Subject: Re: RFC swap over raid1
Date: Fri, 02 Aug 2013 11:21:52 -0400	[thread overview]
Message-ID: <51FBCE90.2030603@redhat.com> (raw)
In-Reply-To: <CAH3kUhH-uc-tXitqZ=xuUYz5A8GY_+dhy+LnvvZTR9gSUJ0Y4A@mail.gmail.com>

On 08/01/2013 10:01 PM, Roberto Spadim wrote:
> the point is: using swap at two partitions / disks, is "better" than
> using a swap over a md raid1? (or any other level?)

That depends on your goals.  If your goal is for your system to be
resilient to disk failure, and you've put your filesystems on a raid
device to be tolerant of failure, then your swap needs to be on one too
or else you are undermining the work you did on your filesystems.  If
that's not the case, then two swap partitions gets you twice the
capacity, but slightly lower performance, than a raid1 swap device over
the same partitions due to the fact that when you are swapping out,
performance is about the same, but when swapping in, we can load balance
reads and increase performance.  Of course, you only have half as much
swap this way.

> other point is... swap have a badblock feature? i think it's not
> linux-raid but linux-vm or something like it...
> for example if i'm using a disk and swap find a badblock, it will use
> it? does swap handle bad blocks? it remove the device? continue using
> it? or change the device priority?

The swap layer does not do bad blocks *while in use*.  You can pass in a
list of badblocks when creating the device, in which case it won't ever
use those blocks.  However, if a block *goes* bad while in use, and we
get a read error, then whatever application was trying to page in that
page of swap is going to get killed due to an unhandled page fault.


  parent reply	other threads:[~2013-08-02 15:21 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-01 22:11 RFC swap over raid1 Roberto Spadim
2013-08-01 23:04 ` Doug Ledford
2013-08-02  2:01   ` Roberto Spadim
2013-08-02  7:46     ` Stan Hoeppner
2013-08-02 14:21       ` Roberto Spadim
2013-08-02 15:40         ` Doug Ledford
2013-08-02 15:59           ` Roberto Spadim
2013-08-02 16:35             ` Doug Ledford
2013-08-02 16:40               ` Roberto Spadim
2013-08-02 16:50                 ` Doug Ledford
2013-08-02 17:29                   ` Roberto Spadim
2013-08-02 17:35                     ` Doug Ledford
2013-08-02 17:38                       ` Roberto Spadim
2013-08-02 18:26                     ` keld
2013-08-02 18:39                       ` Roberto Spadim
2013-08-02 21:31                         ` Keld Jørn Simonsen
2013-08-02 15:21     ` Doug Ledford [this message]
2013-08-02  1:59 ` Brad Campbell
2013-08-02  2:02   ` Roberto Spadim
2013-08-02  2:18     ` Brad Campbell
2013-08-02  2:21       ` Roberto Spadim

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=51FBCE90.2030603@redhat.com \
    --to=dledford@redhat.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=roberto@spadim.com.br \
    /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;
as well as URLs for NNTP newsgroup(s).