On 07/04/2014 11:07 AM, Liu Bo wrote:
On Thu, Jul 03, 2014 at 06:44:21AM -0700, Marc MERLIN wrote:
Thanks for the patch. Hopefully this will make it to the next 3.15.x
kernel.
I also went back to 3.14 anyway since the 'blocked for 120 seconds' look
like another instance of deadlocks we've been discussing here.
But just curious:
[160562.925463] parent transid verify failed on 2776298520576 wanted 41015
found 18120
What should I be doing about this?
Does it mean that I do have some kind of corruption/damage on my
filesystem?
If there is another copy for the block(RAID1, DUP, RAID5/6), it'd try to read
the copy and repair the crc with the good one, it's all we can do about it.
Also, is it possible to have all these messages state which devid they
occurred on? I don't even know which device I should be worrying about
right now, and although I'm running scrub now, my understanding is that
scrub doesn't actually look at FS structures and is likely to miss this
anyway.
Yes we can but it'd need a bit more effort, for now, all device msg we've seen
in panic info comes from sb->s_id which points to @fs_info->latest_device.
You means something like this:
+ printk_ratelimited("BTRFS (device: %s) parent transid verify
failed on %llu wanted %llu found %llu\n",
+ eb->fs_info->sb->s_id, eb->start,
+ parent_transid, btrfs_header_generation(eb));
thanks,
-liubo
Thanks,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
