server kernel support for tcp fast open unknown {“Process”: “storagenode”}
This is the code seen for TFO in Windows
func tryInitFastOpen(*zap.Logger) {
// should we log or check something along the lines of
// netsh int tcp set global fastopen=enabled
// netsh int tcp set global fastopenfallback=disabled
// ?
}
Is it because docker is running linux containers? Please correct me if I am wrong but won’t it mean there shouldn’t be any log entry for Windows SNOs.
My docker nodes (docker desktop for Windows with wsl2 engine) reports it differently:
2023-02-10T15:59:35.452Z INFO server kernel support for server-side tcp fast open remains disabled. {"Process": "storagenode"}
2023-02-10T15:59:35.452Z INFO server enable with: sysctl -w net.ipv4.tcp_fastopen=3 {"Process": "storagenode"}
I remember the newer docker versions allow WSL to be used so that makes sense but older dockers 2.x.x don’t have that feature. It would be interesting to see how this is handled.
I even executed the sysctl command on WSL and restarted the node but it kept showing the same log entry as above.
I suspected the same. Only Windows GUI nodes would report it. I have quoted the whole file for TFO in Windows so it wont show anything.
I don’t think it makes any difference. This is still a Linux VM. And I suspect that Linux docker nodes reports the same.
As for sysctl command, it should be executed on the VM I suppose. So, if you use wsl2 engine, then you can open a wsl2 session to the same VM and change this settings. But I believe it requires to re-create the container after that, and also this settings will not be persistent, unless configured system-wide (inside the VM), similarly to UDP settings for QUIC.
No, not in the docker container, in the docker VM. If you use a Hyper-V VM, you need get to the shell on this VM. If you use wsl2, you just open a new session and execute there with sudo.
For the container it could be a more trick part, see docker run | Docker Documentation