From: Marc MERLIN <marc@merlins.org>
To: Brendan Hide <brendan@swiftspirit.co.za>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Is metadata redundant over more than one drive with raid0 too?
Date: Sun, 4 May 2014 00:24:20 -0700 [thread overview]
Message-ID: <20140504072420.GJ9061@merlins.org> (raw)
In-Reply-To: <5365E4CF.3050405@swiftspirit.co.za>
On Sun, May 04, 2014 at 08:57:19AM +0200, Brendan Hide wrote:
> Hi, Marc
>
> Raid0 is not redundant in any way. See inline below.
Thanks for clearing things up.
> >But now I have 2 questions
> >1) btrfs has two copies of all metadata on even a single drive, correct?
>
> Only when *specifically* using -m dup (which is the default on a
> single non-SSD device), will there be two copies of the metadata
> stored on a single device. This is not recommended when using
Ah, so -m dup is default like I thought, but not on SSD?
Ooops, that means that my laptop does not have redundant metadata on its
SSD like I thought. Thanks for the heads up.
Ah, I see the man page now "This is because SSDs can remap blocks
internally so duplicate blocks could end up in the same erase block
which negates the benefits of doing metadata duplication."
> multiple devices as it means one device failure will likely cause
> critical loss of metadata.
That's the part where I'm not clear:
What's the difference between -m dup and -m raid1
Don't they both say 2 copies of the metadata?
Is -m dup only valid for a single drive, while -m raid1 for 2+ drives?
> >If so, and I have a -d raid0 -m raid0 filesystem, are both copies of the
> >metadata on the same drive or is btrfs smart enough to spread out
> >metadata copies so that they're not on the same drive?
>
> This will mean there is only a single copy, albeit striped across
> the drives.
Ok, so -m raid0 only means a single copy of metadata, thanks for
explaining.
> good for redundancy. A total failure of a single device will mean
> any large files will be lost and only files smaller than the default
> per-disk stripe width (I believe this used to be 4K and is now 16K -
> I could be wrong) stored only on the remaining disk will be
> available.
Gotcha, thanks for confirming, so -m raid1 -d raid0 really only protects
against metadata corruption or a single block loss, but otherwise if you
lost a drive in a 2 drive raid0, you'll have lost more than just half
your files.
> The scenario you mentioned at the beginning, "if I lose a drive,
> I'll still have full metadata for the entire filesystem and only
> missing files" is more applicable to using "-m raid1 -d single".
> Single is not geared towards performance and, though it doesn't
> guarantee a file is only on a single disk, the allocation does mean
> that the majority of all files smaller than a chunk will be stored
> on only one disk or the other - not both.
Ok, so in other words:
-d raid0: if you one 1 drive out of 2, you may end up with small files
and the rest will be lost
-d single: you're more likely to have files be on one drive or the
other, although there is no guarantee there either.
Correct?
Thanks,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
next prev parent reply other threads:[~2014-05-04 7:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-03 23:27 Is metadata redundant over more than one drive with raid0 too? Marc MERLIN
2014-05-04 6:57 ` Brendan Hide
2014-05-04 7:24 ` Marc MERLIN [this message]
2014-05-04 7:44 ` Brendan Hide
2014-05-05 1:27 ` Marc MERLIN
2014-05-06 19:05 ` Duncan
2014-05-06 19:39 ` Duncan
2014-05-05 0:46 ` Daniel Lee
2014-05-05 5:06 ` Marc MERLIN
2014-05-06 17:16 ` Duncan
2014-05-07 8:18 ` raid0 vs single, and should we allow -mdup by default on SSDs? Marc MERLIN
2014-05-07 8:29 ` Hugo Mills
2014-05-07 8:52 ` Marc MERLIN
2014-05-07 22:39 ` Mitch Harder
2014-05-04 21:49 ` Is metadata redundant over more than one drive with raid0 too? Duncan
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=20140504072420.GJ9061@merlins.org \
--to=marc@merlins.org \
--cc=brendan@swiftspirit.co.za \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.