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

[Jeremy Allison]

On Tue, May 01, 2018 at 10:52:30PM +0300, Uri Simchoni wrote:
> 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

Well, I'm trying to simplify the VFS so that the
primary access methods are async.

If you want sync you can always wrap the sync calls
inside an async tevent wrapper - exactly how I did
in the "fake" async fsync_send/fsync_recv I implemented
for ceph (as far as I know, the ceph userspace library
doesn't have async IO). That way, although the smbd
code is making async calls, underneath the covers
it's actually doing sync requests.

It does make creating a VFS a little more complex,
in that you need to understand tevent in order to
implement, but that requirement is coming anyway as
metze and Ralph are planning on moving more of our
underlying file accesses to the
async-with-pthread-credentials model.

Right now a read request does:

	a). Attempt pread_send().
	b). If that fails (not implemented) try sendfile
	c). If that isn't present fall back to synchronous
		pread.

Write requests do the same, only using recvfile
instead of sendfile.

The only problem I can see with hiding the
sync pread inside an async pread_send interface
is that it breaks the ability to fall back to
sendfile if there really isn't an async pread
available.

Now would be a good time for vendors with exotic
filesystem backends to chime in if it's really
easier for us to keep the two pread/pread_send
read methods (I don't think there's any argument
that simple 'read' needs to go :-).

Jeremy.