From: Christoph Hellwig <hch@infradead.org>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v7 02/13] btrfs: introduce a new allocator for scrub specific btrfs_bio
Date: Wed, 29 Mar 2023 16:32:50 -0700 [thread overview]
Message-ID: <ZCTKola6a+tbtyrL@infradead.org> (raw)
In-Reply-To: <c77fd4fd93c34a6d229765088ce0a88f7f8718d4.1680047473.git.wqu@suse.com>
> +struct btrfs_bio *btrfs_scrub_bio_alloc(blk_opf_t opf,
> + struct btrfs_fs_info *fs_info,
> + btrfs_bio_end_io_t end_io, void *private)
> +{
> + struct btrfs_bio *bbio;
> + struct bio *bio;
> +
> + bio = bio_alloc_bioset(NULL, BTRFS_STRIPE_LEN >> fs_info->sectorsize_bits,
> + opf, GFP_NOFS, &btrfs_bioset);
> + bbio = btrfs_bio(bio);
> + memset(bbio, 0, offsetof(struct btrfs_bio, bio));
> + bbio->fs_info = fs_info;
> + bbio->end_io = end_io;
> + bbio->private = private;
> + atomic_set(&bbio->pending_ios, 1);
> + return bbio;
As mentioned in the last round, I'm not too happy with this. With
the inode and file_offset being optional now we might as well drop them
as arguments from btrfs_bio_alloc/btrfs_bio_init and just pass a nr_vecs
instead and make this new allocator obsolete, and it would be a much
better result.
I'd prefer to just do it now rather than doing another series changing
it a little later.
> + /*
> + * Inode and offset into it that this I/O operates on.
> + *
> + * @inode can be NULL for callers who don't want any advanced features
> + * like read-time repair.
> + */
> struct btrfs_inode *inode;
> u64 file_offset;
I don't think these negative comments are nice for the reader. I'd do:
/*
* Inode and offset into it that this I/O operates on.
* Only set for data I/O.
*/
> + /*
> + * For cases where callers only want to read/write from a logical
> + * bytenr, in that case @inode can be NULL, and we need such
> + * @fs_info pointer to grab the corresponding fs_info.
> + *
> + * Should always be populated.
> + */
> + struct btrfs_fs_info *fs_info;
Again here, this comment only makes sense for people following the
development history of this particular patch series. Once that is in
the reason why people use an inode before is irrelevant. The only
useful bit left here is that it must always be populated, but I'm not
even sure I'd add that. So all we might need is:
/* File system that this I/O operates on. */
What would be good in this patch is to replace the
existing bbio->inode->root->fs_info dereferences with bbio->fs_info
ASAP, though.
next prev parent reply other threads:[~2023-03-29 23:32 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-28 23:56 [PATCH v7 00/13] btrfs: scrub: use a more reader friendly code to implement scrub_simple_mirror() Qu Wenruo
2023-03-28 23:56 ` [PATCH v7 01/13] btrfs: scrub: use dedicated super block verification function to scrub one super block Qu Wenruo
2023-03-29 0:29 ` Anand Jain
2023-03-29 9:20 ` Johannes Thumshirn
2023-03-29 9:53 ` Qu Wenruo
2023-03-29 23:25 ` Christoph Hellwig
2023-03-28 23:56 ` [PATCH v7 02/13] btrfs: introduce a new allocator for scrub specific btrfs_bio Qu Wenruo
2023-03-29 23:32 ` Christoph Hellwig [this message]
2023-03-29 23:39 ` Qu Wenruo
2023-03-29 23:47 ` Christoph Hellwig
2023-03-29 23:51 ` Qu Wenruo
2023-03-29 23:54 ` Christoph Hellwig
2023-03-28 23:56 ` [PATCH v7 03/13] btrfs: introduce a new helper to submit read bio for scrub Qu Wenruo
2023-03-29 23:33 ` Christoph Hellwig
2023-03-29 23:41 ` Qu Wenruo
2023-03-30 6:43 ` Qu Wenruo
2023-03-30 21:50 ` Christoph Hellwig
2023-03-28 23:56 ` [PATCH v7 04/13] btrfs: introduce a new helper to submit write " Qu Wenruo
2023-03-29 23:33 ` Christoph Hellwig
2023-03-30 6:47 ` Qu Wenruo
2023-03-30 22:13 ` Christoph Hellwig
2023-03-31 0:48 ` Qu Wenruo
2023-03-31 0:56 ` Qu Wenruo
2023-03-28 23:56 ` [PATCH v7 05/13] btrfs: scrub: introduce the structure for new BTRFS_STRIPE_LEN based interface Qu Wenruo
2023-03-28 23:56 ` [PATCH v7 06/13] btrfs: scrub: introduce a helper to find and fill the sector info for a scrub_stripe Qu Wenruo
2023-03-28 23:56 ` [PATCH v7 07/13] btrfs: scrub: introduce a helper to verify one metadata Qu Wenruo
2023-03-28 23:56 ` [PATCH v7 08/13] btrfs: scrub: introduce a helper to verify one scrub_stripe Qu Wenruo
2023-03-28 23:56 ` [PATCH v7 09/13] btrfs: scrub: introduce the main read repair worker for scrub_stripe Qu Wenruo
2023-03-28 23:56 ` [PATCH v7 10/13] btrfs: scrub: introduce a writeback helper " Qu Wenruo
2023-03-28 23:56 ` [PATCH v7 11/13] btrfs: scrub: introduce error reporting functionality " Qu Wenruo
2023-03-28 23:56 ` [PATCH v7 12/13] btrfs: scrub: introduce the helper to queue a stripe for scrub Qu Wenruo
2023-03-28 23:56 ` [PATCH v7 13/13] btrfs: scrub: switch scrub_simple_mirror() to scrub_stripe infrastructure 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=ZCTKola6a+tbtyrL@infradead.org \
--to=hch@infradead.org \
--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