All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>,
	Damien Le Moal <damien.lemoal@wdc.com>,
	Naohiro Aota <naohiro.aota@wdc.com>,
	Johannes Thumshirn <johannes.thumshirn@wdc.com>,
	Qu Wenruo <wqu@suse.com>, Jens Axboe <axboe@kernel.dk>,
	"Darrick J. Wong" <djwong@kernel.org>,
	linux-block@vger.kernel.org, linux-btrfs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 03/34] btrfs: add a btrfs_inode pointer to struct btrfs_bio
Date: Wed, 8 Mar 2023 06:21:34 +0800	[thread overview]
Message-ID: <96f5c29c-1b25-66af-1ba1-731ae39d912d@gmx.com> (raw)
In-Reply-To: <20230307144106.GA19477@lst.de>



On 2023/3/7 22:41, Christoph Hellwig wrote:
> On Tue, Mar 07, 2023 at 09:44:32AM +0800, Qu Wenruo wrote:
>> With my recent restart on scrub rework, this patch makes me wonder, what if
>> scrub wants to use btrfs_bio, but don't want to pass a valid btrfs_inode
>> pointer?
> 
> The full inode is only really needed for the data repair code.  But a lot
> of code uses the fs_info, which would have to be added as a separate
> counter.  The other usage is the sync_writers counter, which is a bit
> odd and should probably be keyed off the REQ_SYNC flag instead.
> 
>> E.g. scrub code just wants to read certain mirror of a logical bytenr.
>> This can simplify the handling of RAID56, as for data stripes the repair
>> path is the same, just try the next mirror(s).
>>
>> Furthermore most of the new btrfs_bio code is handling data reads by
>> triggering read-repair automatically.
>> This can be unnecessary for scrub.
> 
> This sounds like you don't want to use the btrfs_bio at all as you
> don't rely on any of the functionality from it.

Well, to me the proper mirror_num based read is the core of btrfs_bio, 
not the read-repair thing.

Thus I'm not that convinced fully automatic read-repair integrated into 
btrfs_bio is a good idea.

