All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Matthew Warren <matthewwarren101010@gmail.com>,
	dsterba@suse.cz, linux-btrfs@vger.kernel.org
Subject: Re: Changing the checksum algorithm on an existing BTRFS filesystem
Date: Tue, 5 Oct 2021 06:54:27 +0800	[thread overview]
Message-ID: <d2e7dd3d-5cbf-287f-893c-bed3e6219d0a@gmx.com> (raw)
In-Reply-To: <CA+H1V9yopc2okgT=5XeCwvHF8oXPVhnojaf_rZOeuiThZEfqWQ@mail.gmail.com>



On 2021/10/5 00:01, Matthew Warren wrote:
> I don't know how btrfs is layed out internally, but is checksum tree
> separate from file (meta)data or is it part of the (meta)data? If it's
> separate it should be possible to build a second csum tree and then
> replace the old one once it's done, right?

There are several problems, even for off-line covert.

1) Metadata checksum
    Unlike data checksum, metadata checksum is inlined into the metadata
    header.
    Thus there is no way to make the csum co-exist for metadata, and we
    need to re-write (CoW) all metadata of the fs to convert them to the
    new algo.

2) Superblock flags/csum_type
    Currently we have only one csum_type, which is shared by both data
    and metadata.

    We need extra csum_type to indicate the destination csum algo.
    We will also need to sync this bit to kernel, no matter if the kernel
    really uses that.

Thanks,
Qu

>
> Matthew Warren
>
> On Mon, Oct 4, 2021 at 4:52 AM David Sterba <dsterba@suse.cz> wrote:
>>
>> On Mon, Oct 04, 2021 at 12:26:16AM -0500, Matthew Warren wrote:
>>> Is there currently any way to change the checksum used by btrfs
>>> without recreating the filesystem and copying data to the new fs?
>>
>> I have a WIP patch but it's buggy. It works on small filesystems but
>> when I tried it on TB-sized images it blew up somewhere. Also the WIP is
>> not too smart, it deletes the whole checksum tree and rebuilds if from
>> the on-disk data, so it lacks the verification against the existing
>> csums. I intend to debug it some day but it's a nice to have feature,
>> I'm aware that people have been asking for it but at this point it would
>> be to dangerous to provide even the prototype.

  parent reply	other threads:[~2021-10-04 22:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-04  5:26 Changing the checksum algorithm on an existing BTRFS filesystem Matthew Warren
2021-10-04  6:20 ` Nikolay Borisov
2021-10-04  9:51 ` David Sterba
2021-10-04 16:01   ` Matthew Warren
2021-10-04 20:37     ` Chris Murphy
2021-10-04 22:54     ` Qu Wenruo [this message]
2021-10-05  3:26       ` Zygo Blaxell
2021-10-05  6:00         ` Qu Wenruo

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=d2e7dd3d-5cbf-287f-893c-bed3e6219d0a@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=matthewwarren101010@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.