pwm

Most probably. But as long as they aren't constantly updated they probably can't combine and reach into TB-class disk wear.

The SSD is responsible for wear-leveling. So it will regularly change the internal mapping what flash blocks that will be used for different LBA written from the OS. A more troubling issue is write amplification - how very small writes will count as large writes when it comes to actual drive wear. If the SSD have 128 kB flash blocks, then it isn't always possible for the drive to fit 128 kB of writes on the block before it needs to erase the block and restart. And when it's time to erase a flash block, the drive sometimes has part of the block in use and so have to copy that data to a new block before it can append the new write - so the drive then performs additional internal writes besides the writes sent over the SATA cable. Some SSD has a specific SMART attribute that specifies the amount of write amplification.

There is no obligatory need to trim SSD. It's just a question of which SSD you buy - an SSD with a hidden overprovisioning pool will handle block erases in the background as it rotates flash blocks in/out of the overprovisioning pool, making it possible to treat the SSD as a normal HDD. So a RAID with SSD can work very well, and there are already lots of products that runs RAID on SSD.

Read the word again - it isn't about s or z in the word. It's about the representation of the first character in the alphabet.

Artistic freedom to give the text just the perfect width.

Only on one machine. But it might be worth checking up if you bought a pair of licenses and so might have an additional license still not in use. LT earlier had an option to buy a two-pack licenses.

Lots of transfer errors would produce the effect that the array becomes sluggish.

I'd recommend producing a process listing before the reboot - just to see if some process is consuming lots of CPU or having eaten lots of RAM. If there is an issue, it can only be fixed if people help to collect evidence.

Yes, much much better now. Thanks everyone involved.

An advantage with hanging drives is that it's much easier to free-float them - using rubber grommets to isolate them from the vibration of the other drives.

The spam bots are already written, and proven in battle. They are not relying on forum posts to pick up new skills.

Yes. Putting a break on new accounts is the most efficient way to get in control, even if it isn't foolproof.

I hope so. But General Support has 525 pages with threads. No one will remember all these threads and catch if some spam bot has cut the first paragraphs from one of the threads and added as a new thread.

I just hope these spammers doesn't make use of the copy/paste logic some spam bots have implemented, where they cut text from older threads and paste into the initial posts just to trick manual moderation into accepting the account - and then at a later time when having passed the moderation stage switches over to traditional spam posts.

TX-100 and TX-1000 uses the wires differently, which means TX-100 can work where TX-1000 doesn't. TX-100 only needs two of the pairs, while TX-1000 needs all four pairs. Besides that, TX-1000 uses a higher bandwidth through each pair making it more sensitive to a bad connection.

Why do you see it as "be stuck on Legacy"? It isn't like UEFI will magically make computers much better.

It's very often caused by a bad network cable.

i just found my machine doing that on a 6.3.5. It has been consuming 104 hours so just over 4 days since it went bananas.

I don't use a cache drive either. There is a notification setting if unRAID should store the notifications to the flash drive and I have that setting enabled.

Yes that is a relevant issue - I normally use a workaround on the version_compare() to handle that case, since string-compare fails so very badly unless you whip everyone to use a very narrow definition of version numbers.

version_compare() will: - correctly handle compare of two versions a.b.c[optional prefix] - correctly handle compare of two versions yyyy.mm.dd[optional prefix] - correctly handle compare from a.b.c[optional prefix] moving to yyyy.mm.dd[optional prefix] as long as a is lower than current year. - fail to handle compare from yyyy.mm.dd[optional prefix] to a.b.c[optional prefix] unless a is larger than current year. In the end, version_compare() is the expected function to use, because the problematic variants for version_compare() are just as problematic for string-comparisons because it represents a comparison that are not actually defined. Not even a human can compare a 1.2.3 with 2017.12.10 and know which is newer, without access to the history log for the software. A pure string compare can't understand that 2017.10.12rc10 is > 2017.10.12rc2.

Have you actually tested? <?php function test_ver($v1,$v2) { echo "version 1 [$v1]\n"; echo "version 2 [$v2]\n"; echo "Compare: ".version_compare($v1,$v2)."\n"; } test_ver("2018.01.11a","2018.01.11b"); test_ver("1.2.3","1.12.1"); ?> Result: version 1 [2018.01.11a] version 2 [2018.01.11b] Compare: -1 version 1 [1.2.3] version 2 [1.12.1] Compare: -1 So it did understand that 2018.01.11a is less than 2018.01.11b. And it did understand that 1.2.3 is less than 1.12.1.

Yes, PHP's version_compare is quite flexible and will properly handle most common ways of writing version numbers in the proper way. So I very much recommend that this function is used instead of a strict string-compare.

Best would be to do a version compare. That's a compare where each field is split at the '.' and compared as numbers. A version compare would then treat 2018.01.10 the same as 2018.1.10. And a version compare would also correctly handle 1.2.3 compared to 1.10.19, ie. traditional version numbers. The only thing to think twice about for a traditional version compare is potential suffix characters after the last numbers. They have to be compared as normal string so 1.10.1 is sorted lower than 1.10.1a. See for example: http://php.net/manual/en/function.version-compare.php

A UPS specification of 700 W / 1200 VA can't be used to get any load factor. It can only be used to compute the largest power factor where the UPS still can give out maximum true power without becoming limited by apparent power. It is the power factor of the actual load, that decides if the UPS will reach the maximum limit because it reaches 700 W or 1200 VA. So to display the power in W, you need a UPS that measures and reports the load in W. Or reports the load in VA + PF. Without that information, you have no option but to display the information you do have available. So you need to skip displaying W and only show VA or %.