impersonation part7 (smb_vfs_ev_glue)

[Stefan Metzmacher]

Am 25.07.2018 um 22:55 schrieb Jeremy Allison via samba-technical:
> On Wed, Jul 25, 2018 at 10:26:33PM +0200, Ralph Böhme wrote:
>> On Wed, Jul 25, 2018 at 01:32:23PM -0700, Jeremy Allison via samba-technical wrote:
>>> On Wed, Jul 25, 2018 at 10:29:31PM +0200, Stefan Metzmacher wrote:
>>>> Am 25.07.2018 um 22:26 schrieb Jeremy Allison via samba-technical:
>>>>> On Wed, Jul 25, 2018 at 04:36:47PM +0200, Stefan Metzmacher via samba-technical wrote:
>>>>>> Hi,
>>>>>>
>>>>>> here's an updated patchset. It also fixed a shutdown problem
>>>>>> during a deferred open (we need to free all request before removing
>>>>>> tcons/sessions). There's also a build fix and a vfs_not_implemented
>>>>>> module that exports helper function for use in other opaque modules.
>>>>>>
>>>>>> An earlier version with the same content almost finished this pipeline:
>>>>>> https://gitlab.com/samba-team/devel/samba/pipelines/26474532
>>>>>>
>>>>>> And a new one was also started here:
>>>>>> https://gitlab.com/samba-team/devel/samba/pipelines/26485958
>>>>>>
>>>>>> We'll most likely push this version later today.
>>>>>
>>>>> Just want to check, these are changes planned for 4.10
>>>>> yeah ?
>>>>
>>>> Yes, it's to late for 4.9, it just went to master and will just be in
>>>> the next release (4.10 or 5.0).
>>>
>>> Oh thank goodness :-). I haven't had time to read
>>> through all the pthreadpool/VFS changes yet and
>>> I'm terrified of having to explain them to OEMs :-).
>>>
>>> Is there any change you and Ralph can do a highlevel
>>> design/overview document/description to help those
>>> of us who will have to work with this code ?
>>>
>>> Maybe at SNIA (not officially on the conference
>>> agenda, but informally in the plugfest conf room) ?
>>
>> as a VFS implementer it's bloody simple and all the nastyness is (mostly)
>> hidden behind a cleve APIs.
> 
> That's what I wanted to hear :-).
> 
>> You can take a sneak preview at my upcoming VFS change on how to use it:
>>
>> Branch: <https://git.samba.org/?p=slow/samba.git;a=shortlog;h=8501cb1f4d1f8c5ac4129cceea679e580b6fd864>
>>
>> A good example how to use it to implement an async getxattr:
>>
>> <https://git.samba.org/?p=slow/samba.git;a=commitdiff;h=a736471c334c9fe7db37e37c2a601ce9ab51c9e9>
> 
> One quick comment on this - if you're adding
> SMB_VFS_GETXATTRAT_SEND/SMB_VFS_GETXATTRAT_RECV
> can you also work towards removing SMB_VFS_GETXATTR at the
> same time, and show how to implement the new functions
> in terms of the old sync version so we don't
> end up proliferating multiple ways to do things.
> 
> Look at what I did to remove SMB_VFS_FSYNC for
> details.

I think in the long run it will be important to also have sync versions,
which are allowed to return EAGAIN.

Basically the top level async

smb_vfs_call_something_send() function will check for

handle->fns->something_sync_fn and/or handle->fns->something_send_fn.

If something_sync_fn is found it will be called first in order to avoid
the talloc overhead of the additional _send/recv path.
If it returns EAGAIN, we'll fallback to the full async _send/_recv path.

Remember in future we'll have to deal with persistent memory, which
means we need to avoid as much overhead (for
malloc/talloc/pthread_create) as possible.

Maybe the SMB_VFS layer can figure out the device behind the filesystem
and depending on the expected latency return EAGAIN for the sync
function or not.

metze


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20180725/ae05f53c/signature.sig>