linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Juan Alberto Cirez <jacirez@rdcsafety.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Add device while rebalancing
Date: Tue, 26 Apr 2016 07:11:12 -0400	[thread overview]
Message-ID: <571F4CD0.9050004@gmail.com> (raw)
In-Reply-To: <CAHaPQf03yMAxMZRa=zr3Fjh_B+-ggwwuzRFwDsUyK3t=jW2WFw@mail.gmail.com>

On 2016-04-26 06:50, Juan Alberto Cirez wrote:
> Thank you guys so very kindly for all your help and taking the time to
> answer my question. I have been reading the wiki and online use cases
> and otherwise delving deeper into the btrfs architecture.
>
> I am managing a 520TB storage pool spread across 16 server pods and
> have tried several methods of distributed storage. Last attempt was
> using Zfs as a base for the physical bricks and GlusterFS as a glue to
> string together the storage pool. I was not satisfied with the results
> (mainly Zfs). Once I have run btrfs for a while on the test server
> (32TB, 8x 4TB HDD RAID10) for a while I will try btrfs/ceph
For what it's worth, GlusterFS works great on top of BTRFS.  I don't 
have any claims to usage in production, but I've done _a lot_ of testing 
with it because we're replacing one of our critical file servers at work 
with a couple of systems set up with Gluster on top of BTRFS, and I've 
been looking at setting up a small storage cluster at home using it on a 
couple of laptops I have which have non-functional displays.  Based on 
what I've seen, it appears to be rock solid with respect to the common 
failure modes, provided you use something like raid1 mode on the BTRFS 
side of things.

  reply	other threads:[~2016-04-26 11:12 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-22 20:36 Add device while rebalancing Juan Alberto Cirez
2016-04-23  5:38 ` Duncan
2016-04-25 11:18   ` Austin S. Hemmelgarn
2016-04-25 12:43     ` Duncan
2016-04-25 13:02       ` Austin S. Hemmelgarn
2016-04-26 10:50         ` Juan Alberto Cirez
2016-04-26 11:11           ` Austin S. Hemmelgarn [this message]
2016-04-26 11:44             ` Juan Alberto Cirez
2016-04-26 12:04               ` Austin S. Hemmelgarn
2016-04-26 12:14                 ` Juan Alberto Cirez
2016-04-26 12:44                   ` Austin S. Hemmelgarn
2016-04-27  0:58               ` Chris Murphy
2016-04-27 10:37                 ` Duncan
2016-04-27 11:22                 ` Austin S. Hemmelgarn
2016-04-27 15:58                   ` Juan Alberto Cirez
2016-04-27 16:29                     ` Holger Hoffstätte
2016-04-27 16:38                       ` Juan Alberto Cirez
2016-04-27 16:40                         ` Juan Alberto Cirez
2016-04-27 17:23                           ` Holger Hoffstätte
2016-04-27 23:19                   ` Chris Murphy
2016-04-28 11:21                     ` 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=571F4CD0.9050004@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=jacirez@rdcsafety.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).