From: David Sterba <dsterba@suse.cz>
To: Christoph Hellwig <hch@infradead.org>
Cc: Qu Wenruo <quwenruo.btrfs@gmx.com>, Qu Wenruo <wqu@suse.com>,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 06/13] btrfs: add a helper to queue a corrupted sector for read repair
Date: Thu, 12 May 2022 19:20:15 +0200 [thread overview]
Message-ID: <20220512172015.GU18596@twin.jikos.cz> (raw)
In-Reply-To: <YnKIXKqBpa7gU/DO@infradead.org>
On Wed, May 04, 2022 at 07:06:20AM -0700, Christoph Hellwig wrote:
> On Wed, May 04, 2022 at 09:13:43AM +0800, Qu Wenruo wrote:
> > On 2022/5/3 23:07, Christoph Hellwig wrote:
> > > This adds an ununused static function and thus doesn't even compile.
> >
> > It's just a warning and can pass the compile.
> >
> > Or we have to have a patch with over 400 lines.
>
> The latter is the only thing that makes sense. Patches that are not
> self contained also can't be reviewed self contained. A larger patch
> is much better than a random split.
We've been doing it the way where a complex function is in a separate
patch and its usage in another one. Yes there are different preferences
and opinions on that. It also depends how one does the review, either in
the mails or in the code. For me it's fine with the split as once I'm at
second patch the function exists in the file. In the mails it's "how
does it work" and "how it is used", so this can be seen as two different
things, thus in two patches. On exception a short function in the same
patch as it's use makes sense, for bigger ones I'm for patch split.
next prev parent reply other threads:[~2022-05-12 17:24 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 [this message]
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
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=20220512172015.GU18596@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=hch@infradead.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--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