From patchwork Tue Mar 26 14:48:55 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 2337771 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id D7A8BDF264 for ; Tue, 26 Mar 2013 14:49:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933438Ab3CZOtA (ORCPT ); Tue, 26 Mar 2013 10:49:00 -0400 Received: from dkim2.fusionio.com ([66.114.96.54]:34324 "EHLO dkim2.fusionio.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756862Ab3CZOs7 (ORCPT ); Tue, 26 Mar 2013 10:48:59 -0400 Received: from mx2.fusionio.com (unknown [10.101.1.160]) by dkim2.fusionio.com (Postfix) with ESMTP id A17969A067F for ; Tue, 26 Mar 2013 08:48:59 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fusionio.com; s=default; t=1364309339; bh=qWMvpQa1i1D9xombfgt7tqETK7wygdaO7NQ9T9EvHu4=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=PYc2LJQIB2+mA5eXr3m8YedaldGFurgQO194e8RUbjbjauyhwwvPNGB7zmqOc3lPM +j87hdSK0VY6JpmGrWFDPiEVAINDM6lVpL5Uy2rO9D/GSzPB/3IFopKnjtYZ1NiyCf 12Q6jRt3Zk3WZ4iDZsx0eM3vE/rVTII3LKwv0ASM= X-ASG-Debug-ID: 1364309337-0421b539a8259c0001-6jHSXT Received: from mail1.int.fusionio.com (mail1.int.fusionio.com [10.101.1.21]) by mx2.fusionio.com with ESMTP id FPIFN3fz1EizQZyC (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Mar 2013 08:48:57 -0600 (MDT) X-Barracuda-Envelope-From: JBacik@fusionio.com Received: from localhost (98.26.82.158) by mail.fusionio.com (10.101.1.19) with Microsoft SMTP Server (TLS) id 8.3.83.0; Tue, 26 Mar 2013 08:48:57 -0600 Date: Tue, 26 Mar 2013 10:48:55 -0400 From: Josef Bacik To: =?utf-8?B?U3rFkXRzIMOBa29z?= CC: "linux-btrfs@vger.kernel.org" Subject: Re: Kernel bug on mismatching generation_v2 in inode.c:835 Message-ID: <20130326144855.GM1955@localhost.localdomain> X-ASG-Orig-Subj: Re: Kernel bug on mismatching generation_v2 in inode.c:835 References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2011-07-01) X-Barracuda-Connect: mail1.int.fusionio.com[10.101.1.21] X-Barracuda-Start-Time: 1364309337 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://10.101.1.181:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at fusionio.com X-Barracuda-Spam-Score: 2.62 X-Barracuda-Spam-Status: No, SCORE=2.62 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_SA085b, CN_BODY_332, URIBL_WS_SURBL X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.126299 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 2.10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist [URIs: morrohun.hu] 0.40 BSF_SC0_SA085b Custom Rule SA085b Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org 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 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);