From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: "Alejandro R. Mosteo" <alejandro@mosteo.com>,
linux-btrfs@vger.kernel.org
Subject: Re: Fwd: dup vs raid1 in single disk
Date: Thu, 19 Jan 2017 12:06:32 -0500 [thread overview]
Message-ID: <96508d61-719e-6103-ea16-6be1fdb0aca4@gmail.com> (raw)
In-Reply-To: <CACNDjuw3GqkCggUqim==Y+xj=bnL93wwdx26denvQaD4tFf7yw@mail.gmail.com>
On 2017-01-19 11:39, Alejandro R. Mosteo wrote:
> Hello list,
>
> I was wondering, from a point of view of data safety, if there is any
> difference between using dup or making a raid1 from two partitions in
> the same disk. This is thinking on having some protection against the
> typical aging HDD that starts to have bad sectors.
>
> On a related note, I see this caveat about dup in the manpage:
>
> "For example, a SSD drive can remap the blocks internally to a single
> copy thus deduplicating them. This negates the purpose of increased
> redunancy (sic) and just wastes space"
>
> SSDs failure modes are different (more an all or nothing thing, I'm
> told) so it wouldn't apply to the use case above, but I'm curious for
> curiosity's sake if there would be any difference too.
On a traditional HDD, there actually is a reasonable safety benefit to
using 2 partitions in raid1 mode over using dup mode. This is because
most traditional HDD firmware still keeps the mapping of physical
sectors to logical sectors mostly linear, so having separate partitions
will (usually) mean that the two copies are not located near each other
on physical media. A similar but weaker version of the same effect can
be achieved by using the 'ssd_spread' mount option, but I would not
suggest relying on that. This doesn't apply to hybrid drives (because
they move stuff around however they want like SSD's), or SMR drives
(because they rewrite large portions of the disk when one place gets
rewritten, so physical separation of the data copies doesn't get you as
much protection).
For most SSD's, there is no practical benefit because the FTL in the SSD
firmware generally maps physical sectors to logical sectors in whatever
arbitrary way it wants, which is usually not going to be linear.
As far as failure modes on an SSD, you usually see one of two things
happen, either the whole disk starts acting odd (or stops working), or
individual blocks a few MB in size (which seem to move around the disk
as they get over-written) start behaving odd. The first case is the
firmware or primary electronics going bad, while the second is
individual erase blocks going bad. As a general rule, SSD's will run
longer as they're going bad than HDD's will, but in both cases you
should look at replacing the device once you start seeing the error
counters going up consistently over time (or if you see them suddenly
jump to a much higher number).
next prev parent reply other threads:[~2017-01-19 17:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CACNDjuzntG5Saq5HHNeDUmq-=28riKAerkO=CD=zAW-QofbKSg@mail.gmail.com>
2017-01-19 16:39 ` Fwd: dup vs raid1 in single disk Alejandro R. Mosteo
2017-01-19 17:06 ` Austin S. Hemmelgarn [this message]
2017-01-19 18:23 ` Roman Mamedov
2017-01-19 20:02 ` Austin S. Hemmelgarn
2017-01-21 16:00 ` Alejandro R. Mosteo
2017-02-07 22:28 ` Kai Krakow
2017-02-07 22:46 ` Hans van Kranenburg
2017-02-08 0:39 ` Dan Mons
2017-02-08 9:14 ` Alejandro R. Mosteo
2017-02-08 13:02 ` Austin S. Hemmelgarn
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=96508d61-719e-6103-ea16-6be1fdb0aca4@gmail.com \
--to=ahferroin7@gmail.com \
--cc=alejandro@mosteo.com \
--cc=linux-btrfs@vger.kernel.org \
/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).