All of lore.kernel.org
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Vincent Olivier <vincent@up4.com>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs check help
Date: Tue, 24 Nov 2015 15:28:28 -0500	[thread overview]
Message-ID: <5654C86C.9080800@gmail.com> (raw)
In-Reply-To: <AF79907D-A36B-4806-B31A-3E327F2E5642@up4.com>

[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]

On 2015-11-24 12:06, Vincent Olivier wrote:
> Hi,
>
> Woke up this morning with a kernel panic (for which I do not have details). Please find below the output for btrfs check. Is this normal ? What should I do ? Arch Linux 4.2.5. Btrfs-utils 4.3.1. 17x4TB RAID10.
You get bonus points for being on a reasonably up-to-date kernel and 
userspace :)

This is actually a pretty tame check result for a filesystem that's been 
through kernel panic. I think everything listed here is safe for check 
to fix, but I would suggest waiting until the devs provide opinions 
before actually running with --repair.  I would also suggest comparing 
results between the different devices in the FS, if things are 
drastically different, you may have issues that check can't fix on it's own.
> [root@3dcpc5 ~]# btrfs check /dev/sdk
> Checking filesystem on /dev/sdk
> UUID: 6a742786-070d-4557-9e67-c73b84967bf5
> checking extents
> checking free space cache
> checking fs roots
These next two lines are errors, but I'm not 100% certain if it's safe 
to have check fix them:
> root 5 inode 1341670 errors 400, nbytes wrong
> root 11406 inode 1341670 errors 400, nbytes wrong
This next one is also an error, and I am fairly certain that it's safe 
to have check fix as long as the number at the end is not too big.
> found 19328809638262 bytes used err is 1
The rest is just reference info
> total csum bytes: 18849042724
> total tree bytes: 27389886464
> total fs tree bytes: 4449746944
> total extent tree bytes: 3075457024
> btree space waste bytes: 2880474254
The only other thing I know that's worth mentioning is that if the 
numbers on these next two lines don't match, you may be missing some 
writes from right before the crash.
> file data blocks allocated: 19430708535296
> referenced 20123773407232




[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

  reply	other threads:[~2015-11-24 20:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-24 17:06 btrfs check help Vincent Olivier
2015-11-24 20:28 ` Austin S Hemmelgarn [this message]
2015-11-24 20:32   ` Hugo Mills
2015-11-25 16:51     ` Vincent Olivier
2015-11-25 18:52       ` Henk Slager
2015-11-26  1:44       ` Qu Wenruo
2015-11-27  3:03         ` Vincent Olivier
2015-11-27 11:25           ` Vincent Olivier
2015-11-27 16:32             ` Henk Slager
2015-11-27 20:25             ` Chris Murphy
2015-11-30  1:54             ` 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=5654C86C.9080800@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=vincent@up4.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.