testdasi

watchmeexplode5 already provided some answers so I'll just add to some other points. The 400k object count limit (object = file + folder) is the hard limit per team drive. In practice, anything approaching about 150k objects will cause that particular teamdrive to be perceiveably slower (been there, done that). So keep that in mind e.g. you might want to split TV Shows to smaller libraries. In terms of metadata, what sort of metadata? Typically Plex db (which includes what I would call metadata), for example, is stored locally (and should be stored locally). You really don't want that stuff on the team drive because of the high latency. File attributes (also can be considered metadata) depends on the service itself but it's not part of the object limit. So back to the question, what other kind of metadata? I have unencrypted tdrive for family photos (among other things). All our mobile devices are automatically synced to this tdrive (1 folder per phone) and that is mounted on the server as well. So if I need a photo from a certain phone or if I need to push a file to a certain tablet, I can do it from the server. The main reason the tdrive is not encrypted is because the Android sync app doesn't support rclone encryption.

That was a typo. It's using mergerfs now. First line of the post.

Ignore the tdsrc and tddst part. They are specific to the AutoReclone and not to the buzz script. Yes, add the email to the Team Drive (on the Gdrive GUI). Check the Gdrive GUI, go to the Team Drive and see the access permission list.

The OP already wrote an excellent set of script to integrate rclone + mergerfs to Unraid. Have a look so you won't waste time.

There are 2 lsio hydra2 dockers on the app store. Older one points to linuxserver/hydra2 New one points to linuxserver/nzbhydra2 What's the diff between them? I'm using the old one, do I need to change to the new one?

"Considering ZFS" is not the same as "replacing SHFS with ZFS". And I have not expressed any doubt on the fact that SHFS has performance limitation - because I know and implemented workarounds for the limitation. My understanding is this consideration is for the cache pool. SHFS is still the engine behind the array (and shares). Whatever "imagine" you want to do, you can't change the fact that shfs = Unraid so the chance that Limetech would abandon it completely is rather low. Then you also ignored how integrated ZFS pooling is with its underlying file system, which is RAID-based. Selectively implementing the pooling on a different (non-RAID) file system, and then add parity calculation on top, is not going to be simple (assuming no performance penalty). I'm not saying whether it is possible or not possible to do, nor whether it should or should not be done. I'm saying that the SHFS-less ZFS-based product you are imagining is not going to be called "Unraid". And I'm completely ignoring the fact that switching to XFS seems to resolve the issue that the OP is seeing - suggesting the bug is with integrating BTRFS RAID pool into Unraid and not with SHFS. (and directly accessing /mnt/cache to bypass SHFS has been a known workaround for quite some time).

That's like asking MacOS to throw away its kernel and use Linux kernel instead. SHFS = Unraid. You probably meant replacing BTRFS with ZFS.

Ignore the triangles. They are harmless. It stops being annoying after a while.

The xml config looks correct. Try dumping a vbios and use it. Also try using an older version of AMD driver (check for old versions on the AMD website). Newer AMD drivers were known to break pass through.

Copy-paste your xml here

Some pointers: You shouldn't run your memory at 3200MHz (even if the RAM is rated for such speed). Manufacturer-rated overclock is still an overclock and overclocking is always less stable, which isn't ideal for a hypervisor host. There is no graphic emulation in Unraid. If you need graphic-card-like capabilities then you need to pass through a graphic card to the VM. Threadripper should have enough lanes for 4 GPU's. Issue may come with the 2080 because a lot of the RTX out there are 2.5-slot width varieties which means you can't fit 4x cards in the typical slot arrangement. Make sure to get 2-slot width cards. Get a Gigabyte motherboard because you are embarking on a rather "interesting" adventure so any quality of life improvement will be useful. You almost certainly will need to dump your vbios rom file and/or change which graphic card the BIOS boots with. Gigabyte BIOS has the Initial Display Output BIOS setting that allows you to pick any x16 slot to boot with (instead of having to physically swap the card to the first PCIe x16 slot) - check the owner manual. Expect compromises. VM is never the same as bare metal. Watch SpaceInvader One youtube channel for tutorials and guides.

Firstly, the error is with regards to IOMMU group, which was why I suggested you turn ACS Override to "Both". Based on you IOMMU grouping, ACS Override isn't activated (because 41:00.0 is still in group 17) so I would suggest you turn that on first and foremost. Secondly, please dump your own vbios. SIO has a tutorial for that. Downloading from Techpowerup is a last resort if you can't dump your own vbios (which you certainly can because you have Unraid booted on a different graphic card). It's not at all uncommon for new users to download the wrong vbios - and when it comes to vbios, having no rom is better than having wrong rom. Also next time you copy-paste text from Unraid GUI, please use the forum code functionality (the </> button next to the smiley button) so the text is formatted and sectioned correctly. Save you the effort of manually highlighting the device.

Some pointers: Watch SpaceInvader One tutorial on how to dump your own vbios and see if it helps. If you already boot Unraid with the HD6450 and still have black screens then a vbios is needed. It is no guarantee but it should help, unless the card just can't be passed through at all. 2GB for Unraid is probably too little. I would suggest to start with 8GB for each VM and then see your memory usage and then increase it slowly. You want to make sure your GPU issue is sorted before going on in with the RAM. With your plan, you definitely want ACS Override = Both (i.e. downstream + multifunction). It would also be useful to vfio-pci.ids stub your to-be-passed-through graphic cards (there's a SpaceInvader One tutorial on that - it's about stubbing and passing through USB device but the same principle would apply to GPU). Your core assignment is almost certainly not ideal but let's sort the graphics first then we can talk tuning.

