From: Stan Hoeppner <stan@hardwarefreak.com>
To: Roberto Spadim <roberto@spadim.com.br>
Cc: Doug Ledford <dledford@redhat.com>,
Linux-RAID <linux-raid@vger.kernel.org>
Subject: Re: RFC swap over raid1
Date: Fri, 02 Aug 2013 02:46:16 -0500 [thread overview]
Message-ID: <51FB63C8.2090300@hardwarefreak.com> (raw)
In-Reply-To: <CAH3kUhH-uc-tXitqZ=xuUYz5A8GY_+dhy+LnvvZTR9gSUJ0Y4A@mail.gmail.com>
On 8/1/2013 9:01 PM, Roberto Spadim wrote:
> 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?
I believe you're thinking of "mkswap -c":
"Check the device (if it is a block device) for bad blocks before
creating the swap area. If any are found, the count is printed."
This simply tells you if bad blocks are found during mkswap, and how
many. It doesn't tell you the locations of the blocks nor attempt to
remap them. It's informational only. Remedial action is left to the user.
I'm not aware of any code in the mm or block layer that transparently
handles bad block management, nor code that simply tracks bad blocks to
avoid using them. If there were such a patch, it would not apply simply
to swap, but to the entire block layer. I've not heard of any such
thing in recent development. If this was included in the block layer
you'd surely have seen emails about it on the linux-raid list, as the
current md code that deals with bad blocks would have needed rewriting
to interface with any new generic interface in the block layer.
So if you're worried about your swap partition sitting on potentially
bad blocks you'll want to have one form or another of redundant md
device sitting under that swap partition.
However, you stated you're using enterprise class drives. These are
usually pretty good about remapping bad blocks on the fly, and have much
larger reserved block pools than consumer drives for remapping use, so
this may simply be a non-issue.
--
Stan
next prev parent reply other threads:[~2013-08-02 7:46 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 [this message]
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
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=51FB63C8.2090300@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=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).