From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs fails to mount after power outage
Date: Fri, 13 Apr 2018 05:46:51 +0000 (UTC) [thread overview]
Message-ID: <pan$23865$85130c9$51fc5bf6$31d44e36@cox.net> (raw)
In-Reply-To: db34f571-2a31-5a0a-9f8d-e55a9b579753@gmx.com
Qu Wenruo posted on Thu, 12 Apr 2018 07:25:15 +0800 as excerpted:
> On 2018年04月11日 23:33, Tom Vincent wrote:
>> My btrfs laptop had a power outage and failed to boot with "parent
>> transid verify failed..." errors. (I have backups).
>
> Metadata corruption, again.
>
> I'm curious about what's the underlying disk?
> Is it plain physical device? Or have other layers like bcache/lvm?
>
> And what's the physical device? SSD or HDD?
The last line of his message said progs 4.15, kernel 4.15.15, NVMe, so
it's SSD.
Another important question, tho, if not for this instance, than for
easiest repair the next time something goes wrong:
What mount options? In particular, is the discard option used (and of
course I'm assuming nothing as insane as nobarrier)?
Because as came up on a recent thread here...
Btrfs normally keeps a few generations of root blocks around and one
method of recovery is using the usebackuproot (or the deprecated
recovery) option to try to use them if the current root is bad. But
apparently nobody considered how discard and the backup roots would
interact, and there's (currently) nothing keeping them from being marked
for discard just as soon as the next new root becomes current. Now some
device firmware batches up discards as garbage-collection that can be
done periodically, when the number of unwritten erase-blocks gets low,
but others do discards basically immediately, meaning those backup roots
are lost effectively immediately, making the usebackuproots recovery
feature worthless. =:^(
Not a tradeoff that would occur to most people, obviously including the
btrfs devs that setup btrfs discard behavior, considering whether to
enable discard or not. =:^(
But it's definitely a tradeoff to consider once you /do/ know it!
Presumably that'll be fixed at some point, but not being a dev nor
knowing how complex the fix might be, I won't venture a guess as to when,
or whether it'd be considered stable-kernel backport material or not,
when it happens.
--
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:[~2018-04-13 5:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-11 15:33 btrfs fails to mount after power outage Tom Vincent
2018-04-11 23:25 ` Qu Wenruo
2018-04-13 5:46 ` Duncan [this message]
2018-04-16 16:07 ` Tom Vincent
2018-04-17 0:31 ` Qu Wenruo
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$23865$85130c9$51fc5bf6$31d44e36@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;
as well as URLs for NNTP newsgroup(s).