All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Schmidt <list.btrfs@jan-o-sch.net>
To: Jan Schubert <Jan.Schubert@GMX.li>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH v7 0/8] Btrfs scrub: print path to corrupted files and trigger nodatasum fixup
Date: Mon, 25 Jul 2011 10:34:23 +0200	[thread overview]
Message-ID: <4E2D2A8F.1050206@jan-o-sch.net> (raw)
In-Reply-To: <4E2C8425.9090601@GMX.li>

On 24.07.2011 22:44, Jan Schubert wrote:
> On 07/24/2011 03:31 PM, Jan Schmidt wrote:
>>
>> Yes, please check if that error solely depends on the state of your file
>> system (which is what I expect). Please try another scrub while the
>> system is as idle as you get it (also consider daemon processes, cron
>> jobs etc.).
> 
> 
> Jan, doing a new scrub using a clean kernel (without your patchset) the
> system did not crash. I'm back to my 2211 uncorrectable errors now and
> dmesg shows also the (some?) corresponding inodes:
> 
> btrfs: use lzo compression
> btrfs: enabling disk space caching
> btrfs: use ssd allocation scheme
> Adding 4194300k swap on /dev/sda3.  Priority:-1 extents:1 across:4194300k SS
> btrfs: unable to fixup at 182245502976
> btrfs: unable to fixup at 182245507072
> btrfs: unable to fixup at 182245511168
> btrfs: unable to fixup at 182245515264
> btrfs: unable to fixup at 182245519360
> btrfs: unable to fixup at 182245523456
> btrfs: unable to fixup at 182245527552
> btrfs: unable to fixup at 182245531648
> btrfs: unable to fixup at 182245535744
> btrfs: unable to fixup at 182245539840
> 
> scrub status for 03201fc0-7695-4468-9a10-f61ad79f23ca
>         scrub started at Sun Jul 24 22:13:09 2011 and finished after 787
> seconds
>         total bytes scrubbed: 173.92GB with 2211 errors
>         error details: csum=2211
>         corrected errors: 0, uncorrectable errors: 2211

Okay, it's good that it's persistent.

> So there might be an issue with your patch concerning the kernel oops?

Yes, that seems quite likely.

> Any chance to resolve the inodes to affected files manualy?

That's cumbersome, but you can do it using the information contained in
the debug-tree output. But I'd rather find the bug I must have
introduced :-)

> Did I mention that I just did apply your patches 1 to 3 from your patch
> set as suggested by you in the mailing list?

You did. And yes, that hasn't been tested as much as applying the whole
patch set. I just double checked it's working for me, though. I don't
expect it makes a difference if you apply all the patches.

> Are you interested in btrfs-debug-tree anyway?

Absolutely, yes.

Alternatively, if you have a lot of bandwidth and no private data in
your file system, it would be even more helpful if you put the whole
file system somewhere. But the btrfs-debug-tree output would help a lot,
too.

-Jan

  parent reply	other threads:[~2011-07-25  8:34 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-22 11:12 [PATCH v7 0/8] Btrfs scrub: print path to corrupted files and trigger nodatasum fixup Jan Schmidt
2011-07-22 11:12 ` [PATCH v7 1/8] btrfs: added helper functions to iterate backrefs Jan Schmidt
2011-07-27  7:59   ` Li Zefan
2011-07-27  8:06     ` Li Zefan
2011-07-27  8:22       ` Jan Schmidt
2011-07-22 11:12 ` [PATCH v7 2/8] btrfs scrub: added unverified_errors Jan Schmidt
2011-07-22 11:12 ` [PATCH v7 3/8] btrfs scrub: print paths of corrupted files Jan Schmidt
2011-07-22 11:12 ` [PATCH v7 4/8] btrfs scrub: bugfix: mirror_num off by one Jan Schmidt
2011-07-22 11:12 ` [PATCH v7 5/8] btrfs: add mirror_num to extent_read_full_page Jan Schmidt
2011-07-22 11:12 ` [PATCH v7 6/8] btrfs scrub: use int for mirror_num, not u64 Jan Schmidt
2011-07-22 11:12 ` [PATCH v7 7/8] btrfs scrub: add fixup code for errors on nodatasum files Jan Schmidt
2011-07-22 11:12 ` [PATCH v7 8/8] btrfs: new ioctls to do logical->inode and inode->path resolving Jan Schmidt
2011-07-23 22:38 ` [PATCH v7 0/8] Btrfs scrub: print path to corrupted files and trigger nodatasum fixup Jan Schubert
2011-07-24 11:36   ` Jan Schmidt
     [not found]     ` <4E2C0E2C.4070606@GMX.li>
     [not found]       ` <4E2C1E9D.1090403@jan-o-sch.net>
     [not found]         ` <4E2C8425.9090601@GMX.li>
2011-07-25  8:34           ` Jan Schmidt [this message]
     [not found]             ` <4E2D5C36.306@GMX.li>
2011-07-25 13:15               ` Jan Schmidt
     [not found]                 ` <4E2D9290.6020600@GMX.li>
     [not found]                   ` <4E2E912E.7040109@jan-o-sch.net>
     [not found]                     ` <4E2E92FA.4060008@GMX.li>
2011-07-26 17:36                       ` Jan Schmidt

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=4E2D2A8F.1050206@jan-o-sch.net \
    --to=list.btrfs@jan-o-sch.net \
    --cc=Jan.Schubert@GMX.li \
    --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 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.