Make Windows fonts also available, not just user distro

[WSLUser]

Windows build number:

220000.100

Your Distribution version:

Ubuntu 22.04

Your WSL versions:

Latest

Steps to reproduce:

In https://github.com/microsoft/wslg/pull/824, I noticed Windows fonts were removed. Was that intentional? Why not allow both? We should be able to choose between both Windows fonts and the Linux ones we install as they are not all the same. Please add support back to load Windows fonts in addition to loading user distro fonts.

WSL logs:

No response

WSL dumps:

No response

Expected behavior:

I expect all fonts available in the OS to be available in addition to what's installed in a user distro within WSL2.

Actual behavior:

WSL2 user distro fonts are now loadable at expense of Windows fonts.

[hideyukn88]

@WSLUser, yes, this is intentional change, the main reason is that accessing Windows volume from Linux has huge performance overhead, and this slowing down X11 application launch (as weston initialize pango/fontconfig at X11 app startup, and it scans all font path including Windows's value per local.conf). Thus, until the performance can be improved, it's removed, thanks!

[WSLUser]

You could try using something like NTFS3, which I did request be added to the WSL2 kernel as an option.

[NotTheDr01ds]

@WSLUser Just taking a guess here, but isn't that unlikely to work in WSL since the drive is already mounted by Windows itself?

[Masamune3210]

You are correct, it would, at best case, see the FS Dirty Flag and refuse to mount.

[WSLUser]

You could unmount it first. Other mounting options such as USB work so no reason ntfs3 couldn't work

[Masamune3210]

Unmounting the currently running Windows partition would not end well....

[Masamune3210]

Maybe a font cache could be generated on a scheduled basis, only being modified after the initial creation if a change is detected in the font store? If that was the case, then hypothetically WSL could consume the cache and show that to the Linux side as the installed fonts instead of having to scan for fonts each time something on the Linux side needs a font

[WSLUser]

Unmounting the currently running Windows partition would not end well....

I assume you mean from Windows side. It doesn't matter on the WSL side. There are many users of WSL who specifically disable the mounting of the windows filesystem. Clearly neither Windows nor WSL break as result. Only the interoperability between them.

[Masamune3210]

My point was the filesystem driver is unlikely to be the issue. The issue is in transferring the data efficiently, not in the parsing of the data once it's made it across the pipe. A new filesystem driver would be unlikely to change that much, and raw mounting, even if it was supported, wouldn't work since Windows has already obviously mounted the drive

[NotTheDr01ds]

There are many users of WSL who specifically disable the mounting of the windows filesystem. Clearly neither Windows nor WSL break as result. Only the interoperability between them.

The difference is that what is being mounted/unmounted in WSL is not the physical drive; it's a 9P network share of the physical drive from a Windows process (which, again, is why it's currently slow).

The NTFS physical drive can only be mounted by one system at a time, and the drive where the Windows fonts are stored is, naturally, already mounted by Windows itself. You can't unmount the physical drive from Windows because Windows naturally won't work. And you can't unmount the physical drive from WSL because it's not mounted (only the network share). This is why there's just no way that I can see for you to access the physical drive using the NTFS3 filesystem-drive in WSL.

[WSLUser]

Then you're not aware of DrvFS which is actually what it's going through and is the reason for the performance issue. 9P has nothing to do with it because it's not being used for this. Probably you never used WSL1 so you're not aware of the original filesystem driver that was used by WSL to access NTFS filesystem. That support didn't go away with WSL2. It's still there and the reason for so many complaints. It probably would work much faster if 9P was used instead but it's not.

[NotTheDr01ds]

@WSLUser It feels like we're going in circles here. First, a WSLg team member told you that the reason this wasn't being done was due to performance reasons (a.k.a. the 9P performance). You then suggested that the physical drive could be mounted directly. @Masamune3210 and I both explain that it isn't possible to mount a physical drive into WSL that's already mounted by Windows, and that's why it's mounted as 9P in WSL2. Now you seem to want to return to discussing the built-in filesystem performance.

For background, I'm well aware of WSL1 and have been using it since it was first GA'd. I still, to this day, keep several WSL1 distributions installed for performance reasons, since they are much faster at accessing the files on the Windows drives.

DrvFS which is actually what it's going through and is the reason for the performance issue.

9P has nothing to do with it because it's not being used for this.

You seem to have it backwards:

• WSL1 and WSL itself (the subsystem) use DrvFs to access Windows drives. It appears to me to most likely use some type of overlay technology, since WSL1 runs directly under the Windows kernel and can access the Windows filesystem directly.

  Performance of DrvFS under WSL1 is fairly fast, at least when compared with 9P on WSL2.

• WSL2 extends that access by mounting the drives into WSL2 distributions using the Plan 9 network protocol. This is necessary because WSL2 is running in the virtualized environment and can no longer access the Windows drives directly using DrvFS.

When you are accessing Windows files inside a WSL2 distribution, you are using 9P, which is where the main performance hit resides.

After writing this up, I ended up finding this comment in that issue from one of the WSL team members essentially saying the same thing 2+ years ago.

---

It's easy, though, to confirm this yourself by observing the mount output if you have both a WSL1 and WSL2 distribution installed:

WSL1:

$ mount | grep "/mnt/c"
C:\ on /mnt/c type drvfs (rw,noatime,uid=1000,gid=1000,umask=22,fmask=11,metadata,case=off)

The device is C:\ and the filesystem type is drvfs.

WSL2:

$ mount | grep "/mnt/c"
drvfs on /mnt/c type 9p (rw,noatime,dirsync,aname=drvfs;path=C:\;uid=1000;gid=1000;symlinkroot=/mnt/,mmap,access=client,msize=262144,trans=virtio)

The device is drvfs and the filesystem type is 9p.

---

Performance Comparison

I've run similar tests in the past, but since I believe there have been some recent performance improvements in the WSL2 9P implementation, I just reran the following on both a WSL1 and WSL2 Ubuntu distribution:

sudo apt install sysbench
cd /mnt/c/some/location
sysbench fileio --file-total-size=15G prepare
sysbench fileio --file-total-size=15G --file-test-mode=rndrw --time=300 --max-requests=0 --histogram run

	WSL1	WSL2
File operations
* Reads/sec	2,110.95	901.48
* Writes/sec	1,407.30	600.99
* fsyncs/sec	4,503.50	1,923.58
Throughput
* MiB/sec Read	32.98	14.09
* MiB/sec Written	21.99	9.39
Latency
* Min	0.00	0.07
* Avg	0.12	0.29
* Max	427.44	24.17
* 95th Percentile	0.42	0.68

I ran the WSL1 test first to give any caching advantage to WSL2.