pwm

That depends on what you mean with will work with unRAID. The Smart-UPS can communicate with unRaid allowing unRaid to know when it's good to turn off. The Smart in the name is because it got a smart interface to inform servers about the current state. It will be the size of your machine that decides if 1500VA is enough, but 1500VA is normally enough for a very powerful server.

The .ssh directory must only be accessable by the owner. If id_rsa is registered with multiple servers (the corresponding *.pub file content added to the authorized_keys file of the servers) then you don't need to do anything extra to connect to these servers. But if you want to use different keys when connecting to different servers, then you either need to supply the key name on the command line whenever you connect. Or create a config file that describes which key to use for which server. So a sample /root/.ssh/config file might look like: Host nas HostName 1.2.3.4 IdentityFile /root/.ssh/key_for_server_1 Port 2222 Host monster HostName server2.long.domain IdentityFile /root/.ssh/key_for_server_2 User sysadmin LocalForward 1080 80 With above, you can do "ssh nas" and the connect happens to IP 1.2.3.4 with the server key key_for_server_1. And you can do ssh "ssh monster" and you will connect as user sysadmin on the machine server2.long.domain using the second server key.

I just saw another strange thing with the unread threads logic. In the announce subforum, I came back out from having read all new posts in the release thread for 6.4.0. Suddenly had two unread threads - the release thread I had just visited and the new thread with update notes. Clicked once more the bullet for the release thread and got sent to the first post. Manually clicked last page - no new post to find. Then exited and still had the same two threads unread. Repeated the same action once more with the same result. Trying to read the announce thread just could not clear any unread bullets - and never had any unread posts to read. Clicked instead on the bullet for the update notes thread. Noticed it had received a third post - and that the first post was edited. Exited that thread and that cleared the update notes for both the update notes thread and the 6.4.0 release thread. Not sure if this is related, but the first post in the update notes thread was to my knowledge originally a post of the 6.4.0 release thread but moved into a separate thread. Does the forum get a "phantom binding" between threads when a post has been moved between threads? And will an edit of the moved post turn on "unread" for both the new and original thread?

Just saw the issue again. Had three unread threads. Visited the third. When I returned out, I had zero unread threads. The topmost thread had just about at the same time received a new post. So it seems like there may be some race condition between two users that results in the error.

Not sure I agree. I use BTRFS in some embedded equipment. Before going ahead with it, a test setup did regularly break the power for more than 10k times while the device did run a program that was mass-writing to the file system. No broken file system resulted from the tests. The whole idea with CoW (Copy on Write) file systems is that you don't need a journal. All changes are written to unused sectors and you commit the changes by switching to a new storage tree that includes the new writes. If that last write doesn't happen, then the storage tree will continue to point to the original data. It's just that BTRFS has had a rather large number of bugs, so you need a very recent kernel (or a kernel with the fixes back-ported) to get all the fixes or you'll quickly get file system corruption. For CoW to work, it's important that the final write that switches to the new tree really happens last - if any code block fails to honor the barrier requirements then you can expect serious file system corruption. Alas, BTRFS still has lots of work to do before they have managed to also get the RAID code working properly, when it isn't enough with single-disk barrier requirements.

I have seen it before the spam invasion too. Just have a feeling I might see it more lately than one month ago. But that might also be because I have visited much more threads and subfora.

I have seen the same. I might have 3 unread. I click the third and read. Return to the list and have no unread. Open the other two (no longer marked) threads and they contain unread content at the end. I'm using Chrome. I think I see it more now than a month ago - might it have anything to do with the much more common spam deletions?

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 %.

It's important to remember that if you have a UPS that supplies max 500 W or max 650 VA and claims the load is 50%, then the only thing you know is that 1) the load is <= 250 W 2) the load is <= 325 VA But you can't figure out the power factor, because you can't know if the UPS computed 50% based on VA or W. The UPS could internally have computed that the load was 45% on W and 50% on VA. Or 50% on W and 45% on VA. But it still needs to report the worst-case load percentage, which would be 50%.

I actually think USB3 is fast enough - but it depends a bit on the controller/processor inside the USB enclosure if the enclosure can take advantage of the full capacity of the USB link. But there are at least two reasons why I wouldn't recommend it. - the parity drive in unRAID gets to do much more seeks than what the manufacturer would expect from a normal USB disk. And there isn't much cooling in most USB enclosures. - having both parity drives connected using a single USB cable to a single USB controller means you lose sync for all your parity if you get a USB glitch. And that glitch is likely to happen at the very moment when you really do need valid parity data to recover some problem with your data drives.

Any reason for device /dev/nvme0n1 and not /dev/nvme0n1p1?

If the USB drive still has a NTFS file system, then it can't be mounted as XFS.

He is saying that whenever a new release is published, then the timer is restarted. So if the timeout is set to 72 hours and an author releases a new version every day, then the timer will never reach 72 hours and no update will ever be installed for that application. It's only when the author stops pushing out new releases that the timer will run the full length and the plugin will be updated.

It isn't possible to estimate between VA and W unless you know the specific load that is connected to the UPS. It depends on how well the Power Factor Correction (PFC) of the used PSU works. And the user may also have other equipment connected to the UPS, like switches, IoT sensor equipment etc. The regulations allows higher crest factors (quotient between VA and W) for low-power devices since they have a marginal effect on the power grid. Some old wall warts can have truly terrible crest factors of 10:1 or 20:1. So a single wall wart can require 5 W but 50 VA - a difference of 45 VA from a true resistive load. While a large PSU with a crest factor of 1.1 that draws 400 W measures 440 VA - a difference of 40 VA from a true resistive load.

If notify can't handle a file name, then I would suggest to write a tiny php script that opens the file, massages the content and then prints the result. And then replace cat <filename> with /usr/bin/php safe-filter.php <filename>

It just important to note that the above assumes that the logfile doesn't contain any " characters - or that any " characters have been preprocessed with a break character like \" It is extra important to realize that if someone can manipulate the logfile.txt contents, the above construct could allow a second (and most probably quite evil) command to be run directly after the notify command. What a joy it would be with a logfile.txt that contains Bye, bye..."; rm -rf /mnt/disk*; echo " ...array data Best would be if the notify script supported an alternative form that takes a filename instead of a direct string.

The advantage with a extended SMART test is that it happens inside the drive, so it doesn't load down anything else. The disadvantage is that it will not scream at a bad SATA cable - but a bad SATA cable would normally already have produced ECC errors in the SMART data from incorrect transfers when writing zero to the disk.

Note that a HDD doesn't read back after a write operation, so it will not see if it writes bad data. It assumes that the sector is in a good enough physical state that it will not have more bit errors than what the ECC can safely handle. It takes a full disk read - or an extended SMART test - for the disk to verify that all sectors can actually be read ok.

Is it just a write pass, or also a read pass so the disk gets a chance to test all the just written sectors?

Just a side note - it seems all plugins I have installed uses upgradepkg --install-new and optionally --reinstall And in reality, that means the upgradepkg logic is not used.