mackid1993

That's what I thought, and probably a better option for new systems than using XFS.

I could be wrong, but I think it's possible to format array drives as ZFS instead of XFS but just as a single drive with its own filesystem the way Unraid does it. This could be a nice way to have the benefits of the Unraid array while also having some bitrot protection. Maybe someone can confirm this?

I just bought a second Pro license that I may never use, just to have so I can have a second server if I need it and also to say thank you to the team as I bought an initial Plus license in 2016 and only recently upgraded it to Pro last year. I've gotten a lot of use out of Unraid and this license has lasted me four builds so even if I never activate this second one at least I can support Limetech given that I won't be a new subscriber.

I've been a dedicated Unraid user since 2016 with a Pro license. It's been a while since I bought my license and my flash has survived four builds (still my OG) so it's been a while since I've dealt with licensing. Given the new licensing model I'd like to buy a second Pro key just to have in case I ever want to build a secondary server in the future. I'm wondering if I can buy a Pro key now and hold onto the license indefinitely until the need arises to bind it to a USB drive and use it at some indeterminate point in the future? If it needs to be redeemed in a certain amount of time then I won't do this. Any guidance would be appreciated. Thanks!! Edit: I got an answer from support.

I've been getting these errors for months and have no adverse effects from them minus the errors in the log. My VM is super stable and GPU passthrough works fine.

I'm not sure, my only suggestion would be to spin up a new VM and see if the same thing happens. Are you on the latest version of Unraid?

My Windows 11 VM runs off an nvme drive bound to vfio and passed through. I don't use a vdisk. Maybe it's just system performance. I also give my VM 20 threads and 32 GB of ram.

I'm not sure but I can confirm SMB was much faster. So it's not just you.

@johnsancThis is transferring a file that was on nvme cache on one share to nvme cache on a different share. I think something is wrong with your setup honestly. Update: I did the same test over SMB and got 3-5 GB/s. Something may be up performance wise. @johnsanc I added to your Github issue.

This was spinning disks to NVME. NVME to NVME would be much quicker. What version of WinFSP are you on?

Same results using Windows native file copy. Share -> VM Desktop (nvme drive) Share to Share

I don't have this issue. This is a transfer from my Unraid array to the nvme drive that my VM boots from. I get similar results with a share to share transfer as well. 100 + MB/s

I have the 8125 2.5 Gbe NIC and got the notification in Fix Common Problems. I have no issues with the stock driver and when I installed this driver the RDP connection to my Windows VM got super slow. Not sure if I did something wrong or if this driver isn't needed with my particular board.

I personally avoid Linux as a desktop OS. I'm more of a Windows guy. Most of my Unraid server besides the storage portion is done in the Windows VM. That's why VirtioFS was so important to me. I prefer to run as much as I can under Windows and leave a few hands off things like Plex and Roon to Docker. Since Unraid manages the storage I have no need for Windows Server, so I just run Windows 11 Pro. Hopefully the virtio-fs team could fix that issue for you.

Have you tried the rust version of Virtiofsd? Edit: See here

No problem, we should have official drivers very soon! If you're interested you can also use my scripts to mount your shares as individual drive letters rather than just one share mounted as Z:.

Thanks!!

@SimonF I was hoping this post I wrote could be highlighted higher up in the thread. I shared some scripts for mounting multiple Unraid shares as drive letters and made everything pretty much copy and paste. I also added instructions for setting it up with Task Scheduler.

I'm just using stock Unraid, no rust. I'm on 6.12.6 with the test driver and it's very stable.

After testing there is still a memory leak, just a different memory leak now. Edit: See discussion here: https://github.com/virtio-win/kvm-guest-drivers-windows/issues/1004 It appears that the test drivers may have indeed fixed the leak after all.

The new VirtoFS Windows driver can be downloaded here. To use it you have to enable driver test mode at an admin command prompt with bcdedit /set testsigning on I also went into certmgr and added viofs.cat to Trusted Root Certification Authorities and Trusted Publishers. If the watermark bothers you, this little tool makes it go away: https://winaero.com/download-universal-watermark-disabler/ It's useful until this fix is released with the newest Virtio drivers per the Virtio-win team. Once the new drivers are released uninstall the watermark removal tool and turn off testsigning: bcdedit /set testsigning off It seems that after further testing the Virto-win team fixed the leak: https://github.com/virtio-win/kvm-guest-drivers-windows/pull/1022 I made a copy of these drivers so if they disappear someone ping me and I can share a new link. @SimonF and @christophocles thank you for all of your help with this!

@christophocles @SimonF The virtio-win team were able to repro this!

Question, once I have a working BigSur VM, what happens if I upgrade to a newer version of macOS from within the VM? Will everything break?

Ah, what I don't like is they are testing with pre-release drivers. If it's fixed in unreleased drivers how would we know without compiling them?

Does anyone know what C:\Program Files (x86)\fio\fio\fio.exe. The guy who couldn't reproduce it ran that. Is that something new they haven't released yet?