public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: dsterba@suse.cz
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 00/18] btrfs: migrate to "block size" to describe the
Date: Thu, 19 Dec 2024 06:43:38 +1030	[thread overview]
Message-ID: <73f9e7d0-9954-4507-a48a-2759cf3a2f2f@suse.com> (raw)
In-Reply-To: <20241218183155.GE31418@twin.jikos.cz>



在 2024/12/19 05:01, David Sterba 写道:
> On Wed, Dec 18, 2024 at 08:11:16PM +1030, Qu Wenruo wrote:
>> [IMPEMENTATION]
>> To reduce the confusion, this patchset will do such a huge migration in
>> different steps:
> 
> With some many changes everywhere this is going to make backports even
> more tedious. I think it would be best to do the conversion gradually or
> selectively to code that does not change so often. As you've split it to
> files we can first pick a few obvious ones (like file-item.c) or gather
> stats from stable.git.

For the backports, we can put the btrfs_fs_info union to older kernels 
and call it a day without the remaining part.

So that both newer and older terminology can co-exist without any conflicts.

Although backport conflicts will still happen in the context.

> 
> A quick and rough estimate for all 6.x.y releases counting file
> backports in the individual patches in the list below. This is period of
> 2 years, 104 weeks (roughly matching number of releases). So if there
> are 88 patches touching inode.c that's quite likely a conflict in every
> backport.
> 
> This should be also correlated agains number of 'sectorsize' per file,
> so it many not be that bad, for example in ioctl.c there are only 4
> occurences so that's fine. The point is we can't do the renames without
> some sensibility and respect to backports.

But at least, when a backport fails, we can easily fix the conflict.
It will always be sectorsize -> blocksize, either in the context or the 
modified lines.

Thanks,
Qu
> 
>       88 inode.c
>       62 disk-io.c
>       61 volumes.c
>       57 extent_io.c
>       57 block-group.c
>       56 ioctl.c
>       52 extent-tree.c
>       49 zoned.c
>       49 qgroup.c
>       37 send.c
>       36 super.c
>       33 ctree.c
>       30 transaction.c
>       29 file.c
>       28 tree-log.c
>       28 free-space-cache.c
>       26 scrub.c
>       24 ctree.h
>       22 relocation.c
>       19 delayed-inode.c
>       17 tree-checker.c
>       17 backref.c
>       15 space-info.c
>       14 extent_map.c
>       12 free-space-tree.c
>       12 disk-io.h
>       11 block-group.h
>       11 bio.c
>       10 ordered-data.c
>       10 block-rsv.c
>        9 ref-verify.c
>        9 file-item.c
>        9 btrfs_inode.h
>        8 include/uapi/linux/btrfs.h
>        8 fs.h
>        8 delayed-ref.c
>        8 delalloc-space.c
>        7 root-tree.c
>        7 print-tree.c
>        7 dir-item.c
>        7 dev-replace.c
>        7 block-rsv.h
>        6 sysfs.c
>        6 extent_io.h
>        6 defrag.c
>        6 compression.c
>        5 volumes.h
>        5 transaction.h
>        5 qgroup.h
>        5 export.c
>        4 zoned.h
>        4 space-info.h
>        4 reflink.c
>        4 inode-item.c
>        4 include/trace/events/btrfs.h
>        4 discard.c
>        4 delayed-ref.h
>        3 tree-log.h
>        3 tree-defrag.c
>        3 subpage.c
>        3 raid56.c
>        3 free-space-tree.h
>        3 extent-io-tree.c
>        3 extent-io-tests.c
>        3 backref.h
>        2 zlib.c
>        2 xattr.c
>        2 uuid-tree.c
>        2 tree-mod-log.c
>        2 tests/inode-tests.c
>        2 tests/extent-map-tests.c
>        2 tests/extent-buffer-tests.c
>        2 root-tree.h
>        2 relocation.h
>        2 rcu-string.h
>        2 qgroup-tests.c
>        2 lzo.c
>        2 locking.c
>        2 inode-item.h
>        2 free-space-cache.h
>        2 extent-tree.h
>        2 delayed-inode.h
>        1 tree-checker.h
>        1 tests/free-space-tree-tests.c
>        1 sysfs.h
>        1 props.c
>        1 ordered-data.h
>        1 messages.h
>        1 messages.c
>        1 include/uapi/linux/btrfs_tree.h
>        1 fs.c
>        1 file-item.h
>        1 extent_map.h
>        1 export.h
>        1 compression.h
>        1 btrfs-tests.c
>        1 btrfs.h
>        1 bio.h


  reply	other threads:[~2024-12-18 20:13 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-18  9:41 [PATCH 00/18] btrfs: migrate to "block size" to describe the Qu Wenruo
2024-12-18  9:41 ` [PATCH 01/18] btrfs: rename btrfs_fs_info::sectorsize to blocksize for disk-io.c Qu Wenruo
2024-12-18  9:41 ` [PATCH 02/18] btrfs: migrate subpage.[ch] to use block size terminology Qu Wenruo
2024-12-18  9:41 ` [PATCH 03/18] btrfs: migrate tree-checker.c " Qu Wenruo
2024-12-18  9:41 ` [PATCH 04/18] btrfs: migrate scrub.c " Qu Wenruo
2024-12-18  9:41 ` [PATCH 05/18] btrfs: migrate extent_io.[ch] " Qu Wenruo
2024-12-18  9:41 ` [PATCH 06/18] btrfs: migrate compression related code " Qu Wenruo
2024-12-18  9:41 ` [PATCH 07/18] btrfs: migrate free space cache " Qu Wenruo
2024-12-18  9:41 ` [PATCH 08/18] btrfs: migrate file-item.c " Qu Wenruo
2024-12-18  9:41 ` [PATCH 09/18] btrfs: migrate file.c " Qu Wenruo
2024-12-18  9:41 ` [PATCH 10/18] btrfs: migrate inode.c and btrfs_inode.h " Qu Wenruo
2024-12-18  9:41 ` [PATCH 11/18] btrfs: migrate raid56.[ch] " Qu Wenruo
2024-12-18  9:41 ` [PATCH 12/18] btrfs: migrate defrag.c " Qu Wenruo
2024-12-18  9:41 ` [PATCH 13/18] btrfs: migrate bio.[ch] " Qu Wenruo
2024-12-18  9:41 ` [PATCH 14/18] btrfs: migrate the remaining sector size users " Qu Wenruo
2024-12-18  9:41 ` [PATCH 15/18] btrfs: migrate selftests " Qu Wenruo
2024-12-18  9:41 ` [PATCH 16/18] btrfs: finish the rename of btrfs_fs_info::sectorsize Qu Wenruo
2024-12-18  9:41 ` [PATCH 17/18] btrfs: migrate btrfs_super_block::sectorsize to blocksize Qu Wenruo
2024-12-18  9:41 ` [PATCH 18/18] btrfs: migrate the ioctl interfaces to use block size terminology Qu Wenruo
2024-12-18 18:31 ` [PATCH 00/18] btrfs: migrate to "block size" to describe the David Sterba
2024-12-18 20:13   ` Qu Wenruo [this message]
2024-12-18 20:36     ` David Sterba
2024-12-18 21:15       ` 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=73f9e7d0-9954-4507-a48a-2759cf3a2f2f@suse.com \
    --to=wqu@suse.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    /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