itimpi

Is there any data on the drive you need to keep? If so first copy it to another location. Once that has been done you can go to Tools->New Config and select the option to retain the current assignments; After that go the Main tab and remove the drive. You can now start the array to rebuild parity from the remaking drives.

I am seeing it too when I looked closely enough (perhaps I need new glasses ). It is something that slipped past my radar and easily fixed. At one point I had some extra fields present on that screen to help with testing and left a tiny bit of text behind when I removed them.

Yes, that is the behaviour to expect. I have added a more detailed example to the first post in this thread to make that clearer. I will also add the example to the help text in the GUI when I update the plugin. It does rely on the fact that the interval between scheduled checks is long enough that the daily increnent size Is large enough to add up to enough time to complete one check before the next one is scheduled to start. I must admit I have not (yet anyway) tested what happens if this assumption is not true. I had assumed that people did not run scheduled parity checks too frequently because of both the length of time individual checks take and the load on the system while they are running. I think that the behaviour is likely to be that the check in progress simply continues instead of starting again from the beginning but this does need validating. If not the assumption needs to be clearly stated to stop people setting the increments to be too small.

I can see where you are coming from, but the exact rules you are looking for are not clear. I will have to put some thought into what appears to be some sensible rules for comment. Taking into account the cron schedule for mover is probably quite easy. However what if mover is triggered manually - should the parity check detect this and pause the parity check. What if the user starts both mover and parity check manually - what are the rules for determining who wins? Once a valid set of rules can be derived then I think something could be arranged. However I do not want to rush into something like this before the interactions have been thought out and how they will be resolved sorted out. As you will see from the first post there are already some new features I am working on. I will add this one to the "Wish List" section as I do not want to commit to doing it until I have a better understanding of exactly what it will entail. That means it will not get forgotten and there is time for for further thought.

I have copied this idea for detecting when Scheduled Parity checks are initiated. As you guessed it is the mdcmd command that needs wrapping/replacing. I have already reached the stage of detecting the automatic start of a parity check but still need to do more work to take advantage of this information.

You will need to post your system diagnostics zip file (obtained via Tools->Diagnostics) taken after the problem has occurred to help with diagnosing your issue. Since nobody else has reported seeing this it may well be something specific to your setup.

Thanks. I followed that blog post as it has nice detailed steps and have Dropbox functioning again on my Unraid server

Interesting! That suggests that another solution might work would be be to create a file on the array or cache, and then mount it as a loopback device and format that as EXT4. I might try that

As I understand it the hashes are stored in the files metadata within the file system when the hashes are built. The export copies this information to an external file.

I assume you are talking about the Min Free Space setting? If so this is only checked at the point the file is initially created and used to select a disk. There is no check that the file will not grow to use up all the free space, and then fail because it cannot get any more.

I suspect that you were not writing to the share (which would be done via the network), but instead had something running locally that by-passed the network shares and went in at the Linux level. If you were working at the metwork Level it is definitely a bug. If it was being done locally (as is often the case with plugins or dockers), then the application needs to handle this case correctly as a copy/delete operation).

If I remember correctly you need to have the array stopped; go to the Dockers page; and then turn on Advanced view. You should then be able to order docker startups and set delays

This is not something that Limetech can do anything about as it is behaviour built into Linux. The simple solution is to set the media share to Use Cache=Yes. Then mover will transfer the files to the array when it runs. Is there any reason that this will not meet your needs? The values for the Use Cache setting can be little confusing if you have not turned on the Help in the GUI to get a better description of how they work and affect mover.

If you have Use Cache=No then mover will never move files from the cache to the array (it needs to be set to “yes” for this to happen). The question is how they got there? One way is for an app running locally on the server that tries to do a ‘move’ (rather than a copy and then delete) of a file that is on the cache to a different share. One of the idiosyncrasies of the Linux ‘move’ operation is that Linux can first try a ‘rename’ (which is fast) and only if that fails does it do a copy/delete action. This can result in a file being moved to a folder that corresponds to a share with cache=No set.

Parity in Unraid is always real time so it does not matter when data is written (although writes can slow down the parity check). That is also true of the existing way parity checks run. if you do not want mover to run at the same time then you control that in the mover settings as they already have an option to not run if a parity check is running. This plugin is meant to run in conjunction with the existing Parity check settings, not replace them The existing settings control when a parity check is to be initiated. The settings for this plugin then determine how to split that check into increments to spread the check over a number of days to avoid impacting busy periods.

