From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: BTRFS critical (device dm-0): invalid dir item name len: 45389
Date: Thu, 4 Sep 2014 22:06:04 +0000 (UTC) [thread overview]
Message-ID: <pan$68621$5f405fb4$84800416$5de9f6db@cox.net> (raw)
In-Reply-To: CANg_oxxmR+qkSfZeVYK5dF1HnbSJapEF1tZ+3-9ij5hq7d2E=w@mail.gmail.com
john terragon posted on Thu, 04 Sep 2014 07:30:37 +0200 as excerpted:
> dm-0 is the first dmcrypt device of a pair on which I have
> btrfs in RAID0 (btrfs native raid).
>
> I assume that a scrub would not do any good since it seems to be
> related to btrfs data structures more than actual file data[.]
On btrfs raid0 scrub can't fix anything anyway, tho it might give you a
bit more information about problems it finds.
The only thing scrub does is verify block checksums and if there's a
second copy (as there is in single-device dup mode for metadata, and
multi-device raid1 and raid10 modes, raid5/6 scrub is still broken),
verify its checksum and assuming it verifies, rewrite the bad copy with
the new copy. The same thing happens in normal operation if btrfs
happens to come across the problem, but scrub gives you a way to
systematically check the entire filesystem.
If there's no valid second copy, either because the block was in a single-
copy chunk (btrfs raid0 or single mode) or because the second copy is bad
or the device it was on is missing (raid1/10 with a missing device),
there's obviously no good copy to overwrite the bad one with, so the
problem cannot be fixed. However, if it's in a data chunk, scrub should
log the file it was part of. For metadata you simply get a number, and
have to use btrfs debugging tools to figure out what's affected.
Since you said you're using btrfs raid0 mode, there's no second copy, so
scrub might find bad checksums and give you a bit of additional
information about what's affected, but it can never fix them, because
there's no second copy to fix them from. Scrub for btrfs raid0 (or
single, and scrub for raid56 modes remains broken) mode is thus purely
diagnostics, no possibility of fix, at least from scrub.
--
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-09-04 22:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-04 5:30 BTRFS critical (device dm-0): invalid dir item name len: 45389 john terragon
2014-09-04 13:03 ` john terragon
2014-09-04 22:26 ` Duncan
2014-09-05 0:20 ` john terragon
2014-09-05 1:41 ` Chris Murphy
2014-09-05 2:07 ` Duncan
2014-09-05 3:20 ` Chris Murphy
2014-09-05 2:05 ` Duncan
2014-09-04 22:06 ` 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$68621$5f405fb4$84800416$5de9f6db@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).