From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Encountered kernel bug#72811. Advice on recovery?
Date: Sun, 16 Apr 2017 15:09:51 +0000 (UTC) [thread overview]
Message-ID: <pan$2f4cc$c770dd52$f6a80ea0$7430a310@cox.net> (raw)
In-Reply-To: 4868ddee9604c8b5aa208580fa01b7e7@rqc.ru
Marat Khalili posted on Sun, 16 Apr 2017 11:01:00 +0300 as excerpted:
>> Even making such a warning conditional on kernel version is
>> problematic, because many distros backport major blocks of code,
>> including perhaps btrfs fixes, and the nominally 3.14 or whatever
>> kernel may actually be running btrfs and other fixes from 4.14 or
>> later, by the time they actually drop support for whatever LTS distro
>> version and quit backporting fixes.
>
> This information could be stored in kernel and made available for
> usermode tools via some proc file. This would be very useful
> _especially_ considering backporting. Raid56 could be fixed already (or
> not) by the time it is implemented, but no doubt there will still be
> other highly experimental capabilities judging by how things go. And
> this feature itself could easily be backported.
What they /could/ do would be something very similar to what they already
did for the free-space-tree (as opposed to the free-space-cache, the
original and still default implementation).
There was a critical bug in the early implementations of free-space-
tree. But btrfs has incompatibility/feature flags for a reason, and they
set it up in such a way that the flaw could be detected and fixed.
In theory they could grab another bit from it and make that raid56v2, or
something similar, and if the raid56 flag is there but not raid56v2,
warn, etc.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2017-04-16 15:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-13 18:49 Encountered kernel bug#72811. Advice on recovery? Ank Ular
2017-04-14 3:47 ` Duncan
2017-04-14 16:56 ` ronnie sahlberg
2017-04-15 1:41 ` Duncan
2017-04-15 23:28 ` Duncan
2017-04-15 23:32 ` Hugo Mills
2017-04-16 8:01 ` Marat Khalili
2017-04-16 15:09 ` Duncan [this message]
2017-04-14 16:46 ` Chris Murphy
2017-04-14 16:58 ` Chris Murphy
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='pan$2f4cc$c770dd52$f6a80ea0$7430a310@cox.net' \
--to=1i5t5.duncan@cox.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox