WSL 2 support

[hammerit]

I tried to access my drivepool drive via WSL 2 and got this. Any solution? I'm using 2.3.0.1124 BETA.

 

➜  fludi cd /mnt/g
➜  g ls
ls: reading directory '.': Input/output error

Related thread: https://community.covecube.com/index.php?/topic/5207-wsl2-support-for-drive-mounting/#comment-31212

Edited May 15, 2020 by hammerit

[Reid Rankin]

I've been following up on this with some disassembly and debugging to try and figure out what precisely is going wrong. WSL2's "drvfs" is just a 9P2000.L file server implementation (yep, that's the protocol from Plan 9) exposed over a Hyper-V Socket. (On the Windows side, this is known as a VirtIO socket; on the Linux side, however, that means something different and they're called AF_VSOCK.) The 9P server itself is hard to find because it's not in WSL-specific code -- it's baked into the Hyper-V "VSMB" infrastructure for running Linux containers, which predates WSL entirely. The actual server code is in vp9fs.dll, which is loaded by both the WSL2 VM's vmwp.exe instance and a copy of dllhost.exe which it starts with the token of the user who started the WSL2 distro. Because the actual file system operations occur in the dllhost.exe instance they can use the proper security token instead of doing everything as SYSTEM.

The relevant ETW GUID is e13c8d52-b153-571f-78c5-1d4098af2a1e. This took way too long to find out, but allows you to build debugging logs of what the 9P server is doing by using the tracelog utility.

tracelog -start p9trace -guid "#e13c8d52-b153-571f-78c5-1d4098af2a1e" -f R:\p9trace.etl
<do the stuff>
tracelog -stop p9trace

The directory listing failure is reported with a "Reply_Rlerror" message with an error code of 5. Unfortunately, the server has conveniently translated the Windows-side NTSTATUS error code into a Linux-style error.h code, turning anything it doesn't recognize into a catch-all "I/O error" in the process. Luckily, debugging reveals that the underlying error in this case is an NTSTATUS of 0xC00000E5 (STATUS_INTERNAL_ERROR) returned by a call to ZwQueryDirectoryFile.

This ZwQueryDirectoryFile call requests the new-to-Win10 FileInformationClass of FileIdExtdDirectoryInformation (60), which is supposed to return a structure with an extra ReparsePointTag field -- which will be zero in almost all cases because most things aren't reparse points. Changing the FileInformationClass parameter to the older FileIdFullDirectoryInformation (38) prevents the error, though it results in several letters being chopped off of the front of each filename because the 9P server expects the larger struct and has the wrong offsets baked in.

So things would probably work much better if CoveFs supported that newfangled FileIdExtdDirectoryInformation option and the associated FILE_ID_EXTD_DIR_INFO struct; it looks like that should be fairly simple. That's not to say that other WSL2-specific issues aren't also present, but being able to list directories would give us a fighting chance to work around other issues on the Linux side of things.

[Reid Rankin]

After WAY TOO MUCH DEBUGGING I've discovered that there's a built-in mechanism in vp9fs.dll to downgrade the FileInformationClass it requests. It tries the following in order:

• FileIdExtdDirectoryInformation (60)
• FileIdFullDirectoryInformation (38)
• FileIdBothDirectoryInformation (37)
• FileFullDirectoryInformation (2)
• FileDirectoryInformation (1)

The trick is that it only searches through this list if it gets one of the following NTSTATUS error codes:

• STATUS_INVALID_INFO_CLASS (0xC0000003)
• STATUS_INVALID_PARAMETER (0xC000000D)
• STATUS_NOT_SUPPORTED (0xC00000BB)

Note that this does not include the STATUS_INTERNAL_ERROR (0xC00000E5) code which is returned by CoveFs in response to the unsupported request made with FileIdExtdDirectoryInformation. I've also realized that Dokan filesystems have the same problem; in their case they return STATUS_NOT_IMPLEMENTED (0xC0000002), which while close does not earn it a cigar. (It does, however, result in a more intelligible "Function not implemented" error on the Linux side instead of a generic "Input/output error".)

