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
next prev 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 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).