sahlberg
Client not sending data while multiple writes in parallel
I am working with the PurwFlashblade SMB server (which is relying on the Samba server internally). The server allows writing 4MB of data on the connection as part of 1 PDU (max connection write size is 4MB). I am using libsmb2 as the client. Let's assume that I have to write a 5GB file and I keep 32 outstanding writes to a single file. However, after some time the connection becomes unusable. There is no data on the Wireshark and no activity on the connection (the number of credits is also not exhausted).
Have you seen such a case before? I am still debugging the issue, so will post more updates, but any pointers are helpful.
Since you specifically stated that the number of credits isn't exhausted I'm not quite sure, but you may be running into the same problem as I did in #199 (specifically from the 3rd paragraph onward). In fact I'd assume you run into this issue given your usage.
I'm writing this from memory from back then so take this with a grain of salt: libsmb2 always tries to maintain 1024 or a number close to that of credits available. IIRC 64KB of data requires 1 credit. Sending 4MB takes 4MB/64KB=64 credits, and that means that with 1024/64=16 simultaneous requests you're out.
If halving the payload you send at once to 2MB or halving the number of outstanding requests (or lowering it even a bit more just to be save) solves the issue, this may be the culprit.
I will get back with more details. A colleague of mine had added logs and done packet capture to prove the above hypothesis. Also, for our use case, 1024 is too low, so we use 4096. In fact, I think we should increase it. Samba client uses 8192 as default and they have a synchronous client.
