JonathanM

vdisk files living on the parity array are workable, but keep in mind random writes are going to be way slower than any typical disk. Orders of magnitude slower. I would never actively use a VM with vdisk files stored on the parity array, I only use them for tasks that aren't time sensitive, background processing stuff only. cache is a holdover term from when it was first introduced, back when 40pin IDE interfaces were the norm. At that point it was preferable to write new data at the normal speed of a single disk, then overnight that data could be moved at the parity write restricted speed to the storage array. It never was a real read / write cache. Nowadays the more accurate way to describe things is a single parity protected array, with multiple pools of single or BTRFS RAID array drives for higher speed usage. The parity protected array is still intended as a low speed mass storage destination with flexible disk size and single disk recovery even when you exceed the parity recovery threshold. If you have dual parity, you can recover from 2 disk failures, more failures than that and you can still read all the good remaining disks, instead of losing it all like traditional RAID arrays when you exceed the fault tolerance. Unraid isn't positioned as an enterprise SAN, it's a hobby OS that can be used in a business setting with careful management. With tweaking and high end parts, it's capable of quite a bit, and as a media station, it's formidable. Based on the tone of your posts I'm afraid your expectations are much greater than Unraid is capable of delivering.

Which parts are you missing? Since the license is tied to the USB stick, and not any specific motherboard or controller, you can always use any PC that's capable of booting the USB stick, just don't assign any drives and the PC your are temporarily using won't be altered in any way.

If you do that Unraid won't start properly. Revert instead to the go file packaged with the installation zip archive.

The application itself cannot make changes to the container template. The template content is up to the publisher of the template, and you can override update changes with an edit to your local template. I forget what exactly needs to change, but a good search should reveal what you need.

The official plex container doesn't have a support thread on this forum, they have their own support at https://forums.plex.tv/ There are several plex containers that are supported here, maybe try one of those if you can't get the official one to work?

Maybe this? https://en.wikipedia.org/wiki/U3_(software)#U3_platform

That's for the RAM, you also need to verify the CPU / chipset maximum speed for your configuration. Many AMD require slower speeds for stability.

Did you pull all the old PSU supply cables out, or did you reuse some of them?

I would also strongly recommend getting fully migrated away from ReiserFS to XFS before you move to the next stage getting things running. You will need to systematically copy files off the ReiserFS drives onto your XFS drives, format the ReiserFS drives that you copied from to XFS to make room for the next batch of copies. There is a whole thread dedicated to the different methods and techniques used for this.

I'm guessing you hit enter before you finished the post. You can just reply to this thread and finish your thought.

Maybe, depends on the enclosure. USB is not recommended for Unraid's main array for many reasons. I recommend watching a few youtube videos on Unraid, so you can get a feel for what it is and isn't. Also, https://wiki.unraid.net/Manual/Overview The way Unraid's main array works means all the disks must be accessed simultaneously for parity building and recovery operations, and USB is bad at that type of I/O, some enclosures and USB controllers also have a bad habit of resetting connections which can cause a drive to get kicked from the array. Some have managed to get USB to work somewhat, but it's definitely not ideal.

@SpencerJ? It may be a few hours until you can get a response, meanwhile I'd fill out and submit the form on this page https://unraid.net/contact

Trying to get the iGPU to function on a board with IPMI has been problematic in the past, I seem to remember @Hoopster may have some experience.

You probably have a share set to cache prefer, which puts the files from the array onto the cache drive, instead of cache yes, which puts new files on the cache and moves them to the array. Attach diagnostics to your next post in this thread if you can't solve it.

If you are erasing the drives after you copy, why bother deleting? It's a good idea to verify the copy after it's done anyway, and you can't do that if you delete the source.

That is not a permanent fix even if it works at the moment, it may not work on subsequent boots, as the sdX designations are subject to change based on many factors out of Unraid's control.

mc?

SSD's in the parity array isn't recommended for performance reasons, unless all the array disks are SSD including parity, even then there are limitations.

Are you positive you are monitoring the correct sensor? Sometimes the names are misleading.

FTFY. Yes, I would request a new drive sent with proper packing. Take photos and record the S/N before you return it.

Parity only applies to the main array, not to pools. Pools can be configured with various BTRFS RAID levels, but I don't think it's wise to attempt to expand a pool that currently has errors, you will probably end up worse off than before. I think your best option is to follow the replace cache disk procedure, which does entail using the mover to send the data to the main array by setting any cache prefer or only shares to cache yes, and running the mover. Typically you would need to disable the docker engine and VM services in the configuration so their tabs are gone from the GUI before you run the mover. Attach diagnostics to your next post in this thread for better educated opinions.

If you set a new config, add a blank 18TB as parity, and add your current 18TB as disk1, and the rest of the drives which have data you want to keep as disk2, disk3, etc, then build parity that would accomplish what I think you want. You will need to copy data from disk to disk manually, and since you already started with one 18TB in UD, you may as well keep doing that manual process to copy the content of all the disks you want to remove, then only build parity with the drives you want to keep. If you copy instead of move, you can keep the removed drives as backup.

Formatting is NEVER part of a recovery. The emulation includes the file system, so when you format, you tell Unraid to empty the filesystem. Hopefully you can read all the individual disks and recover your data, it doesn't really sound like you had real disk failures, more failure to read or write. Posting diagnostics may shed some light on what's currently available, but since you've rebooted multiple times since this started, the original errors that started this are lost.

Edit your top post in the thread and change the title, add [Solved] or something like that.

In my opinion, if you truly need VM primary drives larger than 265GB, then I would add the 1TB (1gb typo?) as an additional pool, dedicated to just the VM(s) primary vdisk(s). (domains share) Then you can use your current cache drive as storage for appdata and system shares, and as a temporary home for work in progress. Use the storage array for finished work, archives, and reference materials.