All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Cc: josef@toxicpanda.com, Johannes.Thumshirn@wdc.com
Subject: [PATCH v4 0/6] btrfs: subpage + zoned fixes
Date: Sat, 11 May 2024 09:45:16 +0930	[thread overview]
Message-ID: <cover.1715386434.git.wqu@suse.com> (raw)

[CHANGELOG]
v4:
- Rebased to the latest for-next branch
  Thankfully no conflicts at all.

- Include all the previous preparation patches
  It turns out I split the preparation into other series and even get
  myself confused.

- Use the correct commit message from my local branch
  It turns out Josef is totally correct, the problem I described in
  "btrfs: do no clera page dirty inside extent_write_locked_range()" is
  really confusing, it has direct IO involved and my local branch is
  already using a much better commit and I just forgot it.
 
v3:
- Use the minimal fsstress workload with trace_printk() output to
  explain the bug better

v2:
- Update the commit message for the first patch
  As there is something wrong with the ASCII art of the memory layout.

[REPO]
https://github.com/adam900710/linux/tree/subpage_delalloc

If running subpage with zoned devices (TCMU emulated HDD, 64K or 16K
page size with 4K sectorsize), btrfs can easily hitting various bugs:

- ASSERT()s related to submitting page range which has no OE coverage

- Various reserved space leakage and some OE never finished

This is caused by two major reasons:

- run_delalloc_cow() is not subpage compatible
  Thus we may try to submit pages which has no OE for it.

  This would be addressed by patch 1~4

- Some dirty range is not submitted thus OE would never finish
  This happens due to the mismatch that extent_write_locked_range() can
  clear the full page dirty, even if we're only submitting part of the 
  dirty ranges.

  Then later __extent_writepage_io() would refuse to submit a non-dirty
  page, and the check is only checking the full page dirty flag, not the
  subpage bitmaps.

  This would be addressed by patch 5~6.


Qu Wenruo (6):
  btrfs: make __extent_writepage_io() to write specified range only
  btrfs: lock subpage ranges in one go for writepage_delalloc()
  btrfs: subpage: introduce helpers to handle subpage delalloc locking
  btrfs: migrate writepage_delalloc() to use subpage helpers
  btrfs: do not clear page dirty inside extent_write_locked_range()
  btrfs: make extent_write_locked_range() to handle subpage writeback
    correctly

 fs/btrfs/extent_io.c | 105 +++++++++++++++++++++++++------
 fs/btrfs/subpage.c   | 144 +++++++++++++++++++++++++++++++++++++++++--
 fs/btrfs/subpage.h   |  10 ++-
 3 files changed, 233 insertions(+), 26 deletions(-)

-- 
2.45.0


             reply	other threads:[~2024-05-11  0:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-11  0:15 Qu Wenruo [this message]
2024-05-11  0:15 ` [PATCH v4 1/6] btrfs: make __extent_writepage_io() to write specified range only Qu Wenruo
2024-05-12 16:31   ` Johannes Thumshirn
2024-05-11  0:15 ` [PATCH v4 2/6] btrfs: lock subpage ranges in one go for writepage_delalloc() Qu Wenruo
2024-05-12 17:08   ` Johannes Thumshirn
2024-05-12 22:09     ` Qu Wenruo
2024-05-11  0:15 ` [PATCH v4 3/6] btrfs: subpage: introduce helpers to handle subpage delalloc locking Qu Wenruo
2024-05-12 17:10   ` Johannes Thumshirn
2024-05-11  0:15 ` [PATCH v4 4/6] btrfs: migrate writepage_delalloc() to use subpage helpers Qu Wenruo
2024-05-12 17:14   ` Johannes Thumshirn
2024-05-11  0:15 ` [PATCH v4 5/6] btrfs: do not clear page dirty inside extent_write_locked_range() Qu Wenruo
2024-05-12 17:19   ` Johannes Thumshirn
2024-05-11  0:15 ` [PATCH v4 6/6] btrfs: make extent_write_locked_range() to handle subpage writeback correctly Qu Wenruo
2024-05-12 17:21   ` Johannes Thumshirn

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=cover.1715386434.git.wqu@suse.com \
    --to=wqu@suse.com \
    --cc=Johannes.Thumshirn@wdc.com \
    --cc=josef@toxicpanda.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.