itimpi

That is why I submitted as a ‘pull’ request to the Limetech wegui github repository rather than getting the plugin to try and patch the relevant file. Doing it that way as long as the ‘pull’ request is accepted by Limetech it will automatically be incorporated into the next Unraid build.

The change turned out to be trivial so I have sent a pull request on the Unraid webgui GitHub repository that will display something like the following when an operation is paused. I think this is a good solution that should work well?

Glad to here that it appears to be working as expected. i have raised a feature request to suggest that when a parity check is paused this is indicated in the Status line (I.e. the same message as when running but with ‘(paused)’ added on the end). That seems the right/best way to handle this and keeps the fact the operation is incomplete easily visible. I could look into doing it myself if nothing materialises but it might involve amending one of the main built-in Unraid scripts which I would rather not do as it might be prone to breaking things on an Unraid update which would be very bad news. If you think it would add value to add it to the Settings page that would be quite trivial to do. In fact in the early stages of the development of the plugin when I was trying to work out how to detect array status I actually had it there but thought it did not add much value so removed it to keep things cleaner.

This is not a problem but expected behaviour. The Stop button will be available once the BTRFS operation has completed. It has always been the case that long running operation did not allow you to stop the array. Having said that I cannot see anything in the log that mentions such an operation being started. Did you trigger this yourself or was it triggered automatically in some way?

You need to go (at the Unraid level) to Settings->Network Settings and Enable Bridging. The default name for the first bridge is br0 (although you can over-ride that if you want to.) Once you have done that if you scroll to the bottom of the page you will see the routing that has been set up for both virbr0 and br0. When you go back to the VM settings you should now be offered the choice of virbr0 and br0.

OK - that adapter is a NAT type connection allowing only outbound connections which will explain why you cannot ping or ssh to the VM. It also means that the virtio network drivers are required inside the VM - not sure if Ubuntu server includes them as standard although I would have though it did. If you want the VM to appear as if it were directly connected to the LAN then you need a bridged network (e.g. something like br0 rather than virbr0), but you first need to make sure that has been set up in the Unraid network settings. I also have no experience of editing networking files inside an Ubuntu VM. In my experience the network 'just worked' without me having to do anything. Someone else may be in a better position to help here.

You must have specified the type of network adapter (e.g virbr0). That will determine both what drivers are needed inside the VM and also whether is a NAT connection or not. If you are not sure you can look at the current network settings for the VM at the Unraid level. Alternatively provide the XML for the VM and we can see it from there.

What type of network connection did you specify when setting up the VM?

Looking at the link you gave I would have thought that —-device-write-bps /dev/mdX:10mb should work for disk X. Not sure how you would do it for a User Share as it seems to want a physical device. Maybe something like /dev/fuse?

That is strange - the URL I have is https://lime-technology.com/forums/topic/70783-parity-check-tuning/. Now that you mention it I agree that seems to be the wrong thread number, but not sure how that happened as I thought the URL was originally set up as a copy/paste. However looking at the gitHub commits it was always the value it currently is now in the PLG file. Maybe I am getting things confused with the change to the CA template (which has the correct URL). I tend to go via the Apps tab as it much faster to load than the Plugins one. I am actually surprised the URL went anywhere useful as the name part after the thread number is wrong but that is probably the forum software trying to be helpful in some way. Fair enough. Not sure if I want to bother but it is nice to know that is what is required (and I can add it to my development notes for future reference). I was more interested in the Donate button as a way to get feedback on interest in the plugin rather than any expectation of a significant amount being paid.

If necessary you can get Docker compose via the Nerdpack. However I agree it would be slicker if one could work out how to do it via CA without using compose. If you get that working make sure to keep notes on the steps as they can then probably easily be turned into CA templates for future users.

Great! I hope to push out an update over the weekend to clear up the little points you noted. I had some personal motivation for getting this plugin working :) . I have a slow server and a 12TB parity drive and my check can take up to 30 hours so running the check in increments is of great personal benefit. I always think that implementing something you are going to be using yourself tends to lead to a goid final result.

