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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
