Under heavy load or slow networks the backend is not able to respond before the client times out. I see in the client log Timeout was reached and in the server log a 499 indicating it was still processing the request when the client closed the connection. Ultimately this results in a read error.
Is there a way to configure the drive’s timeout so this can be tailored to the deployment environment?
After testing SeaDrive a few months on Mac and Linux I’m finding it very unreliable due to this issue.
When the drive is placed under load such as an rsync copy of large and numerous files, the drive client times out due to network and server latency.
In some cases it just takes a while for the server to respond with the data, and it’s trying but the drive client times out the operation. In other cases it seems the drive accepts the local requests, queues them, but as the first ones are still transferring data over the network the later queued reads fail with timeout just because data hasn’t been fully received and completed from the first (because data takes a while to transfer over networks). This results in various failures depending on the client app that issued the read.
This appears to be completely preventable if SeaDrive would follow normal I/O rules and block completion while the operation is pending instead of introducing a timeout that the app never asked for.
Could we please at least have a way to control the timeout from the client?
Have you found any answers to that question?
No. SeaDrive developers did not respond to the issue or provide a way to control the client enforced timeouts on pending I/O which made it an unreliable solution for my storage.
That’s really bad - I encountered this issue a few times, too.
I’m really thinking out loud here but have you tried increasing the cache on the client yet? I’m wondering if that might help the client “queue” the files for transfer.
As to the server side, can you say something about your platform?
Which OS is the client running, by the way?
-Thanks
Can you say something about the situation under which you see the problem? Is it similar to what @aarononeal is seeing?
Yes, it is similar. I have now set the cache to 800 GB and I’m looking into it.
Wow! That’s H U G E ! I was thinking that 80 GB would be big.
By the way, which client OS are you using?
I did try increasing the cache at the time but I recall that only partially mitigated the issue on writes and in my case still needed to overflow the cache. The issue was also present on reads when there are cache misses and especially with concurrent operations.
The issue was not OS specific. I tried Windows, Mac, Linux clients and ran SeaFile in a Linux container at the time.
When I troubleshooted the issue I determined it was due to an artificially enforced timeout in the client app on pending I/O. The only real solution would be to not break the I/O contract with the client OS. I don’t have any more details than this as I had to move on 4 years ago. Best of luck.
Yeah, maybe exaggerated a little bit 
I use Windows 11 Pro and SeaDrive 3.0.11