That is at least progress Hopefully you will like some of the changes. Please provide feedback on how well they work for you as I only have a limited testing environment so could easily have missed some edge cases. The saving grace is that if I have messed anything up it is unlikely to cause to much of an issue other than missing a Pause or getting an unexpected Resume. The plugin never installs any new system libraries or touches any user data so should not be dangerous even in a failure mode in the event one occurs. I get the same behaviour What is strange is that my browser (Microsoft Edge) clearly shows it pointing to the correct support thread. I cannot find any reference to Mover Tuning in any of my code or the templates that control installation. Also clicking on the Support link from the Apps tab ends up at the correct location. Not sure, therefore, where the incorrect link is coming from but as I can reproduce this I can at least work on tracking it down. I need to look at that further. The button seems to be appearing on the Apps tab but is then going to the wrong Donate page so something definitely needs looking at. Again I am not sure why. I thought the Donate button was auto-carried over from the Apps tab but I could be wrong about that and I need to do something explicit to get onto the Plugins page. Fixed for the next release! The problem was I was trying to specify an icon I though was available on UnRAID but turns out not to be the case. When testing the code I was by-passing the plugins tab so managed to miss that the icon was not correct. That will be a by-product of introducing the new features and changing the names of some of the variables used internally for storing settings so you reverted to the defaults. Should not happen again going forward. Trying to safely migrate the old settings looked a little error prone and so I thought that with this release users were likely to revisit the settings page and I could thus safely let affected settings revert to defaults.

1). The format is up to you. The Unassigned Devices plugin can handle all common formats. If you want to be able to easily read the drive on a Windows system go with NTFS, but otherwise XFS is a good choice. 2). You can share the whole drive as a single share. You cannot have folders on the drive as their own shares, and the drive will not be part of your User Shares. For your intended use this should be fine.

The version I have uploaded today is 2019.03.28. If you have it should look like the screenshot in the first post. My guess is that we have to wait for CA to see the update (unless I messed something up while uploading the update). What version does CA show as being available?

Update from rc5 to rc6 went smoothly and no anomalous behaviour noted so far after the upgrade.

I have released a new version of the plugin with a significant number of improvements and changes: Added new CA plugin update feature Improved GUI on Settings page with more extensive help and better checks on settings Added option to Pause/Resume array operations if disks overheat Added option to Pause/Resume of Parity-Sync/Disk Rebuild and disk Clear operations Added option to send notifications on Pause/Resume Added sending a notification if its detected the array was stopped while an array operation was in progress Added a Paypal donate option as a way of gauging interest in the plugin (be interesting to see if any actually happen!) . I will be particularly interested to see how the option for Pause /Resume on temperature thresholds works out in practice for those who have such a problem. I do not have such a problem and was only able to test this feature by setting my trigger temperatures to be much lower than required as in normal use my own Unraid systems do not suffer from the disks over-heating. I would also be interested in any feedback on how useful people are finding the plugins prime purpose of being able to run scheduled parity checks in increments. I have been assuming that 'no news' is good news in that users are not encountering any problems but some positive feedback would be encouraging.

There have been reports for some time about only being able to boot in GUI or non-GUI mode on some peoples systems, but I do not think anyone has tracked down the cause or even a clear pattern of when it occurs. Since you can boot in GUI mode I would suggest just setting that as the default. Booting into GUI mode will not be a problem even if normally running in 'headless' mode.

Exactly what mapping have you used for the Krusader container? In particular what access mode did you set up? It probably needs to be RW (slave).

You should always be able to get into the GUI via the network regardless of the boot mode. You can change the default boot mode by moving the ‘default’ entry into the appropriate section of the config/config.sys file. The easiest way is to click on the boot device on the Main tab in the Unraid GUI.

I suspect it is a limitation of the disk controller and how it is handled under Linux

Unfortunately not. I have designed the plugin so that if Limetech provide the required restart capability the plugin will be able to take advantage of it. Yes. This is something I am currently trying to implement. I am not sure how hard it is going to be to get it working well. The idea is that this would be a completely independent setting to the scheduled pause/resume capability that is already implemented so it would always apply to a parity check at any time regardless of how it was initiated once you have set the option to activate this.

Two points: - This plugin does not require a scheduled parity check to be running when the times for its increments to run come around. The parity check could have been started manually or for some other reason (such as an unclean shutdown). The increment pause/resume times do need to be scheduled. - Unraid does not (yet anyway) provide a mechanism that would allow partial parity checks to be run. Parity checks always start from the beginning. All this plugin does is allow a check to be stretched over days only running in scheduled idle periods (typically overnight). The plugin's current capabilities are therefore targeting those who leave their Unraid servers powered on overnight and have large enough parity drives that the check currently takes long enough that it impacts performance at times when the Unraid server is not going to be idle. The sort of capability I think you are asking for can only be implemented if/when Limetech provide a capability for parity checks to be started at a defined offset rather than only from the beginning.

Not quite sure what you are asking for here What are you thinking should be checked for? The plugin currently requires a parity check to be actively running (although it can be paused) before it gets involved

The idea of taking into account disk temperature is an interesting one, but how practical it might be I have no idea. I suspect it is one of those that sounds a good idea at first but then not too practical after all, and that the only real solution is to improve the cooling inside your server’s case. Partial paritcy checks is not a feature that can currently be implemented as there is no way to start except at the start. It will need Limetech to provide a way for developers to start a parity check at a defined offset to make it possible. Whether this will ever happen I have no idea.