--server mode does not work on Windows

[ipvirg]

Need guidance on deploying fio v3.22 client/server scenario for windows 2019 server environment. fio -v fio-3.22

fio does appear timing out when probing the SMB share -

fio --client=192.168.1.3 --runtime=30 .\fioconfig_64k_seq.fio
fio: client 192.168.1.3, timeout on cmd PROBE
fio: client 192.168.1.3 timed out

at host 192.168.1.3, "fio --server" has been initiated prior triggering fio workload

Start-Job -ScriptBlock {fio --server}

Id     Name            PSJobTypeName   State         HasMoreData     Location             Command
--     ----            -------------   -----         -----------     --------             -------
17     Job17           BackgroundJob   Running       True            localhost            fio --server

The cmd probe timeout on the smb share is related to the following openssh issue - https://github.com/PowerShell/Win32-OpenSSH/issues/139 - Cannot access network drive from ssh session

Appreciate if anyone has a workaround in implementing fio client/server in windows 2019/SMB share environment.

[sitsofe]

@ipvirg Does everything work when you run a client and a server on the same machine and you use localhost/127.0.0.1?

[sitsofe]

(additionally can you include the contents of fioconfig_64k_seq.fio here?)

[ipvirg]

Same timeout issue with local client 127.0.0.1

PS C:\Users\fiouser.FIODOMAIN> fio --client=127.0.0.1 --runtime=30 .\fioconfig_64k_seq.fio
fio: client 127.0.0.1, timeout on cmd PROBE
fio: client 127.0.0.1 timed out
PS C:\Users\fiouser.FIODOMAIN\> more .\fioconfig_64k_seq.fio
[global]
name=fio-directory

directory=C\:\Datafiles
nrfiles=1

rw=readwrite
bs=64k

direct=1

time_based=1
iodepth=1

numjobs=1
group_reporting

size=1GB

ramp_time=20
randseed=50

[vm_prime]

Verified fio is running client/server:

Get-process | findstr fio
   2160      12   136452       5844       0.02   5984   2 fio
netstat -an |findstr 8765
  TCP    0.0.0.0:8765           0.0.0.0:0              LISTENING

[sitsofe]

My faint memory is that fio's server mode needed fork() (which Windows doesn't do) and I'm not aware that has changed... Ah here we go: https://www.spinics.net/lists/fio/msg02565.html .

Implementing a thread server mode would be new feature work (would be fun to see though!).

[sitsofe]

https://www.spinics.net/lists/fio/msg05248.html mentions the same timeout on cmd PROBE messages and in https://www.spinics.net/lists/fio/msg05262.html Jens replies:

Windows doesn't support fork(), and the fio server implementation was written to use processes. It could be made threaded instead and switched to that, in which case it would work. But it would require a fair amount of work...

Which confirms the above. As no one has worked on this thus far it would have to come via an outside contribution (which we would review) - patches welcome!

[blah325]

I have done some preliminary work in https://github.com/blah325/fio/commit/e650af9251a73dc08890ce84c277f372ed41fe6c to get fio server working with the Windows OS. Could someone take a first pass look at this to see if it could be pulled into mainline?

There were two fork calls that were worked around to get this working:

The first fork() was in accept_loop() where it creates a new process to work on handle_connection(). This change set uses Window's CreateProcess() in place of fork(). In order to support this, it duplicates the socket connection via WSADuplicateSocket() and passes the resulting WSAPROTOCOL_INFO to the process via a named pipe. The pipe name is then passed to the process via a new command line argument(--server-internal).

The second fork() was in handle_run_cmd() where it creates a new process to work on fio_backend_thread(). This change set runs fio_backend_thread() as a thread via pthread_create() instead of a forked process.

There is also some supporting work in the monitoring of spawned processes/threads in fio_server_check_conns() and fio_server_check_jobs().

The last change was to avoid calls to recv() without a prior call to poll() indicating that something is pending. This avoids a long delay for the OS to detect that the remote had closed the socket. This was necessary for a couple cleanup paths which call recv() without first calling poll via handle_xmit() and fio_drain_client_text().

[adrabkin]

This has been open for quite some time... any update on this feature?

[axboe]

I've already explained what needs to be done to support this. If someone wants to do the work, then I'd be happy to review it. But I personally don't have any plans to work on this.