Jump to content
Covecube Inc.
  • 6
hammerit

WSL 2 support

Question

Posted (edited)

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 by hammerit

Share this post


Link to post
Share on other sites

15 answers to this question

Recommended Posts

  • 1

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.

Share this post


Link to post
Share on other sites
  • 1

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.

Share this post


Link to post
Share on other sites
  • 1

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

Share this post


Link to post
Share on other sites
  • 0

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.

Share this post


Link to post
Share on other sites
  • 0

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.

Share this post


Link to post
Share on other sites
  • 0

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.

Share this post


Link to post
Share on other sites
  • 0

+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.

Share this post


Link to post
Share on other sites
  • 0

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}

 

Share this post


Link to post
Share on other sites
  • 0

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).

Share this post


Link to post
Share on other sites
  • 0

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. 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...