I’m not sure why you’d want to do it, but if you’d want to do it: installing FoundationDB 5.2.5 on Windows Subsystem for Linux with an Ubuntu userland does not work (Win10 1803)
I guess fdb must calling into some syscalls that are not emulated by the windows kernel, crashes, gets restarted, rince, repeat…
Running fdbserver would have been cool, but at least I can install it on the Windows host itself, but it would have been cool to be able to use the client and fdbcli from a linux host, to test linux-native apps (in my case, running .NET Core on Linux on my Windows laptop, without paying the cost of a VM)
I’m not an expert on WSL, but could this be related to the fact that FoundationDB uses O_DIRECT for I/O? That same problem has caused issues for those trying to run FDB within a Docker for Mac container with a mounted volume as the data directory: https://github.com/apple/foundationdb/issues/842
I’m basically suggesting this because of the fact that it’s failing with an I/O error on startup, and (absent, say, a bad disk), the above issue is I think where I’ve seen that before.
It’s possible. The way I understand it, WSL works by translating linux syscalls into their equivalent Windows kernel calls, but not everything is either implemented, or possible. O_DIRECT I/O may be one of the unsupported calls.
If you implement a workaround for platforms that do not support O_DIRECT, it’s possible that WSL may be fixed as well.
Now to be fair, I don’t expect the server to be fully working, but the client part would be nice. And my suspicion is that it’s only the code that deals with the fdb.cluster file that fails (log files are written to disk without issues).
Are there other linux platforms that don’t support AIO? If WSL is recognized as a Linux platform by the client, then that would mean that “if (platform == LINUX) …” is not a sufficient test, and would require either a runtime check for AIO support (with fallback to something else), or a custom package built for WSL? That’s starting to look like a lot of work…
I haven’t really looked into it, so I’m not sure. I don’t think I’ve heard anyone else mention that they had trouble with AIO on a Linux platform before, though.
I found this topic being pointed to elsewhere, so to circle back:
As of FDB 6.1 (and thanks to #1283), one can pass --knob_disable_posix_kernel_aio=1 on the command line to fdbserver, which will cause it to not try to use KAIO on linux, and instead fall back to using a threadpool which issues synchronous IO calls. This should allow FDB to work on the Windows Subsystem for Linux, and feel free to report back/open an issue if it doesn’t.
I tried it with v6.2 still on WSL v1, and I’m still getting an issue with both fdbserver and fdbcli.
Adding knob_disable_posix_kernel_aio=1 to foundationdb.conf or passing it as an argument does not change anything, server crashes immediately on start:
krzys@WSL:~# fdbserver --cluster_file /etc/foundationdb/fdb.cluster --datadir /var/lib/foundationdb/data/4500 --listen_address public --logdir /var/log/foundationdb --public_address auto:4500 --knob_disable_posix_kernel_aio=1
Error: Disk i/o operation failed
Anyway, this is for WSL v1, which will be soon replaced by WSL v2 that will run a real linux kernel (under an hypervisor) so this issue may go away by itself, though it may be usefull to find why here the knob seems to be ignored in some places?
By default it binds 127.0.0.1 which is only accessible from inside the WSL guest, not from the windows host. To fix that, I had to edit the /etc/foundationdb/fdb.cluster and change the IP to the guest’s IP. By default the guest and hosts communicates via an Hyper-V Virtual Ethernet Adapter (it was using 172.x.x.x/20 something in my case).
With that done, and by copying the fdb.cluster file over to the windows host, I was able to connect to it:
C:\DATA>fdbcli -C wsl.cluster --exec "status"
Using cluster file `wsl.cluster'.
Configuration:
Redundancy mode - single
Storage engine - memory-2
Coordinators - 1
Cluster:
FoundationDB processes - 1
Zones - 1
Machines - 1
Memory availability - 24.9 GB per process on machine with least available
Fault Tolerance - 0 machines
Server time - 06/03/20 00:05:12
Data:
Replication health - Healthy
Moving data - 0.000 GB
Sum of key-value sizes - 0 MB
Disk space used - 105 MB
Operating space:
Storage server - 1.0 GB free on most full server
Log server - 240.3 GB free on most full server
Workload:
Read rate - 21 Hz
Write rate - 1 Hz
Transactions started - 8 Hz
Transactions committed - 1 Hz
Conflict rate - 0 Hz
Backup and DR:
Running backups - 0
Running DRs - 0
Client time: 06/03/20 00:05:12
Running ps aux in the guest yields the smallest process list I’ve ever seen
Since WSL2 is using a virtualized linux kernel, it should work much better than before. Though with the fact that the file system is virtualized as well, the performance will probably be less than running the Windows version on the the Windows host? (needs to be tested!)
