pwm

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.

Problems with newly booted machines with lack of entropy for pseudo-random data, resulting in some part of the program hanging waiting for /dev/random to produce enough data?

The text "Pre-fail" and "Old age" are just descriptions of what the different attributes are measuring. Edit - notice that you also have a column "Failed". All your attributes have the value "Never". If you had seen a "Now" there, then you would have known that the disk considers that specific attribute to be currently failing. There are a few of the Raw values that you want to stay at zero permanently. You don't want Attribute 5 (Reallocated sector count), 196 (Reallocated event count), 197 (Current pending sector) or 198 (Offline uncorrectable) to tick up because then you have problems with the drive. And ifh 199 (UDMA CRC error count) is ticking up, then you have issues with the SATA cable or possibly with the electronics in the controller card or the disk. The disk itself gives an indication what it likes the different values based on the colum "Value". Compare this value with the other column "Threshold" - it's a failure for any attribute to have the "Value" drop down all the way to the "Threshold" value.

I have managed quite well to store DVD/BD ISO files to Reiserfs and fill to 99% on older 4 TB volumes. But the special case is that I have only accumulated new files - never erased any existing files. And the total number of files are very low since the ISO images are on average 8 GB for the DVD rips and 44 GB for the BD rips. I also have a few, very small, meta-data files for each rip, but still ends up with a multi-GB average file size. In the general case, 99% is much too high filling level for ReiserFS. RFS starts to spend significant time rebalancing the internal tree structures much earlier, so 90% should be a better general figure - especially if there are important real-time requirements. But just to reiterate: all file systems gets affected when nearly full. It's just a question of how early you start to see significant effects for a specific set of files. Some file systems suffers because the free-space management breaks down. Some, because the FS tries to balance the internal structures. If it's balancing operations that slows down, then it can work quite well to fill the FS to a high level since the rest of the file system life will be reads. But if it's the free-space management that breaks down, then even future reads are likely to become severely affected.

Different file systems behaves differently when nearly full. But in general, you should never fill a file system almost full unless it's an archival disk where you only write to it once and then leave it in that state with no more writes. An almost full disk has a very hard problem figuring out what free space to use for new writes with tends to result in very severe fragmentation. So you can get huge slowdowns accessing some of the files if you make use of all space for a partition. Note that some file systems can allocate a bit of extra space, speculatively, for some files just to allow them to be extended without additional fragments. If you then fill the disk full, then the file system may have to go back and try to get back these speculative allocations and take a huge number of small blocks to store the last files written.

It was unexpected that ps hung. Process hangs normally happens if accessing something protected by a lock that hasn't been released, but ps is normally quite nice about what data it goes hunting for. What arguments did you give to the ps command?

I have had issues where I close notifications and they instantly comes back. And if I close all, they instantly comes back. If I look on the flash drive, all are closed - the "unread" directory is empty and the notifications that comes back are in the "archive" directory. If I navigate to a different page on the unRAID web interface then the problem seems to go away. So it seems like the web interface may sometimes cache incorrect data.

How can this be the wrong board? 6.3.5 isn't pre-release anymore, and this isn't related to any specific plugin. More and more users will come running with this kind of problems where the unRAID and the unRAID shares aren't found since M$ is rolling out Windows 10 updates that has turned off support for SMBv1, so you basically need DNS support to locate other hosts on the local network. Or require that the local hosts file is updated with the IP/name of the missing unRAID machine.

WiFi is quite often fast enough, which is why lots of media players can be run over WiFi. And it allows a backup server to be placed in a room that doesn't have wired networking. The important thing is that different users have different usage cases and different needs.

Windows doesn't check if the USB is bootable - just if it (potentially after a file system repair) seems to be readable. So as @johnnie.black recommends - regenerate the flash drive or possibly replace it. But take care to make a copy of the configuration first.

One more wanting ISCSI.