diff mbox

Kernel bug on mismatching generation_v2 in inode.c:835

Message ID 20130326144855.GM1955@localhost.localdomain (mailing list archive)
State New, archived
Headers show

Commit Message

Josef Bacik March 26, 2013, 2:48 p.m. UTC
On Tue, Mar 26, 2013 at 08:33:27AM -0600, Sz?ts Ákos wrote:
> Dear list members,
> 
> In my previous thread at
> http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg23333.html
> there was a space_cache kernel bug/panic on kernel 3.8. I could
> successfully "fix" that with rebuilding the cache. But some files were
> missing/corrupted. So I booted a rescue CD with kernel 3.7 and ran
> btrfsck --repair, which repaired quite a few things.
> 
> After a reboot I got the following message:
> [  469.457386] btrfs: disk space caching is enabled
> [  469.503612] btrfs: mismatching generation and generation_v2 found
> in root item. This root was probably mounted with an older kernel.
> Resetting all new fields.
> 
> As soon as anything had wanted to read a bit from the file system, the
> hard drive went crazy and was working for 5-10 minutes. After I got a
> kernel panic which said there's an error in fs/btrfs/inode.c:835.
> 
> In the moment I don't just mount, but want to read something from the
> mounted file system under the rescue system, the same procedure
> happens.
> 
> I made some pictures of it (since I cannot read anything from the
> logs, if there are any).
> You can find them here: www.morrohun.hu/temp/btrfs/v2/[123].jpg
> 
> I wanted to create an image with the aforementined btrfs-image tool,
> but yet to have any success .
> 
> Could you please give me an advice what can I do now? Living on a
> live-CD is not a life insurance :)
> 
> Best regards,
>

Ok I'd like to get btrfs-image working so I can run fsck on it here locally and
see what's wrong.  Can you apply this patch to my tree and rebuild and run
btrfs-image again, it should tell us why it's having trouble opening the device.
It also fixes that slight mkfs not compiling problem ;).  Thanks,

Josef

 
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Sz?ts Ákos March 26, 2013, 3:59 p.m. UTC | #1
The error was just a silly "permission denied" one.

I uploaded the created image to www.morrohun.hu/temp/btrfs/btrfs.img
SHA1: 90ee61e0724700495d26678d58dc229e04a04cc4
Please, write me when you downloaded and I'll delete it.

I have the idea to run btrfsck from your tree on the file system
again, but I won't touch the fs until you said so :).

Ákos
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Josef Bacik March 26, 2013, 5:34 p.m. UTC | #2
On Tue, Mar 26, 2013 at 09:59:57AM -0600, Sz?ts Ákos wrote:
> The error was just a silly "permission denied" one.
> 
> I uploaded the created image to www.morrohun.hu/temp/btrfs/btrfs.img
> SHA1: 90ee61e0724700495d26678d58dc229e04a04cc4
> Please, write me when you downloaded and I'll delete it.
> 
> I have the idea to run btrfsck from your tree on the file system
> again, but I won't touch the fs until you said so :).
> 

Ok you can go ahead and delete it, I just pulled it down, I'm restoring it and
then I'll see whats going on.  Thanks,

Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Josef Bacik March 26, 2013, 6:17 p.m. UTC | #3
On Tue, Mar 26, 2013 at 09:59:57AM -0600, Sz?ts Ákos wrote:
> The error was just a silly "permission denied" one.
> 
> I uploaded the created image to www.morrohun.hu/temp/btrfs/btrfs.img
> SHA1: 90ee61e0724700495d26678d58dc229e04a04cc4
> Please, write me when you downloaded and I'll delete it.
> 
> I have the idea to run btrfsck from your tree on the file system
> again, but I won't touch the fs until you said so :).
> 

You did take this image while the file system was unmounted right?  I'm seeing
different weirdness with the restored image, trying to figure out if it's a
problem with the restore or with the dump.  Thanks,

Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sz?ts Ákos March 26, 2013, 6:25 p.m. UTC | #4
If my memory servers me well, it was taken in unmounted state. Do you
want me to take an other one and compare the SHA1 values?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Josef Bacik March 26, 2013, 6:47 p.m. UTC | #5
On Tue, Mar 26, 2013 at 12:25:44PM -0600, Sz?ts Ákos wrote:
> If my memory servers me well, it was taken in unmounted state. Do you
> want me to take an other one and compare the SHA1 values?

Nope I found the bug, just a problem with the restore.  Thanks,

Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sz?ts Ákos March 27, 2013, 11:51 a.m. UTC | #6
What do you think; is this issue in the file system can be repaired
with btrfsck? Or should I install a new, patched kernel on my
partition somehow?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Josef Bacik March 27, 2013, 12:49 p.m. UTC | #7
On Wed, Mar 27, 2013 at 05:51:32AM -0600, Sz?ts Ákos wrote:
> What do you think; is this issue in the file system can be repaired
> with btrfsck? Or should I install a new, patched kernel on my
> partition somehow?

Sorry I was flipping between your problem and somebody elses problem yesterday
and I was having trouble restoring your file system from the image.  Today I
only have your problem and I'm almost done fixing this bug in the restore so I
should have something for you today, hopefully before lunch.  Thanks,

Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Josef Bacik March 27, 2013, 1:58 p.m. UTC | #8
On Wed, Mar 27, 2013 at 05:51:32AM -0600, Sz?ts Ákos wrote:
> What do you think; is this issue in the file system can be repaired
> with btrfsck? Or should I install a new, patched kernel on my
> partition somehow?

Ok I've successfully restored your image and I've reproduced your problem, I
will let you know when I've fixed it.  Thanks,

Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sz?ts Ákos March 27, 2013, 1:59 p.m. UTC | #9
Oh, that's a very good news! Thank you very much :)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/disk-io.c b/disk-io.c
index 72b33da..6d879c5 100644
--- a/disk-io.c
+++ b/disk-io.c
@@ -1047,7 +1047,8 @@  struct btrfs_fs_info *open_ctree_fs_info(const char *filename,
 
 	fp = open(filename, flags, 0600);
 	if (fp < 0) {
-		fprintf (stderr, "Could not open %s\n", filename);
+		fprintf (stderr, "Could not open %s, %d (%s)\n", filename,
+			 errno, strerror(errno));
 		return NULL;
 	}
 	info = __open_ctree_fd(fp, filename, sb_bytenr, 0, writes, partial);
diff --git a/mkfs.c b/mkfs.c
index bc68350..003a8fa 100644
--- a/mkfs.c
+++ b/mkfs.c
@@ -296,7 +296,7 @@  static int create_raid_groups(struct btrfs_trans_handle *trans,
 
 	if (!mixed) {
 		u64 total_bytes =
-			btrfs_super_total_bytes(root->fs_info->super_copy);
+			btrfs_super_total_bytes(&root->fs_info->super_copy);
 		u64 alloced_bytes = 0;
 		u64 alloc_flags = BTRFS_BLOCK_GROUP_ENOSPC |
 			(allowed & metadata_profile);