pwm

Be careful about using correcting parity except when adding new disks or after a power loss. It's required to correct the parity after a power loss because you normally always have a couple of blocks with wrong parity caused by all the data disks not being properly unmounted. But for an already running system that is expected to have correct parity, auto-repair may potentially destroy a valid parity because of a data disk goofing and silently reading out wrong data. When the parity computation detects a difference, unRAID doesn't know why there is a difference. It isn't possible to know which of all the disks that have read out a value that doesn't agree with the content of all the other drives. That's the danger with silent errors on RAID systems. When a disk fails and stops being able to read out data, then it's easy for the system to figure out that the data from all other disks can be used to recompute the data from the problem disk. But with a silent error, any disk may be at fault. So a parity error for a fully working system means that you want to be able to sit down and analyze everything carefully to see if the error is repeatable or if it was a single transfer error. With an automatic parity repair, you don't get this chance because the system will then always assume all the data disks are correct and that it's the parity drive that should be rewritten.

Why do you claim this? Note that the link doesn't seem to have any relevance to RAID 0+1 compared to RAID 1+0. It handles the move past RAID 5. When writing, it's the same amount of work to write to a RAID 0+1 (mirror of stripes) or RAID 1+0 (stripe of mirrors). https://www.hdd-tool.com/raid/raid-10-as-raid-01.html#.W0O1TqMh0UE After one disk fails, a RAID 0+1 no longer have redundancy, and will often no longer touch any disk in the failed stripe, resulting in far worse seek and read speeds than if a RAID 10 loses one disk. With RAID 10, it's only the mirror pair that has lost a disk that will have lower read and seek capabilities. The scary thing with RAID 1+0 aka RAID 10 is that a number of cheap boards claims to support RAID 1+0 while in reality implementing RAID 0+1.

One thing to consider. If you have four disks and create two disk spans that you then mirror like the following: | +-+-+ | | A C | | B D | | +-+-+ | Looking at all possible two-disk failures (A+B, A+C, A+D, B+C, B+D, C+D) If A+C fails - the combined drive is down. If A+D fails - the combined drive is down. If B+C fails - the combined drive is down. If B+D fails - the combined drive is down. A+B fails - still working. C+D fails - still working. Compare this with: | +-+-+ | | A B | | +-+-+ | +-+-+ | | C D | | +-+-+ | If A+B fails - the combined drive is down. If C+D fails - the combined drive is down. A+C fails - still working. A+D fails - still working. B+C fails - still working. B+D fails - still working. Striping mirrors gives fewer combinations that brings down the resulting array compared to mirroring stripes.

I don't think LT has missed the large number of posts in this thread. So if they get too bored some day I think this feature has a quite good chance to get selected for implementation. But the obvious question is what unRAID should serve. If it serves from the array, then it will be mighty slow unless turbo writes are enabled. So maybe it needs to serve from separate disks - in which case it's best if unRAID then supports raw disks without file system.

Docker captures both stdout and stderr output. https://docs.docker.com/config/containers/logging/ For information about redirection, see the following link: https://askubuntu.com/questions/625224/how-to-redirect-stderr-to-a-file But > redirects stdout. And 2> redirects stderr. And &> redirects both. Or you can do: cmd > outfile 2>&1

Sounds like the log data is emitted to standard error instead out standard out - then you will see the text scroll on the screen while a zero-size file is created. Output emitted to standard error can be redirected with the following - the number 2 represents the stderr output stream. cmd 2> file

