From: Psalle <psalleetsile@gmail.com>
To: Mackenzie Meyer <snackmasterx@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: BTRFS RAM requirements, RAID 6 stability/write holes and expansion questions
Date: Tue, 9 Feb 2016 15:07:02 +0100 [thread overview]
Message-ID: <56B9F286.9070408@gmail.com> (raw)
In-Reply-To: <CAKr9ZMFwxZ01gw7SAyFReOfXFb=hVzUXNgYoGcUc2xzLuo+9mg@mail.gmail.com>
On 05/02/16 20:36, Mackenzie Meyer wrote:
> Hello,
>
> I've tried checking around on google but can't find information
> regarding the RAM requirements of BTRFS and most of the topics on
> stability seem quite old.
To keep my answer short: every time I've tried (offline) deduplication
or raid5 pools I've ended with borked filesystems. Last attempt was
about a year ago. Given that the pages you mention looked the same by
then, I'd stay away of raid56 for anything but testing purposes. I
haven't read anything about raid5 that increases my confidence in it
recently (i.e. post 3.19 kernels). Dedup, OTOH, I don't know. What I
used were third-party (I think?) things so the fault may have rested on
them and not btrfs (does that makes sense?)
I'm building a new small raid5 pool as we speak, though, for throw-away
data, so I hope to be favourably impressed.
Cheers.
> So first would be memory requirements, my goal is to use deduplication
> and compression. Approximately how many GB of RAM per TB of storage
> would be recommended?
>
> RAID 6 write holes?
> The BTRFS wiki states that parity might be inconsistent after a crash.
> That said, the wiki page for RAID 5/6 doesn't look like it has much
> recent information on there. Has this issue been addressed and if not,
> are there plans to address the RAID write hole issue? What would be a
> recommended workaround to resolve inconsistent parity, should an
> unexpected power down happen during write operations?
>
> RAID 6 stability?
> Any articles I've tried looking for online seem to be from early 2014,
> I can't find anything recent discussing the stability of RAID 5 or 6.
> Are there or have there recently been any data corruption bugs which
> impact RAID 6? Would you consider RAID 6 safe/stable enough for
> production use?
>
> Do you still strongly recommend backups, or has stability reached a
> point where backups aren't as critical? I'm thinking from a data
> consistency standpoint, not a hardware failure standpoint.
>
> I plan to start with a small array and add disks over time. That said,
> currently I have mostly 2TB disks and some 3TB disks. If I replace all
> 2TB disks with 3TB disks, would BTRFS then start utilizing the full
> 3TB capacity of each disk, or would I need to destroy and rebuild my
> array to benefit from the larger disks?
>
>
> Thanks!
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2016-02-09 14:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 19:36 BTRFS RAM requirements, RAID 6 stability/write holes and expansion questions Mackenzie Meyer
2016-02-06 8:43 ` Duncan
2016-02-09 14:07 ` Psalle [this message]
2016-02-09 20:39 ` Chris Murphy
2016-02-10 13:57 ` Austin S. Hemmelgarn
2016-02-10 19:06 ` Chris Murphy
2016-02-10 19:59 ` Austin S. Hemmelgarn
2016-02-11 14:14 ` Goffredo Baroncelli
2016-02-11 14:58 ` Austin S. Hemmelgarn
2016-02-11 17:29 ` Chris Murphy
2016-02-10 10:16 ` Psalle
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=56B9F286.9070408@gmail.com \
--to=psalleetsile@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=snackmasterx@gmail.com \
/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).