From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Andrej Manduch <amanduch@gmail.com>,
linux-btrfs <linux-btrfs@vger.kernel.org>
Cc: M G Berberich <btrfs@oss.m-berberich.de>
Subject: Re: Questions on using BtrFS for fileserver
Date: Wed, 20 Aug 2014 11:23:57 -0400 [thread overview]
Message-ID: <53F4BD8D.9090203@gmail.com> (raw)
In-Reply-To: <53F3C3C7.8020303@gmail.com>
On 08/19/2014 05:38 PM, Andrej Manduch wrote:
> Hi,
>
> On 08/19/2014 06:21 PM, M G Berberich wrote:> · Are there any
> reports/papers/web-pages about BtrFS-systems this size
>> in use? Praises, complains, performance-reviews, whatever…
>
> I don't know about papers or benchmarks but few weeks ago there was a
> guy who has problem with really long mounting with btrfs with similiar size.
> https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg36226.html
>
> And I would not recommend 3TB disks. *I'm not btrfs dev* but as far as I
> know there is a quite different between rebuilding disk on real RAID and
> btrfs RAID. The problem is btrfs has RAID on filesystem level not on hw
> level so there is bigger mechanical overheat on drives and thus it take
> significantli longer than regular RAID.
It really suprises me that so many people come to this conclusion, but
maybe they don't provide as much slack space as I do on my systems. In
general you will only have a longer rebuild on BTRFS than on hardware
RAID if the filesystem is more than about 50% full. On my desktop array
(4x 1TB disks using BTRFS RAID10), I've replaced disks before and it
took less than an hour for the operation. Of course that array is
usually not more than 10% full. Interestingly, it took less time to
rebuild this array the last time I lost a disk than it did back when it
was 3x 1TB disks in a BTRFS RAID1, so things might improve overall with
a larger number of disks in the array.
next prev parent reply other threads:[~2014-08-20 15:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-19 16:21 Questions on using BtrFS for fileserver M G Berberich
2014-08-19 16:56 ` Kyle Manna
2014-08-19 19:05 ` Austin S Hemmelgarn
2014-08-19 21:09 ` Mitch Harder
2014-08-19 21:38 ` Andrej Manduch
2014-08-20 15:23 ` Austin S Hemmelgarn [this message]
2014-08-19 21:50 ` Roman Mamedov
2014-08-20 3:22 ` Marc MERLIN
2014-08-21 20:20 ` Andrew E. Mileski
-- strict thread matches above, loose matches on Subject: below --
2014-08-20 9:23 Tomasz Chmielewski
2014-08-20 13:41 ` Benjamin O'Connor
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=53F4BD8D.9090203@gmail.com \
--to=ahferroin7@gmail.com \
--cc=amanduch@gmail.com \
--cc=btrfs@oss.m-berberich.de \
--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).