From: Jens Axboe <axboe@kernel.dk>
To: hanqi <hanqi@vivo.com>, Chao Yu <chao@kernel.org>, jaegeuk@kernel.org
Cc: linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] f2fs: f2fs supports uncached buffered I/O read
Date: Wed, 30 Jul 2025 20:05:29 -0600 [thread overview]
Message-ID: <0025981b-9acc-4b6c-a7bb-77bb0e3e543c@kernel.dk> (raw)
In-Reply-To: <d3ced6d7-4037-4962-a2d4-382af0aad4cd@vivo.com>
On 7/30/25 7:58 PM, hanqi wrote:
>
> ? 2025/7/30 23:20, Jens Axboe ??:
>> On 7/28/25 2:28 AM, hanqi wrote:
>>> ? 2025/7/28 16:07, Chao Yu ??:
>>>> On 7/28/25 16:03, hanqi wrote:
>>>>> ? 2025/7/28 15:38, Chao Yu ??:
>>>>>
>>>>>> On 7/25/25 15:53, Qi Han wrote:
>>>>>>> Jens has already completed the development of uncached buffered I/O
>>>>>>> in git [1], and in f2fs, uncached buffered I/O read can be enabled
>>>>>>> simply by setting the FOP_DONTCACHE flag in f2fs_file_operations.
>>>>>> IIUC, we may suffer lock issue when we call pwritev(.. ,RWF_DONTCACHE)?
>>>>>> as Jen mentioned in below path, right?
>>>>>>
>>>>>> soft-irq
>>>>>> - folio_end_writeback()
>>>>>> - filemap_end_dropbehind_write()
>>>>>> - filemap_end_dropbehind()
>>>>>> - folio_unmap_invalidate()
>>>>>> - lock i_lock
>>>>>>
>>>>>> Thanks,
>>>>> That's how I understand it.
>>>> So I guess we need to wait for the support RWF_DONTCACHE on write path, unless
>>>> you can walk around for write path in this patch.
>>>>
>>>> Thanks,
>>> I think the read and write paths can be submitted separately.
>>> Currently, uncached buffered I/O write requires setting the
>>> FGP_DONTCACHE flag when the filesystem allocates a folio. In
>>> f2fs, this is done in the following path:
>>>
>>> - write_begin
>>> - f2fs_write_begin
>>> - __filemap_get_folio
>>> As I understand it, if we don't set the FGP_DONTCACHE flag here, this
>>> issue shouldn't occur.
>> It won't cause an issue, but it also won't work in the sense that the
>> intent is that if the file system doesn't support DONTCACHE, it would
>> get errored at submission time. Your approach would just ignore the flag
>> for writes, rather than return -EOPNOTSUPP as would be expected.
>>
>> You could potentially make it work just on the read side by having the
>> f2fs write submit side check DONTCACHE on the write side and error them
>> out.
>
> Hi Jens,
>
> Thank you for your suggestions. I am currently working on modifying
> F2FS to handle the dontcache unmap operation in a workqueue. I expect
> to submit the patch soon, after which F2FS should also support uncached
> buffer I/O writes.
Sounds good, that's the right approach. Userspace needs to be able to
rely on the fact that if RWF_DONTCACHE io is submitted without error
that the target does the right thing as well, barring bugs of course.
--
Jens Axboe
next prev parent reply other threads:[~2025-07-31 2:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-25 7:53 Qi Han
2025-07-28 7:38 ` Chao Yu
2025-07-28 8:03 ` hanqi
2025-07-28 8:07 ` Chao Yu
2025-07-28 8:28 ` hanqi
2025-07-30 15:20 ` Jens Axboe
2025-07-31 1:58 ` hanqi
2025-07-31 2:05 ` Jens Axboe [this message]
2025-07-31 2:35 ` Chao Yu
2025-08-02 15:35 ` Jens Axboe
2025-08-05 1:32 ` Chao Yu
2025-07-30 8:14 ` Chao Yu
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=0025981b-9acc-4b6c-a7bb-77bb0e3e543c@kernel.dk \
--to=axboe@kernel.dk \
--cc=chao@kernel.org \
--cc=hanqi@vivo.com \
--cc=jaegeuk@kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®