[PATCH] Add missing async fsync_send()/recv() code to ceph VFS.

[Uri Simchoni]

On 05/01/2018 10:08 PM, Jeremy Allison via samba-technical wrote:
> On Mon, Apr 30, 2018 at 02:46:25PM -0700, Jeremy Allison via samba-technical wrote:
>> On Mon, Apr 30, 2018 at 07:03:01PM +0200, Ralph Böhme wrote:
>>> On Mon, Apr 30, 2018 at 09:30:41AM -0700, Jeremy Allison wrote:
>>>> On Mon, Apr 30, 2018 at 11:29:16AM +0200, Ralph Böhme wrote:
>>>>>
>>>>> vfs_ceph doesn't implement profiling so it doesn't really matter, cf the
>>>>> SMBPROFILE_BYTES_ASYNC_* macros in vfs_default how it would look like.
>>>>>
>>>>> So I guess you can either remove the PROFILE_TIMESTAMP macro invocations or
>>>>> implement the profiling stuff.
>>>>
>>>> OK, here is version #2, including the changes you guys discussed.
>>>>
>>>> Please review and push if happy. I have a follow-up patch that
>>>> removes all uses of the synchronous fsync_fn() from the VFS once
>>>> this one goes in :-).
>>>
>>> pushed.
>>
>> Hurrah - it went in, thanks ! Now I have your attention,
>> here is the follow-up that removes the synchronous fsync_fn()
>> completely from the VFS.
>>
>> Please review and let me know what you think !
>>
>> FYI: I'm half way though doing the same for SMB_VFS_READ
>> (converting that to SMB_VFS_PREAD everywhere and then
>> moving SMB_VFS_PREAD -> SMB_VFS_PREAD_SEND/SMB_VFS_PREAD_RECV
>> pairs). Finally I'll get to SMB_VFS_WRITE and do the same,
>> and we should end up with only *one* way to do a VFS
>> FSYNC/READ/WRITE in the backend - and that will be asynchronous,
>> instead of the current two or three different ways, some
>> sync, some async.
> 
> FYI Ralph, I know you're busy - but I've now got working
> code that builds on top of this patch that eliminates
> all uses of SMB_VFS_READ ! SMB_VFS_WRITE next, then
> convert all users of SMB_VFS_PREAD/SMB_VFS_PWRITE to
> the async versions, then we have the holy grail of
> all read/write I/O being done async as the only method
> available !
> 
> Jeremy.
> 

Hmm... if you can get rid of READ, that's great but do you really want
to get rid of PREAD/PWRITE?

To quote your SambaXP performance talk [1], the best IO strategy
"Completely depends on available system resources" and on access patterns.

Taking the "tweaking power" away from users/vendors might upset some people.

[1]
https://sambaxp.org/archive_data/SambaXP2012-DATA/thu/track1/Jeremy_Allison-The-Evolution-of-IO.pdf


Thanks,
Uri.