Re: Is stability a joke?

[Waxhead <waxhead@online.no>]

Zoiled wrote:
> Chris Mason wrote:
>>
>>
>> On 09/11/2016 04:55 AM, Waxhead wrote:
>>> I have been following BTRFS for years and have recently been 
>>> starting to
>>> use BTRFS more and more and as always BTRFS' stability is a hot topic.
>>> Some says that BTRFS is a dead end research project while others claim
>>> the opposite.
>>>
>>> Taking a quick glance at the wiki does not say much about what is safe
>>> to use or not and it also points to some who are using BTRFS in 
>>> production.
>>> While BTRFS can apparently work well in production it does have some
>>> caveats, and finding out what features is safe or not can be 
>>> problematic
>>> and I especially think that new users of BTRFS can easily be bitten if
>>> they do not do a lot of research on it first.
>>>
>>> The Debian wiki for BTRFS (which is recent by the way) contains a bunch
>>> of warnings and recommendations and is for me a bit better than the
>>> official BTRFS wiki when it comes to how to decide what features to 
>>> use.
>>>
>>> The Nouveau graphics driver have a nice feature matrix on it's webpage
>>> and I think that BTRFS perhaps should consider doing something like 
>>> that
>>> on it's official wiki as well
>>>
>>> For example something along the lines of .... (the statuses are taken
>>> our of thin air just for demonstration purposes)
>>>
>>
>> The out of thin air part is a little confusing, I'm not sure if 
>> you're basing this on reports you've read?
>>
> Well to be honest I used "whatever I felt was right" more or less in 
> that table and as I wrote it was only for demonstration purposes only 
> to show how such a table could look.
>> I'm in favor flagged device replace with raid5/6 as not supported 
>> yet. That seems to be where most of the problems are coming in.
>>
>> The compression framework shouldn't allow one to work well with the 
>> other unusable.
> Ok good to know , however from the Debian wiki as well as the link to 
> the mailing list only LZO compression are mentioned (as far as I 
> remember) and I have no idea myself how much difference there is 
> between LZO and the ZLIB code,
>>
>> There were  problems with autodefrag related to snapshot-aware 
>> defrag, so Josef disabled the snapshot aware part.
>>
>> In general, we put btrfs through heavy use at facebook.  The crcs 
>> have found serious hardware problems the other filesystems missed.
>>
>> We've also uncovered performance problems and a some serious bugs, 
>> both in btrfs and the other filesystems.  With the other filesystems 
>> the fixes were usually upstream (doubly true for the most serious 
>> problems), and with btrfs we usually had to make the fixes ourselves.
>>
>> -chris
>> -- 
>> 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
>>
> I'll just pop this in here since I assume most people will read the 
> response from your comment:
>
> I think I made my point. The wiki lacks some good documentation on 
> what's safe to use and what's not. Yesterday I (Svein Engelsgjerd) did 
> put a table on the main wiki and someone have moved that away to a 
> status page and also improved the layout a bit. It is a tad more 
> complex than my version, but also a lot better for the slightly more 
> advanced users and it actually made my view on things a bit clearer as 
> well.
>
> I am glad that I by bringing this up (hopefully) contributed slightly 
> to improving the documentation a tiny bit! :)
>
> -- 
> 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
>
>
Just for the record - sorry for using my "crap mail" - I sometimes 
forget to change to the correct sender. I am therefore Svein Engelsgjerd 
a.k.a. Waxhead a.k.a. "Zoiled" :)
...sorry for the confusion