testdasi

Can you copy-paste the text on to the forum post instead of linking to google drive please? Use the forum code function (the </> button next to the smiley button).

You can run 6.9.0 beta and just wait for subsequent beta releases. Alternatively, a forum member compiled customer kernel for Unraid 6.8.3 (stable) with 5.5.8 (same kernel as Unraid 6.9.0 beta) so you can try it at your own risks. The first post on the topic also has instructions on how to compile your own (which is the best way to do it).

So after a lot of testings - all to a Crucial MX300 SSD (8GB test file at 1M blocksize) I noticed dd test the way recommended on github acts rather strange. It reduces write speed a lot (down to 50MB/s on mergerfs mount, 170MB/s direct) but actual write is done in burst at 500MB/s with long waits in between. I redid the test on an NMVe and observed similar behaviours. dsync appears to be the parameter causing this. I can improve dd with dsync performance to 100MB/s by adding cache.writeback (which requires cache.files NOT =off). cache.files=off is 50MB/s regardless of any other tuning Now testing over the network (SMB) from NVMe (passed through to a VM) to mergerfs mount cache.files=off: 150-170MB/s cache.files=off + threads=16: 190-250MB/s cache.files=partial: 60-90MB/s cache.files=partial + cache.writeback: around 125MB/s Note1 : Adding threads=16 doesn't improve performance with cache.files=partial regardless of writeback I did 64GB dd test without dsync (64GB so less RAM cache impact due to file size > free RAM) and all 4 sets of parameters yielded similar average speed (which matches average actual write speed). So I'm sticking to cache.files=off + threads=16 for my all-local mounts.

Have you updated to 6.8.3?

@trapexit: Can you think of any reasons that would cause write to mergerfs mounts to be very slow? Or maybe some tweaks to improve write speed? It seems the slow speed only affects write to mergerfs mount. Writing direct to source folder is more than 5 times faster. My mount command is below. I tried various combinations of options but none offers any improvement. mergerfs /mnt/disks/ssd860evo_2J/backup:/mnt/disks/ssd860evo_6T/backup /mnt/cache/backup/mergerfs -o rw,async_read=false,use_ino,allow_other,func.getattr=newest,category.action=all,category.create=mfs,cache.files=partial,dropcacheonclose=true,minfreespace=32G @DZMM: are you able to do a quick write test to see what you get?

Anyone noticed performance of mergerfs has gone down really badly? I noticed my mount suddenly stops saturating gigabit. So I did a dd test from the console which yielded 45MB/s on the mergerfs mount and 379MB/s writing directly to the same UD drive (that mergerfs was writing to). I don't remember the mount to ever be that slow.

Uneventful update from 6.8.2

You need each VM to have its own USB controller passed through for that to work. Most KVM switches are physical switches i.e. it's equivalent to plugging and unplugging so you need to manually replug it in the software (e.g. using the Libvirt hotplug USB plugin). My 2 main VM's have one of the 2 onboard controllers passed through and I'm able to switch the same keyboard and mouse between them with a cheapo Ugreen switch.

While waiting for the fix, you should be able to manually edit the RAM amount in the xml instead of using the template.

A forum member just compiled custom kernel for 6.8.3 with Vega patch (and optionally with 5.5.8 kernel as well - that makes it even better than 6.9.0 beta in a sense). Perhaps try that to see if it helps your case.

I can report that the syslinux fix above didn't work, unfortunately. It seemed to have work but I just did a large cp and the process is hitting an isolated core.

Talk to SpaceInvader One and collab on a vid?

+1 The GT710 seems to be a very popular budget option.

It's normal. Shfs (the magic behind Unraid shares) has an effective speed limit of 300MB/s to 500MB/s depending on various factors. What I have been doing is to have custom smb config that targets /mnt/cache directly (instead of enabling disk shares) to get max performance.

Install the VFIO-PCI Config plugin from the app store. Then Settings -> VFIO-PCI Config then tick all FOUR devices in group 31 (GPU + HDMI Audio + 2 USB devices) -> click Build VFIO-PCI.CFG file -> reboot In your VM template, you have to select the GPU, the HDMI Audio Device + tick both Nvidia USB devices in the Other PCI Devices section. The 1650 (and similar gen GPU) have 4 devices that have to be passed through together for it to work.

VRM concern is only applicable if you overclock. If you don't (and you shouldn't with Unraid server) then you don't need so many phases. I always recommend Gigabyte mobo because its BIOS allows you to pick any x16 PCIe slot as "Initial Display Output". That gives flexibility for PCIe card placement if you need a GPU for Unraid to boot with (e.g. for easier dumping of vbios, helps with AMD reset bug, hardware transcoding etc.).

That is one tight case. Watch your HDD temp or they may not last very long. What's the material of the side panel on the HDD side? If it's metal then you may improve the HDD temp by flipping the HDD over over and have the metal side contact the side panel (maybe add some thermal pads) to create a kind of heat spreader. Otherwise, I would run it with the HDD side naked and plug a USB fan (one with flexible arm) to direct some airflow over the HDD.

Thinking outside of the box, why don't you just have the server in the same place as your desktop PC since you are replacing the latter anyway?

On a side note, if you run out of SATA ports, it is generally better to replace low capacity drive with higher capacity drive rather than adding more drives. HDD fails in statistical patterns so the more drives you have, the more likely for you to have a failed drive.

Not that one. Plug your stick to another Windows machine and do a Windows checkdisk. Corrupt usb stick has been known to cause a myriad of weird problems so it's always a good idea to eliminate that possibility in diagnosing issues.

You only need to fix what is broken.

Reinstall drivers? Maybe silly question but did you install the Quadro driver? I don't think it's the same as the consumer line.

Ok, so you don't have dup. Try creating a template from scratch with the same parameters to see if it boots. (note: you might also want to pick 4.2 instead of 3.0, which is very old). This is to eliminate a corrupt bios. Remove the virtio driver iso (i.e. leaving just the vdisk behind). This is to eliminate any interference by the boot sequence. Try changing the type from raw to qcow2. qcow2 and raw are the 2 most frequently used vdisk types. /mnt/user is the same as /mnt/cache if the vdisk is on cache.

I didn't ask anything about /mnt/user Have you checked if there's any dup under /mnt/diskx?

Abandon the VM scenario. If you have to use a Mac, use a proper Mac. Going Hackintosh alone is already a risky venture, let alone going Hackintosh in a VM. Of course, if you don't have to use a Mac then use something else. If you have a lot of money, donate to your nearest charity instead of fattening Apple's balance sheet.