All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tyler Bletsch <tyler.bletsch@gmail.com>
To: Austin S Hemmelgarn <ahferroin7@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: Btrfs is amazing! (a lack-of-bug report)
Date: Mon, 17 Aug 2015 15:18:47 -0400	[thread overview]
Message-ID: <55D23397.6090404@gmail.com> (raw)
In-Reply-To: <55D1CA1E.1060103@gmail.com>

Thanks. I will be trying raid5 in production, but "production" in this 
case just means my home file server, with btrfs snapshot+sync for all 
data and appropriate offsite non-btrfs backups for critical data. If it 
hoses up, I'll post a bug report.

Going to try to avoid LVM, since half the appeal of btrfs for me is 
getting away from the multiple duct-taped layers of indirection that I 
you get currently with ext4/MD/LVM setups.

- Tyler

On 8/17/2015 7:48 AM, Austin S Hemmelgarn wrote:
> On 2015-08-16 23:35, Tyler Bletsch wrote:
>> I just wanted to drop you guys a line to say that I am stunned with how
>> excellent btrfs is. I did some testing, and the things that it did were
>> amazing. I took a 4-disk RAID 5 and walked it all the way down to a
>> one-disk volume and back again, mixed in devices of different sizes in
>> different modes, balanced it in every direction, trashed data on drives
>> without the OS knowing, and did every other form of torture I could
>> think of, all while looping file integrity tests, and it was perfect.
>>
>> The ease of use and simplicity were great.  I was dreading having to
>> administer ZFS in order to get snapshots and other features, but now I
>> don't have to. With the exception of enterprisey features like SSD
>> intent logs and stuff, it is hands down far better than ZFS.
>>
>> Thanks for the great work!
>>
> It's nice to hear success stories for once.  I would suggest being 
> careful of using BTRFS raid5 or raid6 in production, there are 
> probably still bugs that haven't yet been discovered. Secondarily, if 
> you can deal with slightly more setup and maintenance overhead, BTRFS 
> works _very_ well on top of LVM (it makes online data migration much 
> easier, and provides easy ways to do layered RAID setups).
>
>


  reply	other threads:[~2015-08-17 19:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-17  3:35 Btrfs is amazing! (a lack-of-bug report) Tyler Bletsch
2015-08-17 11:48 ` Austin S Hemmelgarn
2015-08-17 19:18   ` Tyler Bletsch [this message]
2015-08-18 11:42     ` Austin S Hemmelgarn
2015-08-19 17:24       ` Tyler Bletsch
2015-08-20 11:52         ` Austin S Hemmelgarn
2015-08-20 12:02           ` Austin S Hemmelgarn
     [not found]             ` <CAC=t97CFWn-mVzyhL4vj6SEMZBgLwFYfszfu55neG=_+NQta=w@mail.gmail.com>
2015-08-20 18:07               ` Tyler Bletsch

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=55D23397.6090404@gmail.com \
    --to=tyler.bletsch@gmail.com \
    --cc=ahferroin7@gmail.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 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.