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) &&
>
--
"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/
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