The other good news is that I hacked up a patch in Cheat Engine (yeah, it's been a long day) that forces vp9fs.dll to pretend the error code is always 0xC0000003 and it makes all of the above work fine. I was worried that there would be more incompatibilities even once the directory listings got working because I saw some other error codes popping up -- but they're caused by the Windows ACLs in my specific environment and are working exactly like they should.

So I suggest DrivePool change its error code returned in these cases to one of these 3 more-specific, magical codes -- personally, I like the STATUS_INVALID_INFO_CLASS. Tomorrow I'll work up a PR for the Dokan people, and I'll also file an issue with the WSL issue tracking repo to try to get them to include a few more error codes in their magical "stuff that works" list.

[Reid Rankin]

For future reference, here's the Dokan issue and PR. Several similar issues were already filed with the WSL repo, so I've added comments to link back to the Dokan issue and hopefully help people get things sorted. I've also cooked up a Cheat Engine script that will patch vp9fs.dll at runtime to properly handle both Dokan's STATUS_NOT_IMPLEMENTED and DrivePool's STATUS_INTERNAL_ERROR, if you need a fix right now and don't mind using what's essentially a video game trainer to make it happen.

Don't use this unless you understand what it does.

fixDrivePoolWSL.CT

[RG9400]

I can confirm, seems my DrivePool is accessible from WSL 2 now, and I can mount and use it from Docker containers like any other DrvFs mount (automounted Windows volumes).

[Froghut]

Any news on this? I would really need WSL2 support.

[timmy05]

I, too, would like to know the future of support for WSL2 as I'd like to move my Docker containers over to WSL2 and I cannot until it's possible to read my DrivePool via WSL2.

[Christopher (Drashna)]

Unfortunately, we don't have any plans on adding support for WSL2 at this time. 

[c_312]

I have just purchased DrivePool yesterday and am very satisfied so far. But this is a feature that I also would really need if I want to continue using DrivePool.

[SPACEBAR]

Here's how I was able to make it work by mounting cifs drives 

 

[Reid Rankin]

Just want to add my two cents as a loyal DrivePool user -- WSL2 support is important to me. I'd like to do my dev work in DrivePool so it's duplicated.

[Wirly]

Just bought 2x14tb thinking I'd get rid of my bulky NAS and use my main pc with DrivePool + Docker containers. However, without WSL2/docker support it can't happen. This needs to be mentioned in the FAQ or product page to warn anyone that intends to use it with WSL2.

[RG9400]

+1 from my side. I've been using WSL2 extensively, and it's been hard to work around DrivePool's lack of support. Windows is heading in a direction where it works in harmony with Linux, so it would be nice for the software to be able to support that.

I am able to cd to various directories on the mount that Windows does natively, but I can't actually list out any files, and no software running within WSL2 can see them either.

[RG9400]

In the meantime, if anyone wants to get this working with Docker for Win using WSL2 as a backend, you actually don't have to do too much complex stuff. If you use compose, you can create a named volume like below, and then mount this into other containers. Performance is what you would expect from a CIFS mount...not sure if DrvFs is better or not, but it works at least

volumes:
  drivepool:
    driver_opts:
      type: cifs
      o: username=${DRIVEPOOLUSER},password=${DRIVEPOOLPASS},iocharset=utf8,rw,uid=${PUID},gid=${PGID},nounix,file_mode=0777,dir_mode=0777
      device: \\${HOSTIP}\${DRIVEPOOLSHARE}

 

[Reid Rankin]

Here's the DrivePool tracking issue; it appears has been resolved in version 2.3.0.1193.

[RG9400]

The DrivePool disk works in  Docker containers using a WSL2 backend, but the performance is abysmal, especially compared to the CIFS mount I was using before. I've gone back to CIFS for now.

A Plex library scan took almost 2 hours using the DrivePool automount. As a CIFS volume, the same folder was scanned in 5 minutes. 

[Nights0ng]

Came across this thread due to having an issue moving to wsl2 with Docker. I take it the 2.3.0.1193 is some kind of alpha/beta build? Don't see it coming through as an update. Would really like to be able to move to wsl2, but this is kind of holding me up currently. Just curious how stable it is, guessing it is recommended to wait for an official release, but how far off is that generally?

[Reid Rankin]

@Nights0ng The fixes referenced here look like they've made it into the 2.2.5.1237 RC version that's available from the official download page. (The betas are available here.)

WSL2 support works pretty OK with these fixes; you can list directories and execute files just like you'd expect. Performance isn't stellar, but not that bad either. My primary workflow is VS Code with a Remote-WSL connection, and my primary dev directory is on a DrivePool drive, and it works fine. Stuff involving access to lots and lots of tiny files, like some git checkouts and npm installs, can be somewhat slower than they would be on a native drive, but IMHO it's a price worth paying for the redundancy.

(IDK whose fault the performance issues are; could be DrivePool's fault, but it could just as easily be inherent to Windows' 9P2000 server implementation. And I'm using SMR drives, which suck in their own special way. But it's good enough as-is, and I'm happy.)

[Nights0ng]

@Reid Rankin Thanks for the ping, looks like it just showed up as a new version recently to install. Will be trying it out. I use it to run things on my media server (reverse proxy and some web applications). Will have to give things a try and see how it goes now I suppose.

[Christopher (Drashna)]

Just a heads up, for any beta builds, if you're getting the internal builds, check the change log file. Get only NUMBERED builds in the log, as these are stable, whereas builds not numbered in the log may not work, at all. 

[klepp0906]

so...is WSL support in now?  i cant quite tell via the banter here but i know i was just checking out the most recent beta patch notes and it says no support up top...

does no support mean no support or does it mean does not work?  or is that old info that hasnt been whittled from the changelog template? :P

[Christopher (Drashna)]

Sorry, no, WSL is still not supported.

 

[klepp0906]

worst developers ever!

joking aside, what does that mean exactly?  i assume when using WSL it will only present an issue if you try to access a virtual disk/pool?  anything else will be business as usual?

i still havent re-installed WSL after moving to 11 but its on my shortlist.  trying to know what im getting into because moving away from drivepool certainly wont be an option. 

if i just have to move some bash scripts off my pool to a standalone disk or something, I can live with that. 

[Christopher (Drashna)]

It means that you may have issues accessing data on the pool through WSL. 

 

Namely, WSLuses a layer between WSL file system and windows for the file system that can cause issues for DrivePool (eg, potentially unsupported commands, etc). And adding support for it is not simple. 

[klepp0906]

1 minute ago, Christopher (Drashna) said:

eans that you may have issues accessing data on the pool through WSL. 

 

Namely, WSLuses a layer between WSL file system and windows for the file system th

well, that will only half present an issue I guess.  worst case id have to do some shuffling to and fro.  moving bash scripts off the pool is easy, unfortunately most data i use bash scripts against is also on the pool.  

i suppose we'll see what comes first, an unrelenting need to use those scripts or the means and implementation from the stablebit side.  time will tell

[Froghut]

I'm using a Drivepool with a bunch of Docker containers using WSL, performance is not the best but in general it works fine.