JonathanM

Probably. Revert the changes and reboot, monitor.

If the data missing from the shares that is now in lost and found is irreplaceable, you will need to manually sort through it to find what you need.

Most likely explanation is that the help text is wrong, and 0 is being used as the value. Does it work properly if you set that to something other than 0?

include exclude? split level? min free space? all of those settings would be bypassed when going directly to a specific drive. diagnostics needed for more specific answer.

This was the first one I actually owned. https://en.wikipedia.org/wiki/TI-99/4A#/media/File:TI99-IMG_7132_(filter_levels_crop).jpg Still have it plus a few spares around somewhere I think. Transitioned into computer repair doing chip replacement and adding zif sockets to https://en.wikipedia.org/wiki/Commodore_64#/media/File:Commodore-64-Computer-FL.jpg Probably still have some of those hanging around too, but none working that I know of.

Fixing the boot order issue is more important to me. Unless that was already fixed and I missed it. I've always had to manually change the boot order in the XML, form view always messed it up.

Even though it sounded like it, I really wasn't meaning to volunteer your time. I just knew you had good experience with the USB hotplug, and figured if there was enough interest you could put it on the list of things to think about. I honestly doubt it's going to show up in the VM manager, there are much higher priority items that have been left by the wayside for years. Your USB hotplug fills a gap that honestly should have been dealt with in the VM manager a long time ago. The core Unraid team just doesn't have enough time keep everything current that lots of people want, let alone all the little niche projects. Without community support we wouldn't have nearly as many nice toys. 👍

Rapid increases in temp could indicate poor thermal coupling between the CPU and heatsink. Air bubble, too much paste, too little paste, uneven tension causing a lift on one side, etc. Ideally the temp would ramp up over several seconds, the slower the better.

Only if there is a subfolder for each container holding the various threads. I really can't imagine trying to sort out the chaos that would be created if Unraid's entire list of containers had random threads mixed together. As you said, it's bad enough having one thread per container, having possibly hundreds of threads referencing hundreds of different containers all mixed together? It is definitely confusing for a newby to be told to create a new thread for their general Unraid issue, and then turn around and tell them they CAN'T create a new thread for their container issue, they must use the existing thread. Fixing that would mean creating a new subfolder in the forum for each new container as it's created, and considering the bar for container creation is so low it would mean creating a new subfolder in the forum every few days, most of which would only ever have one thread.

You can't replace a data drive with a disk larger than parity, thus the parity swap procedure. Put simply, unless you already HAVE an 8TB parity drive, you can't replace a failed 6TB data drive with an 8TB. The OP implied his parity was 6TB, thus the requirement to do the parity swap procedure. I have no way of knowing how big his parity drive is without diagnostics.

Because each core or hyperthread is 0-100% occupied, so the total load is 100% X (number of processor pieces available) You probably were seeing 100% load on 2 cores.

Quote from the link. Assign the current parity disk to the failed disk slot, and assign the new drive to the parity slot. It should prompt to copy the parity information to the new drive. followed by rebuilding the failed slot onto the old parity drive.

6.10.3 includes the fix for this, so as long as you upgrade directly there you will be fine.

https://wiki.unraid.net/The_parity_swap_procedure Read through this, and if you are not 100% on what you are to do and why, attach your diagnostics to your next post in this thread and ask for clarification.

Not possible from the GUI right now. However, you should be able to accomplish it at the Unraid console with a well formed virsh command. Google virsh change iso for some ideas. Should be scriptable, and probably fairly easy to create a plugin, maybe @SimonF could throw something together?

If the data is irreplaceable, you need to clone the drives as they are now, and put them aside to attempt recovery on copies. A file system check would probably be a good first recovery step.

By default 2 members in a Pool will be configured as RAID1, which means the total space available is limited to the capacity of the smaller of the two drives. You went from a pool with a 2TB capacity to a redundant pool with 500GB capacity. I do not know what happens to the data that is beyond the 500GB limit. Hopefully it's still there, and possibly if you balance to a single profile so it spreads the data across both drives it may correct the issue.

Good luck, let us know how that goes. I tried to do something very similar a while back and gave up. I keep an old low power no fan system semi up to date with pfSense so I can power it up when needed. I've never had an issue with the modem needing to reboot, but I've also never had both ports up simultaneously. It doesn't seem to mind if one MAC goes offline and a second MAC comes up assigned with the same IP. Maybe it automatically releases when it detects no active ports. I don't have HA, I have to be onsite to power up the second machine while ensuring the first is fully down, but it's close enough for me. I so rarely have to touch the machine, I think it's been over a year since I've had the other pfSense running. Probably time to make sure it still works. 🤣

No need, you can run just 1. RAID is never a substitute for backups anyway, I personally have single volume pools with regular backups in the VM set to write to the parity array. In my experience, it's better to keep good backups than worry about redundant storage for the base OS. I too run my firewall (pfSense vs OPNsense) as a VM on Unraid, and regular XML backups allow both quick rebuilds if needed as well as temporary transitioning to a hardware firewall when needed for longer maintenance tasks on the main array. I use homeseer instead of home assistant, but it's probably a similar situation, where standing up a new OS and restoring from a backup is quick and easy. It's not worth it for me to dedicate a second SSD for redundancy. I'd rather keep good backups that allow moving to completely new installs if needed rather than wasting hardware on a single failure mode recovery solution. Disk redundancy only helps with drive failure, it can't deal with the myriad of other risks that backups cover. The parity array is another risk assessment, and having disk failure recovery that only "wastes" one or two drives to cover the entire array of 11 (for one of my servers) drives is worth it, and I don't have backups for all the media that is recoverable by re-ripping blu-rays or whatever if the worst case happens. Regardless of disk redundancy, you must have backups elsewhere of anything important. A power supply failure is all it could take to wipe out all your drives, redundant or not.

Already available as a third party modification. Not sure what you are getting at. Unraid unpacks the OS into RAM, and boots from there. No impact from disk formats. Or are you talking about boot times of the VM's? In which case yes, a 10 second boot from a decent NVME drive vs. 3 minutes on the parity array is probably about normal.

https://netcraftsmen.com/just-say-no-to-jumbo-frames/

Sounds like you may have disturbed some cabling. Try verifying and reseating all the motherboard connections. Do you get the Unraid boot selection screen where you select safe mode, gui mode, memtest, etc?

Have you looked at the USB stick in another machine to confirm all the files are indeed there? Possibly manually copying the bz and changes files to the root of the flash from the download zip file would help.

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.