linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: "Pankaj Raghav (Samsung)" <kernel@pankajraghav.com>,
	Matthew Wilcox <willy@infradead.org>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	linux-btrfs <linux-btrfs@vger.kernel.org>,
	linux-mm@kvack.org, mcgrof@kernel.org, p.raghav@samsung.com
Subject: Re: Any way to ensure minimal folio size and alignment for iomap based direct IO?
Date: Tue, 16 Sep 2025 07:16:48 +0930	[thread overview]
Message-ID: <fc7da57f-5b11-4056-857c-bb16a4a20bb5@gmx.com> (raw)
In-Reply-To: <2h2azgruselzle2roez7umdh5lghtm7kkfxib26pxzsjhmcdja@x3wjdx2r6jeu>



在 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



  reply	other threads:[~2025-09-15 21:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <9598a140-aa45-4d73-9cd2-0c7ca6e4020a@gmx.com>
2025-09-15 13:03 ` Matthew Wilcox
2025-09-15 18:12   ` Pankaj Raghav (Samsung)
2025-09-15 21:46     ` Qu Wenruo [this message]
2025-09-15 23:05       ` Matthew Wilcox
2025-09-15 23:20         ` 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=fc7da57f-5b11-4056-857c-bb16a4a20bb5@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=kernel@pankajraghav.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mcgrof@kernel.org \
    --cc=p.raghav@samsung.com \
    --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