On July 21, 2023 1:27:26 PM GMT+02:00, Hao Xu <hao.xu@xxxxxxxxx> wrote:
>On 7/21/23 14:35, Jiachen Zhang wrote:
>>
>> On 2023/6/30 17:46, Hao Xu wrote:
>>> From: Hao Xu <howeyxu@xxxxxxxxxxx>
>>>
>>> In direct_io_relax mode, there can be shared mmaped files and thus dirty
>>> pages in its page cache. Therefore those dirty pages should be written
>>> back to backend before direct write to avoid data loss.
>>>
>>> Signed-off-by: Hao Xu <howeyxu@xxxxxxxxxxx>
>>> ---
>>> fs/fuse/file.c | 7 +++++++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
>>> index 176f719f8fc8..7c9167c62bf6 100644
>>> --- a/fs/fuse/file.c
>>> +++ b/fs/fuse/file.c
>>> @@ -1485,6 +1485,13 @@ ssize_t fuse_direct_io(struct fuse_io_priv *io, struct iov_iter *iter,
>>> if (!ia)
>>> return -ENOMEM;
>>> + if (fopen_direct_write && fc->direct_io_relax) {
>>> + res = filemap_write_and_wait_range(mapping, pos, pos + count - 1);
>>> + if (res) {
>>> + fuse_io_free(ia);
>>> + return res;
>>> + }
>>> + }
>>> if (!cuse && fuse_range_is_writeback(inode, idx_from, idx_to)) {
>>> if (!write)
>>> inode_lock(inode);
>>
>> Tested-by: Jiachen Zhang <zhangjiachen.jaycee@xxxxxxxxxxxxx>
>>
>>
>> Looks good to me.
>>
>> By the way, the behaviour would be a first FUSE_WRITE flushing the page cache, followed by a second FUSE_WRITE doing the direct IO. In the future, further optimization could be first write into the page cache and then flush the dirty page to the FUSE daemon.
>>
>
>I think this makes sense, cannot think of any issue in it for now, so
>I'll do that change and send next version, super thanks, Jiachen!
>
>Thanks,
>Hao
>
>>
>> Thanks,
>> Jiachen
>
On my phone, sorry if mail formatting is not optimal.
Do I understand it right? You want DIO code path copy into pages and then flush/invalidate these pages? That would be punish DIO for for the unlikely case there are also dirty pages (discouraged IO pattern).
