jfs mounted on Windows way slower than jfs mounted on Linux exposed via smb

[happyc0ding]

What happened:
I have 1 client (Windows 10), 1 server (Linux).
(Background: Mounting an image via Arsenal Image Mounter)
Scenario 1:
Mounting jfs in Windows via network and opening a big file (~150GB): Takes about 60 seconds.
Scenario 2:
Mounting the same jfs on the Linux server directly and exposing the mount via smb, then mounting this share via the same network in Windows and opening the same file: Takes about 12 seconds.

Playing around with prefetch, cache-partial-only and setting cache-dir to memory did not change much (caching might have been an explanation, since the local disk is slower than the disk minio is running on).
I've tried several times in order to confirm the timing and ruling out any other caching mechanisms.

What you expected to happen:
I expected the performance in scenario 1 and 2 to be roughly the same or scenario 2 to be slower since it adds another protocol layer.

How to reproduce it (as minimally and precisely as possible):
Install jfs on Windows, install jfs, samba, minio and mariadb on linux. Create a jfs and mount it.
Mounted on linux as described in the docs: sudo juicefs mount -d --enable-xattr mysql://... /mnt/myjfs and used a default smb.conf provided by the package, only added a share as described in the docs.
Mounted jfs in windows with juicefs.exe mount "mysql://..." x:
Mounted smb in windows with net use x: \\foo\bar.

Anything else we need to know?
Not sure if this is a bug. However, I did not find anything in the docs explaining this. Is the windows driver that much slower than linux? If yes, it would be nice to know.

Environment:

• JuiceFS version (use juicefs --version) or Hadoop Java SDK version: juicefs version 1.1.4+2024-08-30.fc080fd on windows, juicefs version 1.2.1+2024-08-30.cd871d1 on linux
• OS (e.g cat /etc/os-release): Windows 10 / Debian 12
• Kernel (e.g. uname -a): Linux 6.1.0-26-amd64
• Object storage (cloud provider and region, or self maintained): self hosted minio version RELEASE.2024-10-02T17-50-41Z
• Metadata engine info (version, cloud provider managed or self maintained): mariadb from 11.5.2-MariaDB
• Network connectivity (JuiceFS to metadata engine, JuiceFS to object storage): 10G via Vmware
• Others: Using winfsp-2.0.23075

[happyc0ding]

I did some more tests:
Opening the file via WSL results in about the same speed as opening it via smb. There's actually a comment regarding performance in the WSL docs:

Using the bench benchmarking tool that comes with JuiceFS, the results show that mounting a file system to Windows (e.g. /mnt/c) has about 30% lower performance than mounting it inside a Linux subsystem (e.g. $HOME/mnt).

However, if this is also the case when mounting through the windows client directly remains unclear.