Thanks,
Qu
> 
>>
>> And since we're here, can we also have btrfs equivalent of on-stack bio?
>> As scrub can benefit a lot from that, as for sector-by-sector read, we want
>> to avoid repeating allocating/freeing a btrfs_bio just for reading one
>> sector.
>> (The existing behavior is using on-stack bio with bio_init/bio_uninit
>> inside scrub_recheck_block())
> 
> You can do that right now by declaring a btrfs_bio on-stack and then
> calling bio_init on the embedded bio followed by a btrfs_bio_init on
> the btrfs_bio.  But I don't think doing this will actually be a win
> for the scrub code in terms of speed or code size.

  reply	other threads:[~2023-03-07 22:22 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-21  6:49 consolidate btrfs checksumming, repair and bio splitting v4 Christoph Hellwig
2023-01-21  6:49 ` [PATCH 01/34] block: export bio_split_rw Christoph Hellwig
2023-01-21  6:49 ` [PATCH 02/34] btrfs: better document struct btrfs_bio Christoph Hellwig
2023-01-22 10:19   ` Anand Jain
2023-01-23 15:25   ` Johannes Thumshirn
2023-01-21  6:50 ` [PATCH 03/34] btrfs: add a btrfs_inode pointer to " Christoph Hellwig
2023-01-22 10:20   ` Anand Jain
2023-01-23 15:26   ` Johannes Thumshirn
2023-01-23 15:47   ` Johannes Thumshirn
2023-03-07  1:44   ` Qu Wenruo
2023-03-07 14:41     ` Christoph Hellwig
2023-03-07 22:21       ` Qu Wenruo [this message]
2023-03-08  6:04         ` Qu Wenruo
2023-03-08 14:28           ` Christoph Hellwig
2023-03-09  0:08             ` Qu Wenruo
2023-03-09  9:31               ` Christoph Hellwig
2023-03-09 10:32                 ` Qu Wenruo
2023-03-09 15:18                   ` Christoph Hellwig
2023-01-21  6:50 ` [PATCH 04/34] btrfs: remove the direct I/O read checksum lookup optimization Christoph Hellwig
2023-01-23 15:59   ` Johannes Thumshirn
2023-01-24 14:55   ` Anand Jain
2023-01-24 19:55     ` Christoph Hellwig
2023-01-25  7:42       ` Anand Jain
2023-01-21  6:50 ` [PATCH 05/34] btrfs: simplify btrfs_lookup_bio_sums Christoph Hellwig
2023-01-23 16:06   ` Johannes Thumshirn
2023-01-24 15:16   ` Anand Jain
2023-01-21  6:50 ` [PATCH 06/34] btrfs: slightly refactor btrfs_submit_bio Christoph Hellwig
2023-01-23 16:13   ` Johannes Thumshirn
2023-01-24 15:27   ` Anand Jain
2023-01-21  6:50 ` [PATCH 07/34] btrfs: save the bio iter for checksum validation in common code Christoph Hellwig
2023-01-23 16:18   ` Johannes Thumshirn
2023-01-21  6:50 ` [PATCH 08/34] btrfs: pre-load data checksum for reads in btrfs_submit_bio Christoph Hellwig
2023-01-23 16:32   ` Johannes Thumshirn
2023-01-21  6:50 ` [PATCH 09/34] btrfs: add a btrfs_data_csum_ok helper Christoph Hellwig
2023-01-23 16:36   ` Johannes Thumshirn
2023-01-21  6:50 ` [PATCH 10/34] btrfs: handle checksum validation and repair at the storage layer Christoph Hellwig
2023-01-23 16:39   ` Johannes Thumshirn
2023-01-24  6:47     ` Christoph Hellwig
2023-01-24  8:16       ` Johannes Thumshirn
2023-01-21  6:50 ` [PATCH 11/34] btrfs: remove btrfs_bio_free_csum Christoph Hellwig
2023-01-23 16:41   ` Johannes Thumshirn
2023-01-21  6:50 ` [PATCH 12/34] btrfs: remove btrfs_bio_for_each_sector Christoph Hellwig
2023-01-23 16:42   ` Johannes Thumshirn
2023-01-21  6:50 ` [PATCH 13/34] btrfs: remove now unused checksumming helpers Christoph Hellwig
2023-01-23 16:49   ` Johannes Thumshirn
2023-01-23 16:53     ` Christoph Hellwig
2023-01-24  8:33       ` Johannes Thumshirn
2023-01-21  6:50 ` [PATCH 14/34] btrfs: remove the device field in struct btrfs_bio Christoph Hellwig
2023-01-24 11:01   ` Johannes Thumshirn
2023-01-21  6:50 ` [PATCH 15/34] btrfs: remove the io_failure_record infrastructure Christoph Hellwig
2023-01-24 11:04   ` Johannes Thumshirn
2023-01-21  6:50 ` [PATCH 16/34] btrfs: rename the iter field in struct btrfs_bio Christoph Hellwig
2023-01-24 11:09   ` Johannes Thumshirn
2023-01-21  6:50 ` [PATCH 17/34] btrfs: remove the is_metadata flag " Christoph Hellwig
2023-01-24 11:13   ` Johannes Thumshirn
2023-01-21  6:50 ` [PATCH 18/34] btrfs: remove the submit_bio_start helpers Christoph Hellwig
2023-01-24 11:49   ` Johannes Thumshirn
2023-01-21  6:50 ` [PATCH 19/34] btrfs: simplify the btrfs_csum_one_bio calling convention Christoph Hellwig
2023-01-21  6:50 ` [PATCH 20/34] btrfs: handle checksum generation in the storage layer Christoph Hellwig
2023-01-21  6:50 ` [PATCH 21/34] btrfs: handle recording of zoned writes " Christoph Hellwig
2023-01-21  6:50 ` [PATCH 22/34] btrfs: support cloned bios in btree_csum_one_bio Christoph Hellwig
2023-01-21  6:50 ` [PATCH 23/34] btrfs: allow btrfs_submit_bio to split bios Christoph Hellwig
2023-01-25 21:51   ` Josef Bacik
2023-01-26  5:21     ` Christoph Hellwig
2023-01-26 17:43       ` Josef Bacik
2023-01-26 17:46         ` Christoph Hellwig
2023-01-26 18:33           ` David Sterba
2023-01-27  7:02             ` test not in the auto group, was: " Christoph Hellwig
2023-01-21  6:50 ` [PATCH 24/34] btrfs: pass the iomap bio to btrfs_submit_bio Christoph Hellwig
2023-01-21  6:50 ` [PATCH 25/34] btrfs: remove stripe boundary calculation for buffered I/O Christoph Hellwig
2023-01-21  6:50 ` [PATCH 26/34] btrfs: remove stripe boundary calculation for compressed I/O Christoph Hellwig
2023-01-21  6:50 ` [PATCH 27/34] btrfs: remove stripe boundary calculation for encoded I/O Christoph Hellwig
2023-01-21  6:50 ` [PATCH 28/34] btrfs: remove struct btrfs_io_geometry Christoph Hellwig
2023-01-21  6:50 ` [PATCH 29/34] btrfs: remove submit_encoded_read_bio Christoph Hellwig
2023-01-21  6:50 ` [PATCH 30/34] btrfs: remove the fs_info argument to btrfs_submit_bio Christoph Hellwig
2023-01-21  6:50 ` [PATCH 31/34] btrfs: remove now spurious bio submission helpers Christoph Hellwig
2023-01-21  6:50 ` [PATCH 32/34] btrfs: calculate file system wide queue limit for zoned mode Christoph Hellwig
2023-01-21  6:50 ` [PATCH 33/34] btrfs: split zone append bios in btrfs_submit_bio Christoph Hellwig
2023-01-21  6:50 ` [PATCH 34/34] iomap: remove IOMAP_F_ZONE_APPEND Christoph Hellwig
2023-01-24 13:22 ` consolidate btrfs checksumming, repair and bio splitting v4 Christoph Hellwig

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=96f5c29c-1b25-66af-1ba1-731ae39d912d@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=axboe@kernel.dk \
    --cc=clm@fb.com \
    --cc=damien.lemoal@wdc.com \
    --cc=djwong@kernel.org \
    --cc=dsterba@suse.com \
    --cc=hch@lst.de \
    --cc=johannes.thumshirn@wdc.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=naohiro.aota@wdc.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 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.