From: Ryan Ding <ryan.ding@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH 0/9 v6] ocfs2: support append O_DIRECT write
Date: Wed, 05 Aug 2015 12:40:10 +0800 [thread overview]
Message-ID: <55C193AA.5020508@oracle.com> (raw)
In-Reply-To: <55C07FFA.4060701@huawei.com>
Hi Joseph,
On 08/04/2015 05:03 PM, Joseph Qi wrote:
> Hi Ryan,
>
> On 2015/8/4 14:16, Ryan Ding wrote:
>> Hi Joseph,
>>
>> Sorry for bothering you with the old patches. But I really need to know what this patch is for.
>>
>> https://oss.oracle.com/pipermail/ocfs2-devel/2015-January/010496.html
>>
>> From above email archive, you mentioned those patches aim to reduce the host page cache consumption. But in my opinion, after append direct io, the page used for buffer is clean. System can realloc those cached pages. We can even call invalidate_mapping_pages to fast that process. Maybe more pages will be needed during direct io. But direct io size can not be too large, right?
>>
> We introduced the append direct io because originally ocfs2 would fall
> back to buffer io in case of thin provision, which was not the actual
> behavior that user expect.
direct io has 2 semantics:
1. io is performed synchronously, data is guaranteed to be transferred
after write syscall return.
2. File I/O is done directly to/from user space buffers. No page buffer
involved.
But I think #2 is invisible to user space, #1 is the only thing that
user space is really interested in.
We should balance the benefit and disadvantage to determine whether #2
should be supported.
The disadvantage is: bring too much complexity to the code, bugs will
come along. And involved a incompatible feature.
For example, I did a single node sparse file test, and it failed.
The original way of ocfs2 handling direct io(turn to buffer io when it's
append write or write to a file hole) has 2 consideration:
1. easier to support cluster wide coherence.
2. easier to support sparse file.
But it seems that your patch handle #2 not very well.
There may be more issues that I have not found.
> I didn't get you that more pages would be needed during direct io. Could
> you please explain it more clearly?
I mean the original way of handle append-dio will consume some page
cache. The page cache size it consume depend on the direct io size. For
example, 1MB direct io will consume 1MB page cache.But since direct io
size can not be too large, the page cache it consume can not be too
large also. And those pages can be freed after direct io finished by
calling invalidate_mapping_pages().
>
> Thanks,
> Joseph
>
>> Thanks,
>> Ryan
>>
>>
>
next prev parent reply other threads:[~2015-08-05 4:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-04 6:16 [Ocfs2-devel] [PATCH 0/9 v6] ocfs2: support append O_DIRECT write Ryan Ding
2015-08-04 9:03 ` Joseph Qi
2015-08-05 4:40 ` Ryan Ding [this message]
2015-08-05 6:40 ` Joseph Qi
2015-08-05 8:07 ` Ryan Ding
2015-08-05 11:18 ` Joseph Qi
2015-08-06 2:35 ` Ryan Ding
2015-08-05 7:08 ` Joseph Qi
-- strict thread matches above, loose matches on Subject: below --
2015-01-20 8:01 Joseph Qi
2015-01-20 8:26 ` Junxiao Bi
2015-01-20 9:00 ` Joseph Qi
2015-01-22 2:10 ` Junxiao Bi
2015-01-22 3:54 ` Joseph Qi
2015-01-22 5:06 ` Junxiao Bi
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=55C193AA.5020508@oracle.com \
--to=ryan.ding@oracle.com \
--cc=ocfs2-devel@oss.oracle.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.