Parity Check Tuning plugin The Parity Check Tuning plugin is primarily designed to allow you to split a parity check into increments and then specify when those increments should be run. It will be of particular use to those who have large parity drives so that the parity check takes a long time and who leave their Unraid servers powered on 24x7. The idea is that you can specify time slots when the increments should be run and these can be chosen to be at times when the Unraid server is likely to be idle. The plugin also support running other long array operations (e.g. Clear, Rebuild) in increments if the user so desires. However since such operations are much rarer the user has to explicitly enable this in the plugin settings. Note that this plugin does not initiate a new parity check (or other array operation) - it only provides facilities for pausing/resuming/restarting them according to the criteria set in the plugin’s settings. If there is no array operation running during the timeslot specified for an increment then this plugin take no action. As an example on my system I have a 10TB Parity Disk and an uninterrupted Parity Check takes about 30 hours to complete. I have my normal scheduled parity checks set to run monthly. By using this plugin to run using 3 hour increments the elapsed time extends to 10 days (10 x 3 = 30) but I do not notice any impact on my normal use as the increments are run when I am not using the system. Once enough increments are run to complete the scheduled parity check then no further increments will be run until the time for the next scheduled check comes around. The plugin also allows other types of long-running array operations to be Paused or Resumed. These are Parity-Sync/Disk Rebuild and disk Clear operations. However since pausing these is less likely to be something the average user wants these can be individually controlled. For those who have problems with cooling on their Unraid systems it is also possible to set array operations to be Paused if the disks reach defined temperature thresholds and then Resumed when they cool down sufficiently. A much better solution is to have your Unraid system set up so that the cooling is sufficient to never let the disks overheat, but for some people this is not always practical. To avoid conflicts that can reduce overall performance you can set the plugin to automatically pause array operations if it detects that either the mover or the CA Backup processes are running and to then automatically resume the array operation when the process it question completes. The plugin will update the standard parity-check log to accurately reflect the duration and speed of parity checks to take into account that the check was run in increments as well as enhancing the information by also recording the number of increments, the total elapsed time and the type of check run. If you are running Unraid 6.9.0 (or later) array operations can be specified to be restated from the point they had reached at the point the reached when the system was shutdown or rebooted (or the array simply stopped/started) rather than from the beginning. This can be of particular use to those who do not want to keep their Unraid system powered on 24x7 (and power off overnight) as with modern large drives an array operation such as parity check can easily take more than 24 hours. The Settings page is added as an extra section to the Settings->Scheduler page (see the screenshot below) in the Unraid GUI as this seemed the most logical place for it to appear. Debug/Testing logging feature If you enable the option for debug logging then you will see additional entries appearing in the syslog about how this plugin is functioning internally. All these entries will include the word DEBUG so It is clear that they have been activated by turning on the Debug logging. This feature is primarily aimed at giving users a sense of what the plugin is doing under the covers for any users interested in such matters. In addition the logging level can be set to TESTING if trying to track down any suspected bugs in the plugin operation. This is primarily used during plugin development but can also help tracking down any issues that might be reported by users. It can be very verbose so users should not normally leave this option enabled. When this option is set to Testing then you are offered an additional option of Hourly for the frequency at which this plugin should pause/resume parity check increments. This was added primarily to help with testing and to help track down any issues that users might experience in using the plugin. Early feedback has suggested that users new to this plugin can use this feature as a way of getting a feel for how the plugin operates. Server Shutdown A feature has been included that allows users to set a temperature threshold for their array and cache drives that if exceeded will force the server to start its shutdown sequence. The prime Use Case for this is seen as protecting the disk drives in the event of the servers cooling failing for some reason. If activated this check runs even when there is no array or cache operation active. Command Line (CLI) options When this plugin is installed it adds the 'parity.check' command to the system which makes the following capabilities available from the command line: Usage: parity.check <action> where action is one of pause Pause a running parity check resume Resume a paused parity check check Start a parity check (as Settings->Scheduler) correct Start a correcting parity check nocorrect Start a non-correcting parity check status Show the status of a running parity check cancel Cancel a running parity check start Start the array stop Stop the array N Built-in Help The settings page for this plugin has very extensive built-in help to describe the meaning of the various settings. You can click on the description text for any particular setting to toggle it on-/off for that particular setting or you can turn it on/off at the page level by using the standard Help toggle in the Unraid GUI. Suggestions for improving the wording or expanding on the provided text are welcomed as it is not intended to produce any separate documentation. Parity Problems Assistant This is an additional option that appears under the Tools menu when the plug-in is installed. it implements Partial parity Checks which can be very helpful when trying to troubleshoot problems with parity after you have encountered errors when running the full parity check. It allows you to run a short check between specified start and end points. The current implementation is quite basic and feedback is welcomed on how it could be improved. Wish List This a holder for "blue sky" ideas that have been expressed for which there is no idea if it is even technically possible. They are kept here as a reminder and for others to perhaps expand on, and even perhaps come up with ideas for implementation.. Auto detect idle periods: The idea is that instead of the user having to specify specific start/stop times for running parity check increments the plugin should automatically detect periods when the system is idle to resume a parity check. This would need the complementary option of automatically detecting the system is no longer idle so that the check can be paused. Stop docker containers during a parity check. The ability to schedule the parity check to stop specified docker containers prior to check running and restart the docker containers after the check is paused or completed. A workaround for this would be to use the User Scripts plugin to do this although an integrated capability would be easier to use. Feedback Feedback from users on the facilities offered by this plugin is welcomed, and is likely to be used to guide the direction of any future enhancements. It will be interesting to hear how useful users find this plugin to be in the normal running of their system. Please feel free to suggest any changes that you think would enhance the experience even if it only rewording of text . Requirements Unraid 6.7.0 or later for the basic capability of running parity checks in increments. Unraid 6.9.0 or later for restarting array operations on next array start, and for using the Parity Problems assistant. Community Applications (CA) plugin. It is expected that this plugin will be installed via the Apps tab (i.e. the Community Applications plugin) and the appropriate template has been prepared to allow CA to handle it tidily. Installation The parity Check tuning plugin is available for installation by using the Community Applications plugin. If you navigate to the Apps tab and search for 'Parity Tuning' this plugin will show up and it can be installed from there. Once the plugin is installed then if you go to Settings->Scheduler in the Unraid GUI you will see an extra section has appeared that allows you to specify the settings you want to be used for this plugin.

