All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/3] btrfs: btrfs_bio and btrfs_io_bio rename
Date: Tue,  7 Sep 2021 15:42:39 +0800	[thread overview]
Message-ID: <20210907074242.103438-1-wqu@suse.com> (raw)

The branch can be fetched from github, and is the preferred way to grab
the code, as this patchset changed quite a lot of code.
https://github.com/adam900710/linux/tree/chunk_refactor

There are two structure, btrfs_io_bio and btrfs_bio, which have very
similar names but completely different meanings.

Btrfs_io_bio mostly works at logical bytenr layer (its
bio->bi_iter.bi_sector points to btrfs logical bytenr), and just
contains extra info like csum and mirror_num.

While btrfs_io_bio acts more like a phyical mapping, mapping logical
bytenr to real devices.

Such naming is completely anti-human.

So this patchset will rename btrfs_io_bio to btrfs_logical_bio and
rename btrfs_bio to btrfs_physical_bio.

This acts as the first step towards chunk layer code refactor, the
ultimate goals include:

- Move bio split code into chunk layer
  Currently btrfs_map_bio() requires the bio passed in not to cross
  stripe boundaries.

  Thus it requires submit_extent_page() to do bio splitting.

  In fact higher layer code shouldn't bother that at all, chunk layer
  code should do the bio splitting.

- Hide btrfs_physical_bio
  In fact for certain types, like SINGLE it doesn't need complex
  btrfs_physical_bio, and can do its IO just remapping the existing bio.

  In fact, each chunk type should have their own bio mapping and
  physical bio tracing code.
  They can share some common infrastructure, but definitely not
  exporting the whole btrfs_physical_bio as a core structure.

- Create fs/btrfs/raid/*.[ch] for each chunk type
  Some chunk mapping can definitely share some code, but we definitely
  don't want to put all chunk mapping code into volumes.[ch]/scrub.[ch].

- Provide better exported chunk layer interface.
  Can't we just use bytenr + mirror_num to handle most things?

  For device map code, we never bother whatever the underlying layer is.

  If we can unify the interface to bare minimal, we can really separate
  the chunk mapping code from higher layer code.

  Although I'm not that optimistic since we still have scrub to bother.


Qu Wenruo (3):
  btrfs: rename btrfs_io_bio_alloc() to btrfs_bio_alloc_iovecs()
  btrfs: rename struct btrfs_io_bio to struct btrfs_logical_bio
  btrfs: rename struct btrfs_bio to btrfs_physical_bio

 fs/btrfs/check-integrity.c |   4 +-
 fs/btrfs/compression.c     |  16 +--
 fs/btrfs/ctree.h           |   5 +-
 fs/btrfs/disk-io.c         |   2 +-
 fs/btrfs/disk-io.h         |   2 +-
 fs/btrfs/extent-tree.c     |  14 +-
 fs/btrfs/extent_io.c       |  96 +++++++-------
 fs/btrfs/extent_io.h       |  11 +-
 fs/btrfs/file-item.c       |  12 +-
 fs/btrfs/inode.c           |  57 ++++----
 fs/btrfs/raid56.c          | 126 +++++++++---------
 fs/btrfs/raid56.h          |   8 +-
 fs/btrfs/reada.c           |  26 ++--
 fs/btrfs/scrub.c           | 130 +++++++++---------
 fs/btrfs/volumes.c         | 263 +++++++++++++++++++------------------
 fs/btrfs/volumes.h         |  67 +++++++---
 fs/btrfs/zoned.c           |  16 +--
 17 files changed, 446 insertions(+), 409 deletions(-)

-- 
2.33.0


             reply	other threads:[~2021-09-07  7:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-07  7:42 Qu Wenruo [this message]
2021-09-07  7:42 ` [PATCH 1/3] btrfs: rename btrfs_io_bio_alloc() to btrfs_bio_alloc_iovecs() Qu Wenruo
2021-09-07  8:53   ` Nikolay Borisov
2021-09-07  7:42 ` [PATCH 2/3] btrfs: rename struct btrfs_io_bio to struct btrfs_logical_bio Qu Wenruo
2021-09-07  9:47   ` Nikolay Borisov
2021-09-07  9:56     ` Qu Wenruo
2021-09-07  7:42 ` [PATCH 3/3] btrfs: rename struct btrfs_bio to btrfs_physical_bio 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=20210907074242.103438-1-wqu@suse.com \
    --to=wqu@suse.com \
    --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 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.