Re: kernel btrfs file system wedged -- is it toast?

[pg@btrfs.list.sabi.co.UK (Peter Grandi)]

> [ ... ] announce loudly and clearly to any potential users, in
> multiple places (perhaps a key announcement in a few places
> and links to that announcement from many places,

https://btrfs.wiki.kernel.org/index.php/Gotchas#Having_many_subvolumes_can_be_very_slow

> ... DO expect to first have to learn, the hard way, of
> ... whatever special mitigations might apply in ones
> ... particular circumstances, before considering deploying
> ... btrfs into a production environment where this, or other
> ... (what other?) surprising limitations of btrfs may apply.

In computer jargon that is called "being a system engineer".

> All the prominent places that respond to the question of
> whether btrfs is ready for production use (spanning several
> years now) should if possible display this warning.

https://btrfs.wiki.kernel.org/index.php/Status
  "The table below aims to serve as an overview for the stability
  status of the features BTRFS supports. While a feature may be
  functionally safe and reliable, it does not necessarily mean
  that its useful, for example in meeting your performance
  expectations for your specific workload."

> [ ... ] Back in my day, such a performance bug would have made
> the software containing it unreleasable, _especially_ in
> software such as a major file system that is expected to
> provide reliable service, where "reliable" means both
> preserving data integrity and doing so within an order of
> magnitude of a reasonably expected time.

For the past several decades, since perhaps the Manchester MARK I
(or the ZUSE probably), it has been known to "system engineers"
and "programmers" that most features of "hardware" and "software"
have very anisotropic performance envelopes, both as to speed and
usability and reliability, and not all potentially syntactically
valid combinations of features are equally robust and excellent
under every possible workload, and indeed very few are, and it is
part of "being a system engineer" or "being a programmer" to
develop insight and experience, leading to knowledge ideally, as
to what combinations work well and which work badly.

Considering somewhat imprecise car analogies, jet engines on cars
tend not to be wholly desirable, even if syntactically valid, and
using cars to plow fields does not necessarily yield the highest
productivity, even if also syntactically valid.

General introduction about anisotropy and performance:

  http://www.sabi.co.uk/blog/15-two.html?151023#151023

In storage system and filesystems "system engineers" often have
to confront a large number of pathological cases of anisotropy,
some examples I can find quickly in my links:

  http://www.sabi.co.uk/blog/1005May.html?100520#100520
  http://www.sabi.co.uk/blog/16-one.html?160322#160322
  http://www.sabi.co.uk/blog/15-one.html?150203#150203
  http://www.sabi.co.uk/blog/12-fou.html?121218#121218
  http://www.sabi.co.uk/blog/0802feb.html?080210#080210
  http://www.sabi.co.uk/blog/0802feb.html?080216#080216

I try to keep lists of "known pathologies" of various types here:

  http://www.sabi.co.uk/Notes/linuxStor.html
  http://www.sabi.co.uk/Notes/linuxFS.html#fsHints

Even "legendary" 'ext3' has/had pathological (and common) cases:

  https://lwn.net/Articles/328370/
  https://lwn.net/Articles/328363/
  https://bugzilla.kernel.org/show_bug.cgi?id=12309
  https://news.ycombinator.com/item?id=7376750
  https://news.ycombinator.com/item?id=7377315

  https://lkml.org/lkml/2009/4/6/331
    the difference between the occasional 5+ second pause and the
    occasional 10+ second pause wasn't really all that
    interesting. They were both unusuable, and both made me kill
    the background writer almost immediately

Wisely L Torvalds writes:

  https://lkml.org/lkml/2010/11/10/233
    ext3 [f]sync sucks. We know. All filesystems suck.
    They just tend to do it in different dimensions.