pwm

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.

Exactly - when new versions are released for Android apps, I wait and read the most recent comments before I upgrade. That has saved me from quite a number of serious bugs - and also means I have old but working versions after the author decided to move some of the functionality into a payed version.

I notice CA also uses upgradepkg - but with --install-new so upgradepkg will just jump directly to installpkg - or exits if the new package file doesn't exist. <!-- The 'source' file. --> <FILE Name="/boot/config/plugins/&name;/&name;-&version;.txz" Run="upgradepkg --install-new"> <URL>https://raw.github.com/&github;/master/archive/&name;-&version;.txz</URL> <MD5>&md5;</MD5> </FILE> It seems the download manager doesn't continue if the download fails - so doesn't process the "Run" command. So neither installpkg or upgradepkg run. But the pre-install code in /boot/config/plugins/community.applications.plg performs file removal before the download of the new version. It is a bit confusing that the *.plg file is run and performs a cleanup before knowing the result of the download of the *.txz file. The plugin doesn't seem to have a chance to perform any cleanup when it knows if the new install will work or not. It would be better if the plugin performs the download without any Run command. Then based on the download result decides if any cleanup is needed before upgradepkg --install-new is run.

It sounds like you are saying that /sbin/upgradepkg is generally not used when updating plugins.

That mitigates the problem but doesn't solve it. A user may have that page open for quite some time before deciding to update plugins, in which case the version displayed may still differ from the latest version available on the server. Somewhere down-the-line, whatever script is used needs to verify that the new version is available before the uninstall happens. That's the only correct way of doing an update. I don't normally use slackware since a huge many years, but correct usage would be that the installpkg script is called with a package file as parameter - and that file is expected to exist. If installpkg is called without an existing script then it will exit. It's just that when updating a plugin, then installpkg is expected to be called from another script - updatepkg - that is responsible for removing unused code. And updatepkg itself verifies that it receives two package names - the old and the new. It really is irrelevant who have written the code - but down the line, installpkg should only be called if the package exists. And the contents of the previous package version should not be removed unless the system has the files for the new package. Does unRAID have a document showing the exact steps performed when a plugin is updated?

It may not be a bug in CA, but it is a bug for an update manager to uninstall a previous version before having successfully retrieved the new version. Your app should never have to bother if specifically version x exists on github. If it does, then the update should work. If it doesn't then the update should stop before the uninstall step, in which case there should be a chance for the system to continue to monitor github for yet newer versions. Your mobile phone would never uninstall the previous version before it has retrieved and validated a new version.

I haven't checked the specification of the UPS, but if the UPS has 650 in the name, then it's likely that 650 is the capacity in VA - not in W. So it's likely that both plugin shows the correct load values. One showing the load as 253 VA One showing the load as 203 W The VA value is almost always higher than the W value, because they can only be same for a perfectly resistive load.

Yes, after I had made my error report, I did pick up the git link from the first post of this thread and did a normal install. I just wanted to report that the app was able to uninstall before verifiying that it could download the newer version. But from what you are saying, this is a bug in unRAID itself that should be fixed - the new version should be downloaded with a temporary file name, and no uninstall should be allowed to happen until the new file has been downloaded ok.

Note that the parity doesn't have any file system, so no file system conversion for that drive.

I did an attempted update on jan 1st from version 2017.12.20 to 2017.12.31. I didn't notice exactly what it was writing on the first update attempt but it didn't perform any update. What it did was uninstall the previous version - I have no directory /usr/local/emhttp/plugins/community.applications The file /boot/config/plugins/community.applications.plg is for version 2017.12.20. If trying to press the update button again, it fails with: plugin: updating: community.applications.plg Cleaning Up Old Versions plugin: downloading: https://raw.github.com/Squidly271/community.applications/master/archive/community.applications-2017.12.31.txz ... failed (Invalid URL / Server error response) plugin: wget: https://raw.github.com/Squidly271/community.applications/master/archive/community.applications-2017.12.31.txz download failure (Invalid URL / Server error response) I didn't immediately noticed that I missed the application - I thought it was just a temporary issue with the repository. Then I noticed I no longer had the extra tab for applications. The log from my update attempt doesn't show anything special - I did try twice, and I'm pretty sure the popup dialog did show extra text the first time. Jan 1 05:45:21 n54l-3 emhttp: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin update community.applications.plg Jan 1 05:45:21 n54l-3 root: plugin: running: anonymous Jan 1 05:45:21 n54l-3 root: plugin: running: anonymous Jan 1 05:45:21 n54l-3 root: plugin: creating: /boot/config/plugins/community.applications/community.applications-2017.12.31.txz - downloading from URL https://raw.github.com/Squidly271/community.applications/master/archive/community.applications-2017.12.31.txz Jan 1 05:45:34 n54l-3 emhttp: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin update community.applications.plg Jan 1 05:45:34 n54l-3 root: plugin: running: anonymous Jan 1 05:45:34 n54l-3 root: plugin: running: anonymous Jan 1 05:45:34 n54l-3 root: plugin: creating: /boot/config/plugins/community.applications/community.applications-2017.12.31.txz - downloading from URL https://raw.github.com/Squidly271/community.applications/master/archive/community.applications-2017.12.31.txz Edit: Forgot to mention that I run 6.3.5.

Read slower or read twice. 1) Steam was an example. But there are no games you are interested in that you haven't gotten interested in because of some kind of reviews. And there are hundreds of sites that offers forums where people write their comments about games. 2) I didn't write anything about games offering test versions. But a whole world have managed quite well even without test versions because of the very ample amount of information available through your favorite search engine. 3) How you find the game? You find people with the same taste as you that writes reviews. Then you follow their reviews. You can't steal a book and read just to figure out if you are going to like the book - you either take a chance, or you do your due diligence. The seller has the right to upvote their products. The buyer has the right to vote with the wallet and not buy. But the buyer never has the right to steal. How do you think you buy paint for painting the house? By stealing one bucket of 10 different brands and test for a couple of years before deciding on buying? In the physical world, you'll have to do your due diligence. Same in the digital world.

Ever noticed review sites? Ever noted that Steam et al have a review function? No, you do not NEED to test before buying.

If you click on Tools/Diagnostics you can get a zip file with the SMART dump from every disk. You still get one file/disk, but it's quite quick to view the individual files. Just note that it is seldom the oldest disk that is the best to replace, since the drives are individuals and ages differently. So it's best to look at more than the number of power-on hours before making your decision.

There are often a number of SMART attributes that have threshold 0, which means the attribute will never be able to go below the threshold value and so will never be in a failing state. So these attributes will only be treated as indicators for an intelligent reader to ponder. Having a current pending sector is a warning - not a failure - for a disk. On one hand, it can be a physically damaged sector - which doesn't mean the disk will fail but that the specific sectors needs to be remapped with spare sectors. Or it can be a physically damaged head, meaning that the drive is permanently bad at reading and/or writing data. But it can also be a power issue etc that has nothing to do with the disk itself. Another thing is that the drive doesn't keep track of write times for the individual sectors. You know that you have recently written to every sector, which means that you know that 2560 offline uncorrectable is a extremely bad figure, because it means the recent fails did fail because head or surface is bad. The above is a reason why many SMART programs informs about changes - expecting the owner to react if some of these fields ticks up and to try to make an intelligent decision of what to do next.