That's actually a trivial problem - Windows supports mounting of disks as directories just as Linux. So you can have c:\mnt\disk1, c:\mnt\disk2, ... By the way - back to the OP. I currently run one RAID with Synology. Not bad. But not really good either. So I keep it as a backup station. It's good for a number of additional spindles. I did look earlier at QNAP. But they are very expensive for 8 or more bays. And I earlier bought a quite expensive QNAP premium media player NMP-1000P. It stuttered for some movies, while my other players did not stutter for the same movies. After having waited for over a year and updated several times, I retired the unit and selected a competitor product. And at the same time retired any interest in other QNAP products since a company that can't supply working firmware for one brand new product within the first year of release can't be relied on to supply working firmware for other products that might be a couple of years old and no longer at the head of the priority queue. One interesting thing with lots of the products on the market is that they are always described as very shiny and premium in the marketing material. And lots of the review sites also posts quite positive feedback - in part because they want to receive more products to review at a later time. Best way to evaluate a product is to locate the support forum and follow it for a week - do the customers get help? Do the helpers seem to know what they are doing? Are they reasonably friendly? Don't forget to jump around on the forum to look for the boiling frustration that hasn't fully reached the level where moderators "magically" remove posts because they don't too explicit negative critique. For many manufacturers, there are often other forum where you will find out if the official forum censors critique. Another thing to look for in forum, when evaluating a product - is there a way to suggest new/improved functionality? Is there any indications that the manufacturer listens? If you wonder - this is a forum where people normally get good help. Most people who don't get help either posts extremely narrow questions - or refuses to supply enough information that anyone can actually even start to help. And the moderators do not have orders to erase critique - you don't find lots of posts with "what happened with my post???". And if you check the release history compared to the feature request thread you can see that lots of feature requests has resulted in new functionality having been added. Try that with Microsoft...

I'm not so sure if you would feel it's headache-free to fix regular SMART scan and mailing of health information in Windows. When googling Windows, you shouldn't google how to share files. You should google how to recover files when the shit has hit the fan. The storage pools in Windows aren't really as easy to use as most information on the net indicates. The majority of the information is the "happy path" information. If accessing your files from outside the network, you need security. Windows will not come with that security unless you invest time. Similar amounts of time as if you do it with unRAID. In the end, it's similar problems to solve - make sure the machine isn't available to hack from Internet. The best way to save time whatever type of NAS you select is to buy a router with a good VPN. Any other solution means you need to install one. And even with videos showing how to install, the #1 problem is still that you need to understand how a VPN works to understand enough that you don't make a huge mistake and leave the barn doors open without knowing about it. When it comes to amount of information, it's often better information available here than for generic Windows installations. The reason is that all information you find if you use Google and limit the searches to this forum is specific to unRAID installations. And most of the information is relating to the most current version of unRAID - a huge amount of information about Windows are for WinXP, Win7, Win8 possibly with or without a service pack that revamps some important subsystem covered in the instructions. You need to realize that the majority of owners of unRAID system already have Windows or Linux machines besides their unRAID machines. So we didn't select unRAID because we don't know what can be done with a Windows machine. unRAID has lots of Docker containers easily available - including containers with Plex etc. You might think Docker is complicated and bad. But Microsoft figured that they want to support Docker on Windows. They didn't arbitrarily made that decision. The cost? $59 is like the price of a decent CPU HSF. So a rather small cost compared to the cost of a complete machine. In the end, it can be quite good to sometimes move outside of the personal comfort zone - even if it means you have to spend some additional time to learn some new concepts. It's not until after you have learned the new concepts that you will have the knowledge level needed to actually be able to compare different systems and be able to understand the advantages/disadvantages of doing things in different ways. You must obviously make the decision what to use. But I don't really think you would get a better total "cost of ownership" by going your "headache-free" route.

My recommendation is that you consider a backup for all files you really care for, stored on a separate machine. This makes sure the files survives if the PSU of the main server breaks and fries everything. And preferably the backup server stores the backup offline, so a virus or hacker can't erase everything. If you do have backup and lose more disks than the parity can handle, then you can restore just the specific disk(s) that lost the data while still having access to the data of the other data disks. The main trick is to have some form of crontab job that keeps track of which files were stored on which disk, so you don't restores duplicates. This isn't an issue if the backup is made from disk shares but if you backup user shares the backup software will not see which disk that contained the different files. Most of the people we read about on this forum or other RAID forum who fails to recover despite dual-parity have almost always failed the very first rule with a RAID system. They have not been running any supervision where all disk surfaces are regularly verified and where any problems is notified in a way that the owner/administrator will see at least within 24 hours. So they think their system is well even when it is running with one or more disks broken. First several months later when one disk too many fails they log in and notices the catastrophic failure. Or if they notices that one or more disks are emulated and start a rebuild, they find that one or more of the remaining disks have unrecoverable read errors never noticed because they haven't regularly scanned them. So in the end - if you lose three or more disks, the most probable cause is failed supervision. Just failing to notice the issue with the first disk. And then the second. And then the third. And the much smaller but still probable cause is some form of catastrophic event (temperatures, impact, supply voltages, ...) that is likely to have hurt every disk in the machine. There are quite a number of unRAID users who thinks it takes too much time to set up mail notifications. Or thinks that one mail/night from their unRAID system is just irrelevant spam. Quite a number of these users will show up in the support forum when it's too late to protect/recover all of their data. These are also often the people who think parity replaces the need for backup.

