testdasi

Same, uneventful update from 6.8.0.

Did you attempt to PCIe stubbing any device in the past? It could be that you used the file method and the controller is in the same IOMMU group as the other intentionally stubbed device (probably your GPU). Unraid will try to stub everything in the same IOMMU group, which affected your controller without your realising it. If you used the syslinux method then follow Jonnie advice (click on Flash then scroll down to the syslinux section).

This probably relates to the recent Samba update that changed quite a bit with regards to security. I also noticed permission changes. I don't think there's much that can be done. If you need the insecure workaround then you probably have no choice but to stay on an earlier version that the workaround still worked. Otherwise you need to rethink the workaround.

I bet a beer the answer is Soon™. 😅

I have a working mergefs mount but it just isn't used by anything. I don't do torrent nor hardlink so no benefit there My mount performance is bottlenecked by rclone and not unionfs so no performance benefit either I consider unionfs COW as a protection layer against cryptovirus (and accidental changes). A silent infection + COW would cause my local UD drive to fill up inexplicably which would alert me that something is amiss. So unless I'm missing something, there isn't anything that motivates me to fully switch at the moment.

Problems with your USB stick / port for sure. Your USB stick is in read-only mode after boot, which usually happens if it drops offline (e.g. failed port, reset port, shorted port etc. many reasons).

Any reason why you are not on the latest stable? Hard to troubleshoot if not on similar kernel.

Can your server even boot? i.e. do you see the login prompt on your monitor? If yes, login using your root credential and on the command line, type diagnostics That command should create the diagnostics zip for you to attach so others can help have a look. Also, if the server does not have an IP then it's either a hardware problem (e.g. failed NIC) or network problem (e.g. not properly plugged into router and/or router doesn't work and/or incorrect custom network settings). If your server doesn't even boot then you need work on creating a working USB stick first.

I'll stick to unionfs for now. It's not broken for me so not seeing any need to migrate to mergefs.

Tools -> Diagnostics -> attach zip file.

Marvell controller? The issue came up with 6.7 so you missed all the discussion. Maybe start with reading this:

I would say normal. My Intel NIC can get to 60+ under load and it's gigabit.

