Re: [f2fs-dev] [PATCH] f2fs: f2fs supports uncached buffered I/O read

[Jens Axboe <axboe@kernel.dk>]

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.

-- 
Jens Axboe


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel