diff mbox

btrfs-zero-log fails, can't mount FS

Message ID 53ED321D.1040702@fb.com (mailing list archive)
State New, archived
Headers show

Commit Message

Chris Mason Aug. 14, 2014, 10:03 p.m. UTC 
On 08/14/2014 01:27 PM, Marc MERLIN wrote:
> On Thu, Aug 14, 2014 at 12:52:35PM -0400, Austin S Hemmelgarn wrote:
>> I don't think it is likely that the Samsung SSD is to blame, in my
>> experience Samsung's SSD's are better than almost every other brand
>> except Intel, and I know that they honor write-barriers correctly.
>> The likely issue is that the system hung during the process of a commit,
>> which is one of the few things that I know of that consistently corrupts
>> the filesystem.  There isn't really anything I know of to prevent it,
>> except for making your system as stable as possible.
>> Interestingly, this type of thing is the only issue I've ever had with
>> BTRFS that wasn't traceable to hardware problems.
> 
> That was my understanding too, thanks for confirming.
> 
> Until this bug gets fixed, I'm perplexed as to why btrfs-zero-log isn't
> fixing this.
> Can't I unroll the last commits until I get to a stable one?
> 
> As luck would have it (again), I'm boarding a plane to Chicago tomorrow to
> go speak at linuxcon about btrfs.
> I would very much like not to have to spend 12H to restore my SSD from
> backup :)

At least I'll get to buy you a beer this time.

Lets just see if the log root is the only problem.  This will get you
through btrfs-zero-log

--
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

Marc MERLIN Aug. 14, 2014, 10:28 p.m. UTC | #1 
On Thu, Aug 14, 2014 at 06:03:09PM -0400, Chris Mason wrote:
> At least I'll get to buy you a beer this time.
 
Haha, no worries :)

> Lets just see if the log root is the only problem.  This will get you
> through btrfs-zero-log

It sure did, thanks much for the patch.
It output absolutely nothing instead of the wanted got lines it usually
spits out, and the filesystem mounted without problems.

I'll add this better btrfs-zero-log in my initrd for next time.

Would it be ok to modify btrfs-zero-log to simply remove the return -EIO
line?

Does it really matter whether it can setup the log root tree when it's being
asked to nuke the log?

Thanks,
Marc

> diff --git a/disk-io.c b/disk-io.c
> index 8db0335..d9a8e19 100644
> --- a/disk-io.c
> +++ b/disk-io.c
> @@ -911,13 +911,13 @@ int btrfs_setup_all_roots(struct btrfs_fs_info *fs_info, u64 root_tree_bytenr,
>  			return -EIO;
>  	}
>  	fs_info->csum_root->track_dirty = 1;
> -
> +#if 0
>  	ret = find_and_setup_log_root(root, fs_info, sb);
>  	if (ret) {
>  		printk("Couldn't setup log root tree\n");
>  		return -EIO;
>  	}
> -
> +#endif
>  	fs_info->generation = generation;
>  	fs_info->last_trans_committed = generation;
>  	if (extent_buffer_uptodate(fs_info->extent_root->node) &&
>
Chris Mason Aug. 15, 2014, 12:17 a.m. UTC | #2 
On 08/14/2014 06:28 PM, Marc MERLIN wrote:
> On Thu, Aug 14, 2014 at 06:03:09PM -0400, Chris Mason wrote:
>> At least I'll get to buy you a beer this time.
>  
> Haha, no worries :)
> 
>> Lets just see if the log root is the only problem.  This will get you
>> through btrfs-zero-log
> 
> It sure did, thanks much for the patch.
> It output absolutely nothing instead of the wanted got lines it usually
> spits out, and the filesystem mounted without problems.
> 
> I'll add this better btrfs-zero-log in my initrd for next time.
> 
> Would it be ok to modify btrfs-zero-log to simply remove the return -EIO
> line?
> 
> Does it really matter whether it can setup the log root tree when it's being
> asked to nuke the log?

Yes, btrfs-zero log doesn't need that root to be read.  I'll fix it up,
really glad it worked for you.

-chris
--
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
Marc MERLIN Aug. 15, 2014, 4:11 a.m. UTC | #3 
On Thu, Aug 14, 2014 at 08:17:02PM -0400, Chris Mason wrote:
> Yes, btrfs-zero log doesn't need that root to be read.  I'll fix it up,

Cool, thanks for fixing that, this one was easy considering :)

> really glad it worked for you.

You and me both :) 
Your timely reply today was very much appreciated.

Thanks,
Marc
diff mbox

Patch

diff --git a/disk-io.c b/disk-io.c
index 8db0335..d9a8e19 100644
--- a/disk-io.c
+++ b/disk-io.c
@@ -911,13 +911,13 @@  int btrfs_setup_all_roots(struct btrfs_fs_info *fs_info, u64 root_tree_bytenr,
 			return -EIO;
 	}
 	fs_info->csum_root->track_dirty = 1;
-
+#if 0
 	ret = find_and_setup_log_root(root, fs_info, sb);
 	if (ret) {
 		printk("Couldn't setup log root tree\n");
 		return -EIO;
 	}
-
+#endif
 	fs_info->generation = generation;
 	fs_info->last_trans_committed = generation;
 	if (extent_buffer_uptodate(fs_info->extent_root->node) &&