I run a rather strange setup, since I work a lot with developing systems-level software. So I run apcupsd to handle my UPS equipment. And more apcupsd in machines that should respond and shutdown to loss of power. And I run a Mosquitto MQTT broker. All apcupsd and lots of status information from the servers are published on the MQTT broker. And I have hacked some basic MQTT support for a Z-Wave hat for an RPi. So subscribing to MQTT topics I can see the current state of all the equipment. And I can publish MQTT topics to turn on/off equipment. In some situations by controlling Z-Wave power plugs. In some situations by issuing WoL. ipmitool can be great if the system supports IPMI. In the end, it's a quite large infrastructure. And quite a lot of it developed when I was a bit pissed about lack of supervision in unRAID 5 and while Limes spent time working on Xen support in early unRAID 6 alpha/beta versions.

I personally have a RPi as "owner" for the UPS units. Besides communicating with UPS and computers, the RPi can also communicate with Z-Wave power plugs to turn on/off equipment. The RPi, Z-Wave and a LTE-conencted gateway is run from a separate UPS giving them a huge battery time. I have some machines that doesn't turn off the PSU on shutdown - so for them the RPi cuts the power from the outside. And the BIOS setting makes them boot when power is restored. Some machines do turn off the PSU. Then WoL or IPMI might wake the machine.

