JonathanM

https://www.kingston.com/us/usb-flash-drives/datatraveler-se9-usb-flash-drive Is what I use. USB2.0, rugged, cheap. Mount it internally with a IDC to USB adapter from one of the motherboard headers.

The way this is worded is wrong. Unraid's parity doesn't deal with files in any way. It only recreates the whole drive, filesystem included. When you delete a file, an entry is made in the filesystem, which in turn updates parity. When a drive is formatted, parity changes to match. When you add a file, parity is changed. Every change to the drive is updated to parity, including if something corrupts a file, or the filesystem, causing all files to be unavailable. Parity will happily recreate the corruption on a new drive if you replace it, and the replacement drive will have the identical corruption. TLDR: Parity does not backup your files. Its only use is to rebuild a drive that has not accepted a write, for whatever reason, be it a hardware or controller failure. It cannot restore corrupted or deleted files. Only a second copy of files on another physical device is a backup.

How many different endpoints have you tried? PIA has a bunch with port forwarding enabled, some work much better than others.

If you remove a drive that isn't clear, your parity will be wrong until you do a correcting parity check. You would have been better off to just remove the drive and rebuild parity.

No, sounds like a BIOS issue. Some BIOS's lose their mind when they have too many bootable devices attached. If you are using a HBA of some flavor you can try disabling its boot capability.

Probably not, since the upgrade process just stages the new version for next boot, but why risk it? I don't see what you are gaining by doing it before the rebuild is complete.

I smell a very fruitful collab going on. This is going to be an excellent addition to the unraid dashboard.

Before messing with live data, I strongly recommend replicating your copy scenario with other non involved drives, and experimenting with command line options on healthy drives. Take a known good drive with some data in whatever format, could be NTFS, whatever, doesn't matter, and run your copy routine to a second drive. Make sure that things happen how you would expect, as in that the source drive is unchanged and the destination drive becomes a true clone. That way you have an idea about how things should behave before you play with live data.

If you order the correct batteries, that's not an issue. F1 vs F2 terminals. https://www.batterystuff.com/kb/articles/battery-articles/terminal-type-f1-f2-tabs.html

Not necessarily. The drives need a surge of power to spin up, if power is marginal, it can effect the slowest to initialize or most power hungry drive. If the drive doesn't recover in time to accept a write without error, it will get disabled.

You are probably right. Many "proprietary" APC batteries are simply generic 12VxAH batteries with a liberal application of labels, wires, and double stick foam tape. They should be easy to reverse engineer with some application of force where needed and swapping the wiring to the new batteries. That specific pack looks like 4 12V7Ah batteries to me.

Does the motherboard have a round 6 pin PS/2 keyboard connector? Also, on some boards only a few of the USB ports are initialized for early I/O, and that can be controlled with a BIOS setting.

SATA power connectors are rated for a max draw of 4.5 Amps per wire. You are subdividing that across 4 drives, so yes, it could be a possible issue. It's borderline at best. 4 Pin Molex are rated for 13 Amps per wire, so even if you have to split the load across 2 4 pin connectors on the same lead, it's still better. Even just switching out your current adapters for a pair of 4 pin to 4ea SATA connectors would be an improvement, but the more you can split it up the better.

So pressing a key doesn't continue? Are you sure the keyboard is being detected properly? Caps Lock light toggles when pressed?

Are you sure that's IT mode? It doesn't look like it to me.

SATA power connectors really aren't rated to supply 4 drives simultaneously, I would source several 4 pin Molex - SATA adapters instead, and use as many wires as possible from the PSU split across those drives. How many 4 pin molex and how many SATA power are available on that PSU? I see at least 1 4 pin Molex, and from my experience there are probably 3 more. So, if you get (3) 4 pin Molex to dual SATA adapters you could run your drives from 5 sets of wires instead of 2.

It would be kind of you to edit your post, change the title and add the solution, so the next person that encounters the issue can find the fix instead of having to ask.

4VM's running simultaneously with 16GB of RAM? That's going to be extremely tight, unless all those VM's are happy to run with 3GB RAM each.

Way more complicated than that. I wouldn't have written two paragraphs explaining the differences if it were that simple.

Support. Investigate who is providing it for each specific container, how responsive they are, etc. Official doesn't necessarily mean best supported, it typically just means the author of the packaged app also builds the container. That can mean good things, or it can mean they put it together once and don't bother to maintain or support it. Think of containers as mini-VM's, the application is only one part of it, the base libraries and such are important too, and because of the way docker containers work, if you use multiple containers with the same base, they will all share the same layers saving space in the docker image. So, one way of deciding between otherwise equal containers tips in favor of commonality with your other containers.

It's not that simple. If you want lower power consumption overall, you pretty much need to use a newer model cpu die. The low TDP versions of the same die will likely consume more power overall than the unrestricted version. If a task requires X cpu cycles to complete, the low TDP version will take longer to do that task, keeping your drives and memory spun up longer, causing the overall power for that specific task to increase compared to the unrestricted CPU that will spike to a higher instantaneous power, but complete the task sooner allowing the system to get back to idle. Idle power for the same die type CPU is largely identical across all models, low TDP or not. Low TDP is there for enclosure cooling limits, if you have a normal desktop or server you don't need to bother.

Really no point in continuing a test with a failure shown.

Did you set the memory speed in the BIOS? I'm not sure how to interpret the numbers I'm seeing, does CLK: 3593 MHz mean anything? And yes, any fail on memtest is severe, and must be eliminated before things will stabilize. Assuming the memory is not running an overclock (XMP) profile, I would try swapping sticks around and running on one stick at a time in memtest until you get zero errors over a period of not less than 12 hours, I wouldn't trust my data to a server that didn't run at least 24 hours with a clean memtest.

I would approach it slightly differently. I would slowly increase the amount of resources from a minimum on the VM's until you don't see an increase in real (not synthetic benchmark) performance. Remember the hypervisor (Unraid KVM here) is creating much of the hardware the VM guest thinks it sees on the fly. So by artificially limiting the amount of resources Unraid has available, you may be severely limiting the ultimate performance of the guests. So, if the VM runs well on 1 physical core and 4GB ram, why give it more than it needs to run? Linux is generally very good in using all the resources available, and guest VM's don't readily give back resources to the host. Once you block out RAM for a guest, it's pretty much wasted if the guest isn't maxing it out.

Sometimes the HP branded tool for formatting USB sticks works better. https://www.majorgeeks.com/files/details/hp_usb_disk_storage_format_tool.html