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
next prev parent 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).