public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: dsterba@suse.cz, Qu Wenruo <wqu@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 00/13] btrfs: make read repair work in synchronous mode
Date: Fri, 13 May 2022 07:01:11 +0800	[thread overview]
Message-ID: <fc35699e-236d-655c-bb2e-7dc1748b50fd@gmx.com> (raw)
In-Reply-To: <20220512170857.GS18596@twin.jikos.cz>



On 2022/5/13 01:08, David Sterba wrote:
> On Tue, May 03, 2022 at 02:49:44PM +0800, Qu Wenruo wrote:
>
>> By this we can:
>> - Remove the re-entry behavior of endio function
>>    Now everything is handled inside end_bio_extent_readpage().
>>
>> - Remove the io_failure_tree completely
>>    As we don't need to record which mirror has failed.
>>
>> - Slightly reduced overhead on read repair
>>    Now we won't call btrfs_map_bio() for each corrupted sector, as we can
>>    merge the sectors into a much larger bio.
>
> I thake this as the summary points for the whole patchset and frankly I
> don't see it justified given all the new problems with the preallocation
> and shuffling with the structures. What we have now is not perfect and I
> would like to get rid of the io_failure_tree too, yet it works.

Indeed I have no better solution for the bitmap.

I have one very limited optimization for it, e.g. if we hit profiles
without any extra mirrors (like RAID0/SINGLE), we skip the preallocation
and just error out.

But that's all, we have to allocate the memory, and since I'm neither a
fan of mempool (nor a good fit for variable length bitmap), we really
only have two solutions:

- Allocate bitmap when we hit the first error
   The way I did in previous RFC version.
   But it also means, if the memory allocation failed, we will error out
   without reading out the correct mirror. (Christoph is strongly against
   the error path)

- Preallocate bitmap before we submit the bio
   The way I did in this version.

Now I think the first solution would be more sane, no change in
btrfs_bio (which is already big).
And the memory allocation failure will not really cause any bit damage,
VFS will re-try a read with much smaller block size.

>
> The main point is probably to stop reentering the functions, though the
> idea of having a single tree that tracks the repair state and there are
> callbacks dealing with that is not IMHO bad design. The alternative is
> to complicate data structures and endio handler. I'm not sure if it's
> worth the risk.

The point of the repair work is a first step towards less members in
btrfs_bio.

In fact, all logical read/write should not really care about read
repair/csum/mirror num etc.

Thus it can be hidden into lower layer, thus my ultimate goal is to make
logical layer to only use plain bio completely.

But the existing read repair is a blockage, thus why I'm purposing this
patchset.

Thanks,
Qu

      reply	other threads:[~2022-05-12 23:01 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-03  6:49 [PATCH 00/13] btrfs: make read repair work in synchronous mode Qu Wenruo
2022-05-03  6:49 ` [PATCH 01/13] btrfs: introduce a pure data checksum checking helper Qu Wenruo
2022-05-03 15:03   ` Christoph Hellwig
2022-05-03  6:49 ` [PATCH 02/13] btrfs: quit early if the fs has no RAID56 support for raid56 related checks Qu Wenruo
2022-05-03  6:49 ` [PATCH 03/13] btrfs: save the original bi_iter into btrfs_bio for buffered read Qu Wenruo
2022-05-03  6:49 ` [PATCH 04/13] btrfs: remove duplicated parameters from submit_data_read_repair() Qu Wenruo
2022-05-03  6:49 ` [PATCH 05/13] btrfs: add btrfs_read_repair_ctrl to record corrupted sectors Qu Wenruo
2022-05-03 15:06   ` Christoph Hellwig
2022-05-04  1:12     ` Qu Wenruo
2022-05-04 14:05       ` Christoph Hellwig
2022-05-04 22:40         ` Qu Wenruo
2022-05-12 17:16           ` David Sterba
2022-05-13 10:33             ` Christoph Hellwig
2022-05-13 10:53               ` Qu Wenruo
2022-05-13 10:57                 ` Christoph Hellwig
2022-05-13 11:21                   ` Qu Wenruo
2022-05-13 11:23                     ` Christoph Hellwig
2022-05-17 13:32                       ` Qu Wenruo
2022-05-03  6:49 ` [PATCH 06/13] btrfs: add a helper to queue a corrupted sector for read repair Qu Wenruo
2022-05-03 15:07   ` Christoph Hellwig
2022-05-04  1:13     ` Qu Wenruo
2022-05-04 14:06       ` Christoph Hellwig
2022-05-12 17:20         ` David Sterba
2022-05-03  6:49 ` [PATCH 07/13] btrfs: introduce a helper to repair from one mirror Qu Wenruo
2022-05-03  6:49 ` [PATCH 08/13] btrfs: allow btrfs read repair to submit writes in asynchronous mode Qu Wenruo
2022-05-03  6:49 ` [PATCH 09/13] btrfs: handle RAID56 read repair differently Qu Wenruo
2022-05-03  6:49 ` [PATCH 10/13] btrfs: switch buffered read to the new read repair routine Qu Wenruo
2022-05-03  6:49 ` [PATCH 11/13] btrfs: switch direct IO routine to use btrfs_read_repair_ctrl Qu Wenruo
2022-05-03  6:49 ` [PATCH 12/13] btrfs: remove io_failure_record infrastructure completely Qu Wenruo
2022-05-03  6:49 ` [PATCH 13/13] btrfs: remove btrfs_inode::io_failure_tree Qu Wenruo
2022-05-03 15:07   ` Christoph Hellwig
2022-05-12 17:08 ` [PATCH 00/13] btrfs: make read repair work in synchronous mode David Sterba
2022-05-12 23:01   ` Qu Wenruo [this message]

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=fc35699e-236d-655c-bb2e-7dc1748b50fd@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.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