From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Corrupt filesystem after hardware failure: Scrub causes kernel GPF
Date: Wed, 2 Jul 2014 05:40:48 +0000 (UTC) [thread overview]
Message-ID: <pan$84417$648ac343$a399577a$88d87100@cox.net> (raw)
In-Reply-To: 53B2DF4B.4080708@fos4x.de
Philipp Tölke posted on Tue, 01 Jul 2014 18:18:19 +0200 as excerpted:
> root@filer:~# btrfs fi df /home
> Data, single: total=9.61TiB, used=9.32TiB
> System, single: total=32.00MiB, used=1.04MiB
> Metadata, single: total=19.00GiB, used=17.37GiB
> unknown, single: total=512.00MiB, used=0.00
> root@filer:~# uname -a
> Linux filer 3.15-trunk-amd64 #1 SMP Debian
> 3.15.1-1~exp1 (2014-06-20) x86_64 GNU/Linux
> Doing a scrub scrubs over the first TiB of the filesystem and then
> caused this OOPS:
Well, it shouldn't GPF and there's obviously other more complex problems
that I won't attempt to address, but as a btrfs user and list regular I
can pick off the the low hanging fruit for you...
Btrfs scrub is designed to detect and possibly fix exactly one sort of
problem: bad checksums. Since btrfs does checksumming by default, btrfs
scrub should detect bad checksums whenever the calculated checksum
doesn't match the recorded one, but it can only /correct/ the problem if
there's another copy of the data available that still has a /valid/
checksum.
And your filesystem, as reported above, is all single, data single,
metadata single, system single, and "unknown" (kernel 3.15 split out, I
believe it was the free-space cache-tree, into its own type, but there's
no corresponding btrfs-progs release to label it, and it's simply listed
as "unknown" in current userspace) single.
Single means there's only the one copy, so scrub couldn't correct any
invalid checksums it detected anyway, altho at least it should detect
them, and it should NOT segfault.
So as I said there's obviously a more complex problem as well, well at
least one, but scrub wouldn't/couldn't fix anything for you anyway, since
the only way it can fix is if there's a second copy (single-device dup
mode or multi-device raid1/10 mode, etc), and you have single mode for
everything so there's no further copy to checksum verify and restore the
bad copy from, assuming checksum verification of the second.
--
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
prev parent reply other threads:[~2014-07-02 5:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-01 16:18 Corrupt filesystem after hardware failure: Scrub causes kernel GPF Philipp Tölke
2014-07-02 5:40 ` Duncan [this message]
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$84417$648ac343$a399577a$88d87100@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).