testdasi

For advanced rules like that, I would either use Unassigned Devices or rclone to mount the remote server as a local disk and then use more a more advanced tool. Alternatively, you might want to consider Syncthing (docker is available on CA). Has a lot more functionalities.

I also don't think this is a bug. You might want to post in the support forum to get more visibility. Note 3 things: please provide as much details as you can of what you did (your current post does not have enough details) Tools -> Diagnostics -> attach zip file Enclose any xml / error messages etc. in the code block (the </> button next to the smiley button - makes it way easier to diagnose errors in xml etc.

First thing first, get your unit right please. You use "mb/s" for everything. Do you mean megabit per second? Then your "Ran a file write speed test on my cache drive and was able to hit 160mb/s write speed consistently" suggests a potential issue with your cache drive. 160 "mb/s" is 20 megabytes/s - incredibly slow. Also Have you checked if your ISP and/or VPN is capping your torrent speed?

First time I heard of reset issue with Nvidia cards. What exactly did you do when you "re-install" your VM? Did you change the template? Did you update Unraid to a newer version? You must have changed something else beyond reinstalling Windows. Also, Tools -> Diagnostics -> attach zip file.

I was doing some testing last night and noticed that with Hyper-V turned off, CrystalDiskMark on my passed-through Samsung 970 NVMe was: about 60% slower with random I/O! sequential (read) is capped at 2.6GB/s (Hyper-V On is 3.5GB/s) Especially considering how much the random I/O dropped, I would hypothesize that it has something to do with latency. I didn't have time to run any GPU benchmark but given the above, presumably that would affect GPU performance too. So perhaps, anyone who thinks their GPU isn't performing up to par might want to turn Hyper-V on (and perhaps try resolve the error code 43, if affected, via some other tweaks - I don't have any issue with this for both my 1070 and 710).

Updates: Great news! 6.8 has resolved the peculiar lagging with ACS Override On (that seemingly only happens to Gigabyte X399 motherboard). Tested with 6.8.0-rc7 and no lag with both Q35-4.1 and i440fx-4.1. ❤️ the new kernel! During testing, I also discovered that Hyper-V has an impact on performance. I did CrystalDiskMark on my passed-through Samsung 970 NVMe and noticed with Hyper-V off: Random I/O is 60% slower! Sequential is capped at 2.6GB/s (approximately) (3.5GB/s with Hyper-V on). Extrapolating on the above, I would imagine GPU performance would be worse with Hyper-V off too. Hence, I would say unless you have error code 43 that can't be resolved with any other tweak, don't just turn off Hyper-V by default. Finally get what the Unraid Mount tag thing is all about. It allows you to mount Unraid share directly to a Linux mount point (presumably skipping network). The mount command needs to be run inside the OS for it to work e.g. sudo mount -t 9p -o trans=virtio "Unraid Mount tag" /mnt/example

I remember a number of posts about the RX570 not cooperating with passthrough so you might run into problems with that. Depending on how things play out, you might want to budget for another GPU just in case.

Ahh, sorry I completely forgot about 1st gen vs 2nd gen. My 2990WX used to swing quite hot with early BIOS too. Ironically, AMD recent BIOS went a bit too far the other way so there isn't enough voltage leading to instability. I had to tune it up a bit LOL.

Don't overclock TR. Just use Precision Boost. Because it raises clock (and voltage) on-demand, it will run cooler and consume less energy. I have found it to be superior than any effort to manually overclock. That's still a bit hot I think. I'm writing this post while transcoding on half of the cores in the background and I'm at 38 (with whisper-level fan noise). You might want to change the fan curve in your BIOS a little bit to get a bit more juice out of Precision Boost. (or maybe your temp was already with Precision Boost tuned up, which is then normal ).

There isn't really a "need" for a 2nd SSD. Each guide is specific for a particular use case so ask yourself if it's your use case or not. If the guide says you need a Ferrari, doesn't mean you need a Ferrari if you don't have a use for it. 1 GPU can only be used for 1 VM at any one time. It can be used across multiple VM's provided (a) the VM's do not run simultaneously and (b) the GPU doesn't have reset issues (mostly an AMD problem). (Docker) containers are independent of VM's. For Unraid, you can more or less consider docker containers equivalent to Android apps. Your incompatibility question is hard to answer. Of course there are hardware out there that are incompatible with a certain feature or down right not work or may or may not work depending on the exact config / model. For example, Intel 660p NVMe SSD can't be passed through via PCIe method (Linux kernel issue) Marvell controller basically doesn't work (again Linux kernel issue) Nvidia driver, under the right (wrong) conditions, will refuse to load with the infamous error code 43 i.e. detected that it's being used in a VM So really the only way to know for sure that there is zero issue is to confirm with someone with the exact same config. MacOS VM though is a rather niche use so I would recommend you check with SpaceInvaderOne for hardware issues. In terms of stability (which seems to be what you meant by "maintenance), once it's running, it won't randomly crash unless there's hardware issue (which isn't an Unraid problem). Bad RAM, for example, will crash stuff - you are just more likely to notice it with 24/7 server than a on-demand workstation. It's UNraid array. Very important to make the distinction that it is NOT RAID. For example, don't expect RAID-5 performance. I have Android phone, Linux, Mac and Windows accessing the Unraid server without any specific app. The specific apps is more for specific use case (e.g. if you want the nice Nextcloud interface instead of having to connect via smb). I have added 3TB, 4TB, 6TB, 8TB, 10TB in my array at different points. I wouldn't call it "tricky". Ability to use mixed-size HDDs is a selling point of Unraid so if it's tricky then it would defeat the purpose.

Good to hear. Just out of curiosity, your Mac VM, was it just standard MacinaBox + pass through GPU?

What has been written won't be redistributed. When trying to redistribute data manually, make sure you don't accidentally move files between disk share and user share because you will lose data. Due to that risk, it's better to just let thing slowly correct itself over time as more data is written. There is an Unbalance plugin that can help.

Low usage does not equal reliability. In fact, they could be failing and you don't know it simply because they are on the shelves. I think your downside, while true, is a bit misguided. Probability speaking, having 10x5TB almost doubles your probability of having a failure than having 5x10TB, assuming equal probability of failure of 5TB vs 10TB drives. Also according to Backblaze data, newer high capacity drives seem to have better reliability than older smaller capacity drives. That means the probability of failure might even more than doubled for the former. Then you would have to consider that older drives are usually also slower on average so 10x5TB array will need more than half the time of 5x10TB to build / rebuild. (i.e. the shorter time exposed to risks does not fully offset the probability of such risks). So yes, building/rebuilding is painfully slow but the first priority should be not needing it to begin with. Ask yourself whether you need the faster speed first before deciding if a share should use cache or not. Wifi transfer shouldn't need more than 30MB/s - 50MB/s (within typical "Normal" write speed with parity). Wired transfer shouldn't need more than 125MB/s (within typical "Turbo Write" i.e. reconstruct write speed with parity). The cache functionality was originally created back when HDD was incredibly freaking slow. Modern recent HDDs are usually fast enough for typical NAS uses that you really don't need cache for such purposes. Cache is more useful for things that actually needs the speed such as appdata, vdisk, temp files etc. You can have install all the drives but leave them out of the array as spares. They should spin down on their own (at least on my current and previous servers).

Where can't you find it? In Unraid or in the VM? Q35-2.4 is pretty old. What version you had before that? Why did you change it to Q35-2.4?

Your current Write Mode is "Normal" i.e. Turbo Write is off. I would suggest doing your test without the plugin. The settings for Turbo Write is controlled natively in Unraid settings You don't actually need the plugin to turn it on and for testing purposes, having the plugin introduces a variable i.e. it can turn off Turbo Write when you want it on etc. For your other questions: No. Won't be faster. The initial bust is due to write caching in RAM.

Sounds like you want "Most Free" allocation. Why don't you just pick that instead?

Please can you edit your post and enclose each of your error, IOMMU grouping and xml sections in the code block (the button that looks like </> next to the smily face button). It's incredibly hard to read when everything is the same colour and font size, which is why the forum has that code functionality so that your narrative and the "code" (i.e. the system's "narrative") have different format and can be easily read. Help us help you, please.

I don't see any reason why not. Depending on what cheap GPU you use, you might even still have a spare PCIe slot left for other uses. I can't quite connect your points about IOMMU group issues and needing the NIC. Shameless plug: you can have a look at my rig below with that mobo (with IOMMU groups)

Could very well be thermal throttling. 55-60 is excessive. My rig, even at full load + Precision Boost On is in the low 50s. My rig temp change under load is also gradual, or at least certainly not qualify for "shot right up".

You are asking rather simple questions with no details for a complicated issue. What are you copying between (over network? VM to VM? VM to array? VM to cache? cache to cache? etc)? What is your share setting? What is your SSD? How big are the files? How many files?

Try installing the Tips and Tweaks plugin, and use it to tweak Unraid to turn on boost + change CPU profile to Performance. Also 500 MHz seems exceptionally low (my TR4 idles in the GHz) so perhaps you have some power saving thingie in the BIOS turned on.

1. Certainly possible. 2. Ryzen is the economical choice right now. 3. Define "maintenance". I have to clear my fan dust filter regularly but that's regardless if I run Unraid or not. In terms of experience, go to Youtube and subscribe to SpaceInvaderOne channel. His guides are pretty dang close to having someone sitting at your desk doing it for you. A gotcha that you may want to consider: Your Mac Pro RAID5 will not be readily convertible into Unraid array so don't sell your MacPro before migrating your data. Depending on your tech savvy-ness, risk tolerance, budget and how much of the RAID5 pool you have used, the migrating approach will be different.

Having all your shares "gone" is likely due to the USB stick corruption you had and not because of your formatting of the cache drive. This is assuming you have at least some shares with Cache = No (or Cache = Yes and you have already run the mover in the past). Now, the reason you have "No Backup Sets Found" is probably because you set your data share to either Cache = Only or Cache = Yes so the backup was already erased by your formatting of the cache disk. (in the case of Cache = Yes, you might have formatted the cache before running the mover so the backup is still in cache). So unfortunately I don't think your data is recoverable.

Q1: Your choice is justifiable but note that, just like with TR2 vs TR3, AMD could simply make Ryzen 4 not backwards compatible (or selectively compatible) and then all your future proofing goes out of the window. To be honest though, I have always thought TR was a stop-gap measure to get ultra high core count so have never thought about future proofing it. Q2: picking which slot as primary GPU has been a BIOS option feature for Gigabyte mobo so that's why it's good for Unraid VM uses. IOMMU grouping is almost never certain without owning the actual board. Q3: Black Friday (and Cyber Monday) is generally overrated for bleeding edge tech. Most of the times you get last-gen stuff on sale and bleeding edge stuff "on sale" after a price increase the month prior.

Same physical node has better latency but in term of pure speed, more cores beat fewer cores. So it depends on the workload. Gaming should be same node. Transcoding wants as many cores as it can get.