Re: bvec_iter.bi_sector -> loff_t?

[Hongbo Li <lihongbo22@huawei.com>]

On 2024/6/20 22:56, Jens Axboe wrote:
> On 6/20/24 8:49 AM, Matthew Wilcox wrote:
>> On Thu, Jun 20, 2024 at 10:16:02AM -0400, Kent Overstreet wrote:
>> I'm more sympathetic to "lets relax the alignment requirements", since
>> most IO devices actually can do IO to arbitrary boundaries (or at least
>> reasonable boundaries, eg cacheline alignment or 4-byte alignment).
>> The 512 byte alignment doesn't seem particularly rooted in any hardware
>> restrictions.
> 
> We already did, based on real world use cases to avoid copies just
> because the memory wasn't aligned on a sector size boundary. It's
> perfectly valid now to do:
> 
> struct queue_limits lim {
> 	.dma_alignment = 3,
> };
> 
> disk = blk_mq_alloc_disk(&tag_set, &lim, NULL);
> 
> and have O_DIRECT with a 32-bit memory alignment work just fine, where
Does this mean that file system can relax its alignment restrictions on 
offset or memory (not 512 or 4096)? Is it necessary to add alignment 
restrictions in the super block of file system? Because there are 
different alignment restrictions for different storage hardware driver.

Thanks,
Hongbo
> before it would EINVAL. The sector size memory alignment thing has
> always been odd and never rooted in anything other than "oh let's just
> require the whole combination of size/disk offset/alignment to be sector
> based".
> 
>> But size?  Fundamentally, we're asking the device to do IO directly to
>> this userspace address.  That means you get to do the entire IO, not
>> just the part of it that you want.  I know some devices have bitbucket
>> descriptors, but many don't.
> 
> We did poke at that a bit for nvme with bitbuckets, but I don't even
> know how prevalent that support is in hardware. Definitely way iffier
> and spotty than the alignment, where that limit was never based on
> anything remotely resembling a hardware restraint.
> 
>>>> I'm against it.  Block devices only do sector-aligned IO and we should
>>>> not pretend otherwise.
>>>
>>> Eh?
>>>
>>> bio isn't really specific to the block layer anyways, given that an
>>> iov_iter can be a bio underneath. We _really_ should be trying for
>>> better commonality of data structures.
>>
>> bio is absolutely specific to the block layer.  Look at it:
> 
> It's literally "block IO", so would have to concur with that.
>