From: Chao Yu <chao@kernel.org>
To: Jens Axboe <axboe@kernel.dk>, hanqi <hanqi@vivo.com>, jaegeuk@kernel.org
Cc: chao@kernel.org, linux-f2fs-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] f2fs: f2fs supports uncached buffered I/O read
Date: Tue, 5 Aug 2025 09:32:05 +0800 [thread overview]
Message-ID: <f8ab5bbf-79b0-42ac-9c61-d906593b5d8f@kernel.org> (raw)
In-Reply-To: <e163bbcd-b4d7-4a76-a42f-950f3cb5a644@kernel.dk>
On 8/2/25 23:35, Jens Axboe wrote:
> On 7/30/25 8:35 PM, Chao Yu wrote:
>> On 7/30/25 23:20, Jens Axboe wrote:
>>> 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.
>>
>> Jens,
>>
>> Do you mean like what we have done in kiocb_set_rw_flags()?
>>
>> if (flags & RWF_DONTCACHE) {
>> /* file system must support it */
>> if (!(ki->ki_filp->f_op->fop_flags & FOP_DONTCACHE))
>> return -EOPNOTSUPP;
>> ...
>> }
>>
>> IIUC, it's better to have this in original patch, let me know if I'm
>> missing something.
>
> Right, that would certainly be required to have it functional on the
> read side but not yet on the write side. Still leaves a weirder gap
> where other file systems (like XFS and ext4) you can rely on if read or
> write support is there, then the other direction is supported too. f2fs
> would be the only one where the read side works, but you get -EOPNOTSUPP
> on the write side.
>
> Unless there's a rush on the read side for some reason, I think it'd be
> better to have with setting FOP_DONTCACHE until the write side has been
> completed too.
Sure, let's wait for dontcache support in both read&write side, unless something
is blocked in write side, let's see. :)
Thanks,
>
next prev parent reply other threads:[~2025-08-05 1:32 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
2025-07-31 2:35 ` Chao Yu
2025-08-02 15:35 ` Jens Axboe
2025-08-05 1:32 ` Chao Yu [this message]
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=f8ab5bbf-79b0-42ac-9c61-d906593b5d8f@kernel.org \
--to=chao@kernel.org \
--cc=axboe@kernel.dk \
--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®