You should go back to page 1 and look for bastl's post with the Skylake emulation and use that. The reason it didn't work for the previous poster was because his CPU is FX 8320 which came out before Skylake (so it can't emulate Skylake hence unsupported CPU). Threadripper works fine with Skylake emulation. Generally, as long as your host CPU has AES NI + your emulating CPU also has AES NI + you don't disable it then it should have it.

What browser did you use? Any ad blocker? I tested on Chrome and Firefox and have no problem at all.

Updated from rc7 to stable. Was a bit apprehensive with the kernel downgrade but so far so good.

Try these, hope it helps with the sluggishness. Enable Global C State Control in the BIOS. (Enable, NOT Auto) Create a new template with Hyper-V = Yes, Machine Type = Q35-4.0.1 and the rest of the config the same. Untick Start VM and Save. Then edit in xml mode: Change the <hyperv> ... </hyperv> block of codes to this: <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vpindex state='on'/> <synic state='on'/> <stimer state='on'/> <reset state='on'/> <vendor_id state='on' value='0123456789ab'/> <frequencies state='on'/> </hyperv> Add this bit above </features> <kvm> <hidden state='on'/> </kvm> <ioapic driver='kvm'/> Change the <clock> ... </clock> block of code to this: <clock offset='localtime'> <timer name='hypervclock' present='yes'/> <timer name='hpet' present='yes'/> </clock> You will also need to watch SpaceInvaderOne vid on lstopo so you assign the right cores to the right PCIe slot. Always leave core 0 free.

Sorry but you need to be clearer. What is "default pilot form Unraid"? Also, share your new xml please.

Need pics!

I just noticed you have this: <feature policy='disable' name='hypervisor'/> Any particular reason for that? HyperV can also help with performance so perhaps try removing that line. Failing that, maybe try the path to the disk from /mnt/user/domains/Windows/vdisk1.img to /mnt/disk1/domains/Windows/vdisk1.img That would bypass shfs and hopefully improve performance. Failing that, start a new template and pick Q35-4.0.1 as machine type. Other than that, I'm at lost as to what else could cause performance issue.

Yes you can trim xfs. I trimmed my Unassigned and cache xfs disks all the time. It's xfs in the array that can't be trim cuz it's not mounted with discard.

A few things that come to mind: Do you have Global C State Control turned off? If so, go to your BIOS and turn it back on. It is not required to be off for Threadripper. I also found turning it off negatively affects my NVMe random performance (60% drop!), which could explain your lag when accessing Explorer. SSD in the array isn't trimmed so perhaps that could be the cause but I doubt it since you seem to describe read lag and not write lag. Your 2 iso images buses are "IDE" which is incredibly out of date by now. Change it to SATA. Also your core assignment isn't ideal. The 1950X has 2 chiplets, each chiplet has 2 CCX, each CCX has 4 cores. I have found uneven load spreading across CCX can "waste" as much as a core of performance (so 7 uneven cores perform about as well as 6 cores evenly spread). So I would suggest you try something like: 1-3,5-7,9-11,13-15 + hyperthreading sisters for a total of 24. Bench that out vs your current 28 cores - I have a feeling you may be surprised as to how similar the performance is.

Do these and see how it goes Start a new VM template Pick machine type = Q35-4.0.1 Pick the same GPU + HDMI + 2 additional devices you stubbed Pick Hyper-V = Yes Pick everything else the same as your current template Untick "Start VM" and Save Edit the VM in XML mode Now we try to resolve your black screen. Look for </hyperv> in the xml. Above the </hyperv> add this: <vendor_id state='on' value='0123456789ab'/> Below </hyperv> add this: <kvm> <hidden state='on'/> </kvm> <ioapic driver='kvm'/> Save your template and start your VM and keep your fingers crossed The above assumes your ROM was correctly dumped.

Read through the manual pdf. Find out if the BIOS says anything like "Initial display output" or "Primary display output" or something like that. Having a skim through the pdf on Asus website, I don't think it has that (in fact, it looks surprisingly quite limited - I can't even find PCIe bifurcation but then I skim). PCIe slots are not all the same. And don't confuse "lane" with "slot". A x16 slot can only have x4 lanes. The 2nd PCIe x16 slot on your X570 motherboard only supports up to PCIe x4 speed (i.e. lanes) which, depending on the GPU, can be too slow. If the BIOS allows you to pick the slow slot as primary display then you can put a cheap GPU on that slot to boot Unraid with (e.g. a GT 710) and have your powerful GPU to pass through. You seem to misunderstand what the 2nd ("Unraid") GPU is used for. It doesn't matter if you have never used the Unraid GUI. Having a GPU for Unraid is less a requirement for Unraid but rather to stop the other (main / powerful) Nvidia GPU from booting up (so to speak) so that when it's passed through to the VM, it is less likely to detect that it is being used in a VM and thus doesn't throw error code 43. It also makes things easier to dump vbios etc. Again, there is no guarantee. You can only have 1 GPU and pass it through fine without error code 43 and vice versa may have 2 GPU and have the problem.

Possible without guarantee. You misunderstood odds vs guarantee Having a GPU for Unraid to boot with improves your odds (i.e. probability) of avoiding problems passing through the (other) GPU. It is NOT a guarantee that you will have NO problem at all (or that it is even possible) Conversely, it does NOT mean that it is IMPOSSIBLE to pass through the only / primary GPU. Note that dumping vbios does require a 2nd GPU for Unraid to boot with (so you can dump the vbios for the other card) but once dumped, it does not require the 2nd GPU to use the vbios file. Having said the above, I recommend you have a look at the owner's manual of your prospective motherboard to check if its BIOS settings allow you to pick any PCIe slot to boot with (the primary slot). That gives you the flexibility to go the Unraid GPU route without sacrificing the 1st PCIe slot (which is usually the fastest with best clearance for multi-slot GPU).

I suggest perhaps you post in the UD support topic. I haven't seen this before.