linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu WenRuo <wqu@suse.com>
To: "dsterba@suse.cz" <dsterba@suse.cz>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	Christian Pernegger <pernegger@gmail.com>
Subject: Re: [PATCH] btrfs-progs: rescue-zero-log: Modify super block directly
Date: Fri, 1 Nov 2019 10:56:36 +0000	[thread overview]
Message-ID: <65d30567-a0cb-4430-43ba-94e5fe597f8e@suse.com> (raw)
In-Reply-To: <20191101105216.GJ3001@twin.jikos.cz>



On 2019/11/1 下午6:52, David Sterba wrote:
> On Sat, Oct 26, 2019 at 06:11:27PM +0800, Qu Wenruo wrote:
>> +	/*
>> +	 * Log tree only exists in the primary super block, so SBREAD_DEFAULT
>> +	 * is enough.
> 
> For read it should be enough to read the default one, but do you mean
> that 1st and 2nd copy don't have the log_root values set? They're
> written from the same buffer so I'd expect the contents to be the same.

Log tree update only happens for primary sb.

The kernel code has this:

btrfs_sync_log()
|- ret = write_all_supers(fs_info, 1)
   |- write_dev_supers(max_mirrors); # max_mirrors == 1
      |- for (i = 0; i < max_mirrors; i++)

> 
>> +	ret = btrfs_read_dev_super(fd, sb, BTRFS_SUPER_INFO_OFFSET,
>> +				   SBREAD_DEFAULT);
>> +	if (ret < 0) {
>> +		errno = -ret;
>> +		error("failed to read super block on '%s': %m", devname);
>> +		goto close_fd;
>>  	}
>>  
>> -	sb = root->fs_info->super_copy;
>>  	printf("Clearing log on %s, previous log_root %llu, level %u\n",
>>  			devname,
>>  			(unsigned long long)btrfs_super_log_root(sb),
>>  			(unsigned)btrfs_super_log_root_level(sb));
>> -	trans = btrfs_start_transaction(root, 1);
>> -	BUG_ON(IS_ERR(trans));
>>  	btrfs_set_super_log_root(sb, 0);
>>  	btrfs_set_super_log_root_level(sb, 0);
>> -	btrfs_commit_transaction(trans, root);
>> -	close_ctree(root);
>> +	btrfs_csum_data(btrfs_super_csum_type(sb), (u8 *)sb + BTRFS_CSUM_SIZE,
>> +			result, BTRFS_SUPER_INFO_SIZE - BTRFS_CSUM_SIZE);
>> +	memcpy(&sb->csum[0], result, BTRFS_CSUM_SIZE);
>> +	ret = pwrite64(fd, sb, BTRFS_SUPER_INFO_SIZE, BTRFS_SUPER_INFO_OFFSET);
> 
> So this only writes on the one device that's passed to the command.
> Previously it would update superblocks on all devices.

Oh, you got me.

That's indeed the case. I guess we need to do the same skip_bg behavior
just like kernel to handle multiple devices.

Thanks,
Qu

  reply	other threads:[~2019-11-01 10:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-26 10:11 [PATCH] btrfs-progs: rescue-zero-log: Modify super block directly Qu Wenruo
2019-11-01 10:52 ` David Sterba
2019-11-01 10:56   ` Qu WenRuo [this message]
2019-11-01 11:08     ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=65d30567-a0cb-4430-43ba-94e5fe597f8e@suse.com \
    --to=wqu@suse.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=pernegger@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).