Re: Btrfs is amazing! (a lack-of-bug report)

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]

On 2015-08-20 07:52, Austin S Hemmelgarn wrote:
> On 2015-08-19 13:24, Tyler Bletsch wrote:
>> Thanks.  I'd consider raid6, but since I'll be backing up to a second
>> btrfs raid5 array, I think I have sufficient redundancy, since
>> equivalent to raid 5+1 on paper. I'm doing that rather than something
>> like raid10 in a single box because I want the redundancy of a second
>> physical server so I can failover in the event of a system-level
>> component failure.
>>
>> (And of course, "failover" means "continue being able to watch TV shows
>> and stuff")
>>
>> A question about what you said -- when you say people have hit bugs in
>> the raid56 code, which flavor do these bugs tend to be? Are they
>> "minding my own business and suddenly it falls over" bugs or "I tried to
>> do something weird with btrfs and it screwed up" bugs?
> More along the lines of 'I tried to do something that works fine with
> the other raid profiles and it kind of messed up the filesystem'.  In
> general, you should be safe as long as you are using at least Linux 4.0
> and the most recent version of btrfs-progs.  It's been a while since I
> saw any raid56 related bugs that caused actual data loss.  If you are
> using this on SSD's though, I would wait, there are known issues with
> DISCARD/TRIM not working correctly on btrfs right now (nothing involving
> data loss, just problems with it not properly trimming free space and
> therefore causing issues with wear-leveling), and it looks like the fix
> won't be in 4.2 as of right now.
>
>
On second thought, you might want to wait until 4.3, I just saw this thread:
http://thread.gmane.org/gmane.comp.file-systems.btrfs/47321/focus=47325


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]