pwm

Not sure what you mean with this. If you enter a name, then that name needs to be resolved to an IP number. But if you enter an IP number, then no resolve needs to be done - there is no hostname or domain name involved when you have already specified an IP number.

That was a very nice price. Lots of recovery options adds one or two digits more in the recovery price.

Good to hear you got your data back. How much did they want?

I'm not sure it matters when updating just a single data disk - the data disk also has to perform read/modify/write so for single-disk-writes it should still be the slowest of the two disks that decides the write speed. But since the parity is involved for any data disk writes, it's obviously never good if the parity drive is slow.

It is, when you are writing to a single data drive. But if you write to two data disks, then the parity drive is involved in both tasks and have to do much more seeks and writes than the individual data disks.

It's mostly caused by some process being hung inside the kernel with process state 'D' which is a non-interruptible wait. It's hard to know if it's caused by a hardware bug, a software bug or some random glitch like a memory bit error or power surge. So you can check with ps if you have any threads hanging in this state. And there just is no way to kill them, which makes Linux unable to unmount and shutdown gracefully.

It's hard to prove they are better. But the manufacturers explicitly specify that they are intended for 365/24/7 use, and that they have some form of detection to abort and retry writes in case of vibrations from other drives. They are also specified for a decent workload, i.e. number of TB of transfers/year.

Something happened with the shfs process - this is what it looks like when a FUSE application goofs.

Btrfs should be very good at handling power loss for single-disk use. The open question is how it handles different variants of disk pools, where there are cross-disk synchronization issues introduced.

Now this sounds like famous last words...

Since all your data fits on a single disk, the cost of backup is basically the cost of a single USB hard drive. And for some data possibly the cost of DVD-R or BD-R media. I recommend that people put a value in real money on the different data they have. How much money do you want to receive to intentionally destroy the contents of a specific directory of data? How much money do you want to intentionally destroy all digital copies of your photos? Do that for you data, and enter the data in a spreadsheet. That should give you an indication of how much money you should be willing to spend on safe storage. If you are fine with overwriting all data if I pay you $100-$200, then it's obvious that you don't need a backup - you don't see any real value in the data. If you don't assign an actual monetary value on your data, then you will never be able to make a good decision of if you should spend $100 on a backup strategy or on some event on the next vacation or partial payment for a new TV. It isn't possible to compare apples and oranges - and since a backup costs $$$ you need to also put $$$ value on the data and $$$ value on the time it would take to recreate the data (if at all possible).

Sounds like a working plan. Just a note. You don't format drives before you place them in unRAID - it's unRAID that formats them. And the parity drive doesn't make use of any file system so no formatting involved at all.

Download speed to where? A cache drive? An array drive? A VM? And with or without turbo write enabled? Next thing - you don't mention anything about how the box is networked. Or what transfer speeds you get to/from unRAID and other local machines.

So run a constantly updating top sorting on memory size - is any process consuming lots of resources during the delete?

If it can deliver the streams but gets overheated, then it would be logical to look at the cooling.

ECC memory with one or more memory addresses with single-bit errors that can be corrected, so the machine can continue to run without failing. The last (top-most) error is probably a memory address with more than a single-bit error. So the machine couldn't continue to run. The event log in the BIOS can most probably tell you which specific memory module that has issues. It might be an error with the module - or possibly you have overclocked it or it's overheating or you have problems with the power supply.

The cheap cable testers you can find just verifies that there is an electrical connection and that the wires are connected to the other end - it will not be able to see if the wrong color strand is used (i.e. if the twisted pairs in the cable are correctly used) or measure the impedances and capacitances to figure out the quality of the cable - no pulses are sent through the cable. Some motherboards have test functionality for the internal NIC - but only to verify that the individual wires are connected as they should or to report distance to short or break for a cable pair. But this is still just good to check for a broken cable. It doesn't measure the cable quality. 10gbe really isn't very forgiving.

Most disks works well to keep spinning 24/7 if you don't worry about the power consumption. I have lots and lots of disks spinning 24/7. But if you have a cache drive, then of course you can use it. Just that I don't think you need it for performance reasons.

You don't need a cache drive to get the required performance to write 24 GB /hour. If the array manages 40 MB/s with turbo write off, that's still about 5 times the write speed your recordings needs. So even without a cache you can record 24 GB/hour and at the same time look at one or more streams from the same data disk.

I have a couple of motherboards with Intel Atom chips. The processor draws 2.6W. The chipset draws 14W. When originally released, more than one magazine and web site pointed at the chip with heatsink+fan and claimed it was the processor, while missing the anonymous chip beside. It as a chipset basically designed for P4 processors, and a great way to get early Atom chips a very bad reputation. The machine I currently sit at was delivered with an extra fan accessory to be fitted over the chipset just in case the user decided on water cooling the processor. So it's easy to miss out on the cooling requirements of the chipsets.

No additional input lag if the VM owns the USB controller and graphics card. It's just some of the hardware sliced off and running as if was a completely separate computer. It's only when you let the host own the USB controller that you will suffer input lag because you then add an additional software translation layer before the gaming OS will be able to see events from the connected USB devices.

"Best" when noise matters is to have a case where you can use as large fans as possible, since large fans can use lower RPM for the same air volume. It isn't huge amounts of heat to move away from the chipset, but it still takes a bit of air. Some cases have shrouds that explicitly directs air to flow over critical components.

Within maybe 10 minutes it should have stabilized at the new temperature after you added the additional fan.

These also often have very strict requirements of a high air speed front-to-back. Especially if the board is intended for use in a low-height chassis.

Take a copy of the content of the config directory - it should contain your *.key file (assuming that you did install the key file before ending your project). The name of the key file will differ, depending on the size of the license. With a copy of the config directory, you should then be able to follow the current documentation how to download and install a fresh unRAID to the thumb drive. Then you can restore the key file and you should have a thumb drive that boots a fresh unRAID.