mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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,

> 


  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®