Re: Any way to ensure minimal folio size and alignment for iomap based direct IO?

Qu Wenruo
2025-09-15T21:47:22Z

在 2025/9/16 03:42, Pankaj Raghav (Samsung) 写道:
>>> But unfortunately I can not find any folio allocation for the direct IO
>>> routine except the zero_page...
>>>
>>> Any clue on the iomap part, or is the btrfs requirement incompatible with
>>> iomap in the first place?
>>
>> It's nothing to do with iomap. We can't make the assumption that
>> userspace is using large folios for, eg, anonymous memory. Or if
>> the memory is backed by page cache, we can't assume that the file
>> that's mmaped is on a similarly-aligned block device.
>
> Just to add to willy's point, XFS did not have this requirement when we
> upstreamed block size > page size support. The only thing that XFS does
> is to pad the direct I/O with zeroes if I/O was smaller than block size.
>
> Is it very difficult to add multi-shot checksum calls for a data block
> in btrfs? Does it break certain reliability guarantees?

I'd say it's not impossible, but still not an easy thing to do.

E.g. at data read time we need to verify the checksum. Currently we're
able to do the checksum for one block in one go, then advance the bio iter.

But with multi-shot one, we have to update the shash several times
before we can determine if the result is correct.

There is even compression algorithm which can not support multi-shot
interface, lzo.

Thankfully compression is only possible for buffered IO, so it's not
involved in this case.

>
> Another crazy idea would be to either fall back to buffered I/O if this
> condition is not met or allocate a new folio and copy the contents so that
> it meets the condition of single large folio that matches the block
> size (like we do in bio_copy_user_iov() when we cannot map).

I'd prefer to reject the direct IO completely, but also fine with
falling back to buffered IO.

However then the problem is why the read iov_iter passes the alignment
check, but we still get the bio not meeting the large folio requirement?

Anyway the direction is clear (double check on the iov iter alignment),
and for the worst case, introduce multi-shot checksum verification code.

Thanks a lot for the help,
Qu

>
> --
> Pankaj