If you can boot to Repair mode, from the command line just type the below and it will boot back up again (obviously without Hyper-V) bcdedit /set hypervisorlaunchtype off I have given up on nested virtualisation for quite a while now because of this catch-22 situation. Unraid has docker and VM support so it's not like I miss it to be honest.

Warning: backup your vdisk before running the below. When I tried Docker Desktop, even on bare metal, it wouldn't work because of that Hyper-V not running error. The command below fixed it (run it as administrator). bcdedit /set hypervisorlaunchtype auto However, when booting as a VM (NVMe passed-through in dual boot), the VM wouldn't boot (stuck in the Tianocore screen). Hence backup your vdisk first before trying in case you need to restore.

If the stick is corrupted or drops offline while the server is running (or during boot up), it always leads to strange issues so keep that in mind.

Look to be issue with your USB stick but not because /usr/local is on the stick. Do a diskchk of your USB stick on a Windows machine to make sure the file system is ok. Then boot your server using a different USB port, preferably USB 2.0 port.

Don't forget to change the format on the VM xml / GUI to qcow2 as well. It's very easy to forget after you finished the qemu-img convert. You don't need SCSI to use qcow2 but you should use it to allow the drive to show up correctly to Windows as thin provisioned. Note that you want to install the driver first before changing your drive bus or you may end up with endless bluescreen at VM boot (if that happens, switch back to SATA and it should boot normal again for you to install the driver). And note that raw img is also thin provisioned, just that the size you see is the max size and not the used size.

You might want to post a separate topic with your details and preferably attach your diagnostics (Tools -> Diagnostics -> attach zip file) Also would be helpful to copy-paste your xml and the PCI Devices section of Tools -> System Devices. When copy-paste text from Unraid, please use the forum code functionality (the </> button next to the smiley button) so the text is sectioned and formatted correctly. In the meantime, watch SpaceInvader One tutorial on youtube. That will clear some of the questions you have.

Yes you should. As you start to use the gdrive for things beyond media storage (which you will once you discover how convenient this whole gdrive thing is), you will start to desire separating data for easier organisation and/or approach the limits of gdrive (yes, even unlimited has limits) and/or control access. That's where team drives come in. It's better to start using tdrive now then to wait till you need it and then have to wait for things to be moved about. You can double check the encryption just by trying to access the file from the gdrive website. The file names should be jumbled up and if you download the file, you should not be able to make any sense out of it.

Welcome to Unraid. Good job with the cable there. That is very neat. A few unsolicited tips for you: Ask yourself whether the data in cache pool needs RAID-1 or not. If you are not storing any important data on there, you can make your SSD last even longer by separating write heavy and ready heavy data to 2 SSD instead. The write heavy SSD (e.g. for download temps) should be almost empty most of the time except when data is being written to it. That will minimise write magnification and wear leveling and thus enhance your SSD lifespan. Alternatively, the next time you get a new SSD (which presumably should be larger than 128GB, they don't make that size anymore), add that as a single-drive cache pool instead and just cp data over from the old cache pool. Then use the old 128GB for write-heavy stuff. With the right treatment, SSD's last forever (I still have a 128GB SATA II (yes, TWO) that does not have even a single reallocated sector despite going way over its rated endurance rating). Aim to get fewer large capacity drives instead of more smaller ones. The more drives you have, the more likely you will have a failed drive. And make sure to preclear each drive before adding to the array to weed out the "infant mortality". Are you running Unraid Nvidia? If you want to use the 1660 (or 970) outside of a VM for Plex, you will need Unraid Nvidia build. Read up on it (there's a forum topic) before jumping in. Alternatively, you can pass through the GPU to a VM (with an OS that supports Nvidia e.g. Windows) and run Plex in there. There's a lot of overhead with this + passing through GPU isn't the easiest thing to do but that's one alternative to consider. Change your CPU cooler fan config. It's better to set it to push air onto the cooler and then (pulled) through the rear exhaust fan. That way you kinda create a push-pull config that works a bit better than a double pull from the look of it right now.

What data are you storing in cache? Given SSD is more reliable (than HDD) and even when it fails, it tends to fail gracefully (i.e. giving you time to respond and replace), having a backup can be more useful than mirror redundancy. In fact, running RAID-1 doesn't mean you don't want to have a backup. And separating write-heavy and read-heavy data to 2 different SSDs will help improving the lifespan of both by reducing wear leveling and write magnification. Not saying that redundancy isn't useful but it sounds to me like you might be over-valuing it and dismissing the alternatives.

Any particular reason why you set it at 150GB? That is extremely high value for min free space. No wonder your SSD runs out of free space before the mover runs.

Sounds to me like you set his mover schedule not often enough and/or have a cache pool that is too small for the amount of data that needs to be cached. Also, do you know that filling an SSD close to the brim has a detrimental effect to its lifespan? I think you might be trying to put a bandaid on COVID-19.

I just skimmed through this topic in less than 10 minutes. If that is "countless hours" for you then you have bigger things to be concerned about. Blaming others for your own laziness will get you quite far.