From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Hugo Mills <hugo@carfax.org.uk>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Question about a specific error.
Date: Tue, 2 Feb 2016 08:00:49 -0500 [thread overview]
Message-ID: <56B0A881.5080403@gmail.com> (raw)
In-Reply-To: <20160201202112.GB8313@carfax.org.uk>
On 2016-02-01 15:21, Hugo Mills wrote:
> On Mon, Feb 01, 2016 at 02:44:24PM -0500, Austin S. Hemmelgarn wrote:
>> In the process of trying to debug issues I'm having on one of my
>> systems with a new kernel version, I decided to do a dry run check on
>> the root filesystem. 'btrfs check' returned a bunch of lines like:
>>
>> root 257 inode XXXXXX errors 2000, link count wrong
>> unresolved ref dir YYYYY index 53 namelen 3 name LOG filetype 0 errors 3, no dir item, no dir index
>>
>> I got about 20 messages like this with varying values for everything
>> except the filetype and error counts. Based on what I can tell, these
>> look like orphaned inodex, but I'm not certain.
>> Is it safe to tell BTRFS to try and fix these errors?
>
> Yes, those are errors I'd expect btrfs check --repair to handle
> properly.
>
OK, it looks like things were fixed safely, but I'm not 100% certain
that it fixed things the way it should have. All of the files it
reported got moved to /lost+found (which makes me think it thought they
were orphaned items), but none of the files themselves showed any issues
in regular usage (they were all perfectly visible beforehand in the
regular directory structure, and there were no errors accessing them).
On top of that, it pulled out two different versions of each one, one
from more than a year ago, and one current version. I think btrfs check
may have gotten either confused or over-zealous and just decided it
needed to pull out the current, perfectly fine versions of the files as
well.
next prev parent reply other threads:[~2016-02-02 13:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-01 19:44 Question about a specific error Austin S. Hemmelgarn
2016-02-01 20:21 ` Hugo Mills
2016-02-01 20:37 ` Austin S. Hemmelgarn
2016-02-01 21:31 ` Hugo Mills
2016-02-02 13:00 ` Austin S. Hemmelgarn [this message]
2016-02-03 21:17 ` Chris Murphy
2016-02-03 21:27 ` Hugo Mills
2016-02-04 12:18 ` Austin S. Hemmelgarn
2016-02-04 10:56 ` Duncan
2016-02-01 20:27 ` Chris Murphy
2016-02-01 20:35 ` Austin S. Hemmelgarn
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=56B0A881.5080403@gmail.com \
--to=ahferroin7@gmail.com \
--cc=hugo@carfax.org.uk \
--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).