### Author:  [@KrzysFR](https://forums.foundationdb.org/u/KrzysFR)
#### Post date: [October 27, 2018, 6:14pm UTC](https://forums.foundationdb.org/t/foundationdb-does-not-run-on-windows-subsystem-for-linux-wsl/809/1 "2018-10-27T18:14:34Z")
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)
_For those wondering what the hell I’m talking about: yes, this is a real thing [https://docs.microsoft.com/en-us/windows/wsl/faq](https://docs.microsoft.com/en-us/windows/wsl/faq)_
Installing the server package fails
```nohighlight
~/fdb$ sudo dpkg -i foundationdb-server_5.2.5-1_amd64.deb
Selecting previously unselected package foundationdb-server.
Preparing to unpack foundationdb-server_5.2.5-1_amd64.deb ...
Unpacking foundationdb-server (5.2.5-1) ...
Setting up foundationdb-clients (5.2.5-1) ...
Adding group `foundationdb' (GID 115) ...
Done.
Adding system user `foundationdb' (UID 111) ...
Adding new user `foundationdb' (UID 111) with group `foundationdb' ...
Not creating home directory `/var/lib/foundationdb'.
...
Setting up foundationdb-server (5.2.5-1) ...
ERROR: Disk i/o operation failed (1510)
dpkg: error processing package foundationdb-server (--configure):
installed foundationdb-server package post-installation script subprocess returned error exit status 1
dmesg: read kernel buffer failed: Function not implemented
Processing triggers for ureadahead (0.100.0-20) ...
Processing triggers for systemd (237-3ubuntu10.3) ...
Errors were encountered while processing:
foundationdb-server
E: Sub-process /usr/bin/dpkg returned an error code (1)
```
Installing the client package does not fail, but running fdbcli fails immediately:
```auto
~/fdb$ fdbcli
ERROR: Disk i/o operation failed (1510)
```
[https://media.giphy.com/media/LycfkVG4L6x0Y/giphy.gif(image larger than 4096KB)](https://media.giphy.com/media/LycfkVG4L6x0Y/giphy.gif)
The log files all look identical to this (this is the whole file! nothing more)
```xml
```
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)
---
### Author:  [@alloc](https://forums.foundationdb.org/u/alloc)
#### Post date: [October 27, 2018, 6:54pm UTC](https://forums.foundationdb.org/t/foundationdb-does-not-run-on-windows-subsystem-for-linux-wsl/809/2 "2018-10-27T18:54:32Z")
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](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.
---
### Author:  [@KrzysFR](https://forums.foundationdb.org/u/KrzysFR)
#### Post date: [October 27, 2018, 7:06pm UTC](https://forums.foundationdb.org/t/foundationdb-does-not-run-on-windows-subsystem-for-linux-wsl/809/3 "2018-10-27T19:06:02Z")
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).
---
### Author:  [@ajbeamon](https://forums.foundationdb.org/u/ajbeamon)
#### Post date: [October 27, 2018, 9:57pm UTC](https://forums.foundationdb.org/t/foundationdb-does-not-run-on-windows-subsystem-for-linux-wsl/809/4 "2018-10-27T21:57:50Z")
IOSetupError is caused by a failure to setup linux kernel aio. I take it that’s not supported in WSL?
Maybe using AsyncFileEIO instead of AsyncFileKAIO in this case would work? I think this would require a code change to test.
---
### Author:  [@KrzysFR](https://forums.foundationdb.org/u/KrzysFR)
#### Post date: [October 28, 2018, 5:29pm UTC](https://forums.foundationdb.org/t/foundationdb-does-not-run-on-windows-subsystem-for-linux-wsl/809/5 "2018-10-28T17:29:30Z")
It looks like AIO is not supported by WSL, according to this issue (that impacts mysql as well): [https://github.com/Microsoft/WSL/issues/3631](https://github.com/Microsoft/WSL/issues/3631) or [https://github.com/Microsoft/WSL/issues/2113](https://github.com/Microsoft/WSL/issues/2113)
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…
---
### Author:  [@ajbeamon](https://forums.foundationdb.org/u/ajbeamon)
#### Post date: [October 29, 2018, 3:33pm UTC](https://forums.foundationdb.org/t/foundationdb-does-not-run-on-windows-subsystem-for-linux-wsl/809/6 "2018-10-29T15:33:21Z")
> [@KrzysFR](#):
>
> Are there other linux platforms that don’t support AIO?
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.
> [@KrzysFR](#):
>
> 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…
Another option is to have it be a runtime toggleable piece of behavior, perhaps using knobs. I haven’t attempted to do this, but this may be the only place where you need to modify the behavior: [https://github.com/apple/foundationdb/blob/51afb29e3b23e41e55c1aec1a2865b29baf6073b/fdbrpc/Net2FileSystem.cpp#L61](https://github.com/apple/foundationdb/blob/51afb29e3b23e41e55c1aec1a2865b29baf6073b/fdbrpc/Net2FileSystem.cpp#L61).
As a side note, maybe avoiding AIO in this way is a better option for those who can’t use O\_DIRECT than reverting to synchronous behavior (see [Offer a knob to disable the use of O\_DIRECT by alexmiller-apple · Pull Request #859 · apple/foundationdb · GitHub](https://github.com/apple/foundationdb/pull/859)).
---
### Author:  [@alexmiller](https://forums.foundationdb.org/u/alexmiller)
#### Post date: [November 22, 2019, 1:31am UTC](https://forums.foundationdb.org/t/foundationdb-does-not-run-on-windows-subsystem-for-linux-wsl/809/7 "2019-11-22T01:31:17Z")
I found this topic being pointed to elsewhere, so to circle back:
As of FDB 6.1 (and thanks to [#1283](https://github.com/apple/foundationdb/pull/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.
---
### Author:  [@KrzysFR](https://forums.foundationdb.org/u/KrzysFR)
#### Post date: [November 22, 2019, 7:30am UTC](https://forums.foundationdb.org/t/foundationdb-does-not-run-on-windows-subsystem-for-linux-wsl/809/8 "2019-11-22T07:30:26Z")
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:
```auto
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
```
Logs:
```xml
```
fdbcli also crashes on start (while reading fdb.cluster ?)
```auto
krzys@WSL:~# fdbcli --version
FoundationDB CLI 6.2 (v6.2.7)
source version d3c4bd9c5ac29ef98c024317353e3c1a24a9d6b3
protocol fdb00b062010001
krzys@WSL:~# fdbcli
ERROR: Disk i/o operation failed (1510)
krzys@WSL:~#
```
Am I missing something?
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?
---
### Author:  [@alexmiller](https://forums.foundationdb.org/u/alexmiller)
#### Post date: [November 22, 2019, 7:44pm UTC](https://forums.foundationdb.org/t/foundationdb-does-not-run-on-windows-subsystem-for-linux-wsl/809/9 "2019-11-22T19:44:18Z")
_sigh_.
A check for the knob is missing on [the init call](https://github.com/apple/foundationdb/blob/ef14f7a718663595f6bd2a7c73e686eeb8fc7b2f/fdbrpc/Net2FileSystem.cpp#L96). Thanks for testing, and let me go file [an issue](https://github.com/apple/foundationdb/issues/2382)…
---
### Author:  [@KrzysFR](https://forums.foundationdb.org/u/KrzysFR)
#### Post date: [June 2, 2020, 10:08pm UTC](https://forums.foundationdb.org/t/foundationdb-does-not-run-on-windows-subsystem-for-linux-wsl/809/10 "2020-06-02T22:08:46Z")
After upgrading to Windows 10 2004 and WSL 2, I can say that FoundationDB does install on WSL2 and seems to be running fine:
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:
```nohighlight
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 🙂
```nohighlight
krzys@SATSUKI:~$ ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 892 548 ? Sl Jun02 0:00 /init
root 31236 0.0 0.0 892 80 ? Ss Jun02 0:00 /init
root 31237 0.0 0.0 892 80 ? R Jun02 0:00 /init
krzys 31238 0.0 0.0 8852 5820 pts/0 Ss Jun02 0:00 -bash
root 32058 0.0 0.0 5236 2392 ? Ss 00:00 0:00 /usr/lib/foundationdb/fdbmonitor --conffile /etc/foundationdb/foundationdb.conf --lockfile /var/run/fdbmonitor.pid
foundat+ 32059 0.1 0.0 167700 14132 ? Sl 00:00 0:00 /usr/lib/foundationdb/backup_agent/backup_agent --cluster_file /etc/foundationdb/fdb.cluster --logdir /var/log/foun
foundat+ 32060 0.5 0.1 478500 38780 ? Sl 00:00 0:01 /usr/sbin/fdbserver --cluster_file /etc/foundationdb/fdb.cluster --datadir /var/lib/foundationdb/data/4500 --listen
krzys 32081 0.0 0.0 9104 3540 pts/0 R+ 00:05 0:00 ps aux
```
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!)