linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Matthew Wilcox <willy@infradead.org>
Cc: Kent Overstreet <kent.overstreet@linux.dev>,
	Hongbo Li <lihongbo22@huawei.com>,
	linux-bcachefs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-block@vger.kernel.org, axboe@kernel.dk, hch@lst.de
Subject: Re: bvec_iter.bi_sector -> loff_t? (was: Re: [PATCH] bcachefs: allow direct io fallback to buffer io for) unaligned length or offset
Date: Thu, 20 Jun 2024 17:30:50 +0200	[thread overview]
Message-ID: <20240620153050.GA26369@lst.de> (raw)
In-Reply-To: <ZnQ0gdpcplp_-aw7@casper.infradead.org>

On Thu, Jun 20, 2024 at 02:54:09PM +0100, Matthew Wilcox wrote:
> I'm against it.  Block devices only do sector-aligned IO and we should
> not pretend otherwise.

While I agree with that, the bvec_iter is actually used in a few other
places and could be used in more, and the 512-byte sector unit bi_sector
is the only weird thing that's not useful elsewhere.  So turning that
into a

	u64 bi_addr;

that is byte based where the meaning is specific to the user would
actually be kinda nice.  For traditional block users we'd need a
bio_sector() helpers similar to the existing bio_sectors() one,
but a lot of non-trivial drivers actually need to translated to
a variable LBA-based addressing, which would be (a tiny little bit)
simpler with the byte address.   As bi_size is already in bytes
it would also fit in pretty naturally with that.

The only thing that is really off putting is the amount of churn that
this would cause.

  parent reply	other threads:[~2024-06-20 15:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20240620132157.888559-1-lihongbo22@huawei.com>
2024-06-20 13:36 ` bvec_iter.bi_sector -> loff_t? (was: Re: [PATCH] bcachefs: allow direct io fallback to buffer io for) unaligned length or offset Kent Overstreet
2024-06-20 13:54   ` Matthew Wilcox
2024-06-20 14:16     ` Kent Overstreet
2024-06-20 14:49       ` Matthew Wilcox
2024-06-20 14:56         ` bvec_iter.bi_sector -> loff_t? Jens Axboe
2024-06-20 15:15           ` Matthew Wilcox
2024-06-20 15:18             ` Jens Axboe
2024-06-20 16:26               ` Keith Busch
2024-06-20 15:20             ` Christoph Hellwig
2024-06-20 15:21               ` Jens Axboe
2024-06-21  2:37           ` Hongbo Li
2024-06-21  3:05             ` Kent Overstreet
2024-06-20 15:35         ` bvec_iter.bi_sector -> loff_t? (was: Re: [PATCH] bcachefs: allow direct io fallback to buffer io for) unaligned length or offset Kent Overstreet
2024-06-21  3:13         ` bvec_iter.bi_sector -> loff_t? Hongbo Li
2024-06-20 15:30     ` Christoph Hellwig [this message]
2024-06-20 15:43       ` bvec_iter.bi_sector -> loff_t? (was: Re: [PATCH] bcachefs: allow direct io fallback to buffer io for) unaligned length or offset Kent Overstreet
2024-06-21  1:48         ` Ming Lei
2024-06-21  3:07           ` Kent Overstreet
2024-06-21  3:36             ` Ming Lei
2024-06-21  3:52               ` Kent Overstreet

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=20240620153050.GA26369@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=kent.overstreet@linux.dev \
    --cc=lihongbo22@huawei.com \
    --cc=linux-bcachefs@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).