The BIOS has a setting if the machine should resume previous state on return of mains power. So if the machine was running when it lost power, then it auto-boots when power is returned. However, you really should think twice about starting the machine directly the power is returned. If you let it run on batteries and depletes the batteries and you then wake up the machine directly power returns then you have no UPS capacity left - so a second power failure (it's quite likely to get a second power failure if the first was an extended outage) will let your machine fail rather badly with no possibility of a soft shutdown. If you want automatic start after the machine has been shutdown, then you should delay the automatic start until the UPS has recharged. If you are home and need the machine earlier, then you should for that specific case make a manual start after having made an evaluation of the current battery state. If you really, really want the machine to autostart before the batteries have been fully charged, then you should instead configure your system so it shutsdown quite early - at the very max consume maybe 30% of the UPS capacity. Then you will know that there is a good probability for the machine to make a safe shutdown a second time if the power is directly lost again.

A traditional RAID has a much larger need for hot spare support because a traditional RAID that loses one disk more than the number of parity disks will suffer a 100% data loss. unRAID doesn't stripe the data - every single data disk has a separate file system. So a unRAID system with one parity drive that loses two disks will lose 1 or 2 data disks (depending on if one of the failed disks was the parity) - the other data disks will continue to supply valid file content. An unRAID system with dual-parity will lose the data from 1, 2 or 3 data disks in case 3 disks fails at the same time. The other disks will continue to supply valid file content. Since a traditional RAID requires you to read back every single file from backup sources if you lose one disk too much, it's quite obvious why the recommendation is to have hot spare support. Parity is about availability (not replacement for backup) and a full restore of all files from the backup is very far from the availability goals. Note that unRAID supports a single parity-protected array. Besides the array, you can use BTRFS mirroring - commonly used to get redundancy for a cache pool - especially if the cache pool is used to store VM.

Normal best practices results in quite robust electronics. I wonder if HP have picked up one or two hw designers from Apple. Apple computers are known for having quite weird "unlucky" designs. But HP have by tradition managed well to design and produce very well working equipment that just keeps working way past the expected economical lifetime. One problem currently, is that lots of companies buys parts from other companies to save own R&D and manufacturing costs. Normally not an issues, except it means they lose the control and often aren't aware about changes introduced in parts they buy. And the subcontractors aren't 100% aware about how the parts are used. So over time, there may be issues introduced that never would have happened if engineer A could have walked two corridors down and asked engineer B for feedback about a planned product change. I hope you get a resolution to your problems.

There is no support for in-place encryption. And since the LUKS encryption is block-level and sitting below the file system, it isn't something that is easy for Limes to implement - you need to shrink and move the file system since LUKS needs space for an additional header. And in the same way it isn't something that is easy for the LUKS coders to implement, since the different file systems has different needs. So it's basically the file system guys that should have to write the in-place upgrade support for their own file systems. In the end, for the user it's similar to replacing the file system on the disks - you need to clear out the contents from a disk. Then you can reformat and at the same time add encryption. And then restore the data and start the process with the next disk.

Of course. But the #1 step is to realize that a RPi visibly connected to power (and especially if not connected to something else, like the HiFi system looking like a media player) will always be a prioritized target for someone really interested in the installed computer equipment. A WiFi-connected RPi can give important information about how to access the WiFi network and so give even more information about how to attack the rest of the network.

You could reverse the question and it would still be impossible to answer. I.e. if the RPi can connect - how could we know if your phone will also be able to connect given that different phones have better or worse antenna? But if the goal is just to have the RPi as a hidden key locker, then you don't need a huge bandwidth. The biggest problem is that it needs power, so anyone searching for it can start by visiting all wall power connectors and then follow the cables.

But remember that if all of your logic is on your unRAID server, then you have all that is needed to unlock on the server. If I unplug the USB stick, then I don't need to care about any 2FA since the encryption key is on the stick - and if you use a passphrase to unlock the encryption key then that passphrase is also on the stick. And if I find a hole in your network and manages to connect over SSH, then I don't need to unplug the USB stick to retrieve the required information to mount your array. Same issue if you happen to share your flash device over SMB. Your 2FA ends up just being a slightly complicated way of saying "I agree" before mounting the array. A good solution should allow someone to walk away with your machine and still not have access to any material that allows them to unlock any disks. That's why you would want the passphrase for decrypting the LUFS key file stored on your phone or some other device.

Just that if I'm allowed to make 1000 2FA tests/second I'll have access to the key within a couple of minutes. 2FA needs to be complemented with some form of timed blacklist - so minutes of blocking after every three failed attempts. But the problem here is that if the 2FA is used as "is it ok to unlock", then the server must have access to the key + passphrase already and just adds a manual "acknowledge" step. It would be better if a phone contains an app that stores the passphrase. So the server itself computes a 2FA and sends to your phone. Your phone verifies the 2FA and if not ok (within +/- one time slots) opens a popup informing about failed attempt from unRAID server. If 2FA test ok instead opens a popup asking "ok to unlock the unRAID key?". If you press ok, then the phone sends out the passphrase to unlock the key. Then the phone only includes a 2FA key and a passphrase. And the unRAID server only includes an encrypted crypto key and a 2FA key. You need to hack both sides to get access to the unencrypted disk key. Or you need to loop enough 2FA attempts while the phone paces how many answers/minute it will allow.

Yes - with 1 miljon combinations it's quick to test a huge number of configurations to find one that works. It doesn't matter much that the receiver randomizes a new number every 60 seconds if it's possible to perform many tests per second. Let's say a test takes 1 ms. Then 60000 numbers can be tested in a minute. So testing the first 60000 numbers again and again would every minute give a 1/17 chance to try the correct code. So a server that only relies on a 6-digit number needs to force a long delay between each test. And even then, the probability of hacking the 6 digit number will be millions of millions of times easier than attacking the actual crypto. 2FA is intended to be used together with some other security - not as the only security - that's the reason for the name two-factor authentication.

No, I don't think using consumer disks should be an issue. Just wondering if there might be some interaction with pin 3 of the SATA power connector - the signal in the SAS standard and in SATA v3.2+ and v3.3 intended to turn on/off power to the drive to force a full reboot of the drive. But I can't understand why connecting two SSD would make the backplane change behavior. And I can't see how 2xHDD + 2xSSD would draw so much current that something would break.

Any component burned by supplying power to four disks?

Seems I missed the actual link in my previous post. A lot of motherboard-specific configuration files for the sensors package can be found here: https://github.com/groeck/lm-sensors/tree/master/configs

This link contains specific configuration files for a number of machines and motherboards. With some luck, you can find your hardware there. Or you might get lucky by googling for lm-sensors and your motherboard name - it isn't unreasonable that someone else have spent time trying to figure out the exact translations required. But have you verified that you actually needs to do anything? A number of sensor chips normally have standard measurement ranges that are already represented in the file /etc/sensors3.conf

Depends on the hardware - but people could use way more than 4-5 HDD for many years when dual rail was the required/expected standard for PSU. The implications of dual-rail or single-rail matters way more for people building 24-disk systems than for people building what is more or less a standard PC.