[PATCH] SMB2_FIND improvement for clustered environments

[Amitay Isaacs]

Hi,

On Thu, Mar 23, 2017 at 8:54 PM, Ralph Böhme via samba-technical <
samba-technical at lists.samba.org> wrote:

> Hi!
>
> Attached is a patchset that improves SMB2_FIND performance in a ctdb
> cluster by
> making records fetching from locking.tdb asynchronous.
>
> This has three parts:
>
> - add a seperate IPC channel to ctdb for asynchrous processing
>
> - new async dbwrap API: dbwrap_parse_record_send|recv()
>
> - making use of it in smbd_smb2_query_directory_send()
>
> Some numbers follow.
>
> The time it takes to enumerate a directory with 50k files, current code:
>
> $ time bin/smbclient -U FAST\\slow%x -m smb3 //localhost/share -c "ls
> dir\50kfiles\*" > /dev/null | grep real
>
> 3 runs:
> real    0m10.693s
> real    0m10.608s
> real    0m10.710s
>
> Using the new async API this becomes:
>
> 4 runs:
> real    0m3.903s
> real    0m2.809s
> real    0m3.869s
> real    0m3.894s
>
> Some more implementation details shamelessly copied from the commit
> messages:
>
> ---8<---
> dbwrap: add dbwrap_parse_record_send/recv
>
> The req_state parameter tells the caller whether the async request is
> blocked in a full send queue:
>
> req_state >= DBWRAP_REQ_DISPATCHED := request is dispatched
> req_state < DBWRAP_REQ_DISPATCHED := send queue is full
>
> This is useful in a clustered Samba environment where the async dbwrap
> request is sent over a socket to the local ctdbd.
>
> If the send queue is full and the caller was issuing multiple async
> dbwrap requests in a loop, the caller knows it's probably time to stop
> sending requests for now and try again later.
>
> This will be used in subsequent commits in
> smbd_smb2_query_directory_send() when implementing async write time
> updates. Directories may contain umpteen files so we send many requests
> to ctdb without going through tevent and reading the responses which has
> the potential to deadlock.
> ---8<---
>
>
Looking at the code, it seems to duplicate a lot of functionality in the
CTDB client (new) code.  May be it's time to start using CTDB client code
to avoid duplication of effort and keep separate implementation of CTDB
protocol.  All of the CTDB client code has async API already.

May be something worth discussing at SambaXP?

Amitay.