Historically Unraid was run ‘headless’ administered from another machine/device. A GPU was then only required if the motherboard demanded it to boot successfully. The option to have the GUI Boot mode was added during v6 development due to popular demand but I think that the ‘headless’ mode is probably still the commonest way Unraid is run. There have been a number of reports that some motherboard/GPU combinations do not seem to run in GUI boot mode at optimum resolution. I know Limetech have been trying to reduce the incidence of this type of problem but it has definitely not been eradicated for everyone.

Does the update icon appear in XML mode if you refresh the screen? From your description it appears that it might! Just checking if it simply a case of forcing a refresh to get the browser to realise the icon has changed.

If you login and issue the ‘df’ command does it show anything mounted as /boot. If the boot process completed correctly this is where the flash drive should be mounted. If it is not being successfully mounted then it could explain your symptoms. If there is no /boot shown perhaps you can tell us more about how you prepared the flash drive; what make and model it is (USB2.0 drives seem to be more reliable); and whether you have it plugged into a USB2 or a USB3 port (again USB2 seems more reliable).

Technically USB 2.0 is not an absolute requirement. It is just that experience has shown that USB 2.0 seems to be far less likely to drop the flash drive offline unexpectedly.

That suggest that when doing the update the write to flash either failed or dropped offline. It would also explain why the parity check was instigated as if the disk state cannot be written to the flash after shutting down the array Unraid will think it was an unclean shutdown. You might want to try putting the flash drive into a Windows or Mac system and let it heck for corruption? If so make sure that it can be fixed just in case there is a real problem with the flash drive. Is the flash drive a USB2 one and do you use a USB2 port on your Unraid system? Just asking as using USB2 for both of those seems to be much less prone to unexpected errors. While plugged into your PC/Mac it would be a good idea to make sure you have a backup of the config folder? You then have the option of erasing the current flash drive, creating it as a new flash drive with the 6.6.7 release and then overwriting the config folder with your saved one to set back all your settings and your license key. Alternatively if you created a backup of the flash drive from the Unraid GUI you could use that.

I think that is normal due to UnRAID having to check the file does not already exist on another drive. Belonging to the share (although I could be wrong ) it is likely that using the Folder Caching plugin will help here. I know that recently some people have had problems with that plugin but it could well have been due to the same kernel bug that was causing these small writes? I guess we will have to see what others find out?

I do not think you can set the 'port' and 'websocket' to the same value. I always set the 'websocker' entry to a value in the 5700 range rather than the 5900 range and that seems to work fine. Cannot remember where I got the idea that the 'websocket' should be in that range

What browser are you using?

I would find this useful as well. Ideally there should then be a checkbox as to whether the original should be deleted or retained (although I personally would happy with the original being deleted).