From c0e8d43f68ee6e4a452da438302639fcdf8bc35f Mon Sep 17 00:00:00 2001 From: itimpi Date: Fri, 2 Apr 2021 14:13:20 +0100 Subject: [PATCH] Update paritychecktuning.txt updates for compatibility with latest version of Parity Check Tuning plugin --- Parity Check Tuning/paritychecktuning.txt | 244 ++++++++++++++++++---- 1 file changed, 208 insertions(+), 36 deletions(-) diff --git a/Parity Check Tuning/paritychecktuning.txt b/Parity Check Tuning/paritychecktuning.txt index 4510721..c5196ad 100644 --- a/Parity Check Tuning/paritychecktuning.txt +++ b/Parity Check Tuning/paritychecktuning.txt @@ -1,9 +1,13 @@ ; Translation text for the Parity Check Tuning plugin -; Page file prompts -below warning disk temperature= +; Parity Check Settihgs Page +automatic= +Basic= +below warning disk temperature threshold= +CAUTION= Click to show parity-check history= Data Rebuild= +Debug= Disk Clear= Donate to plugin author=DONATE entry in %s format= @@ -11,19 +15,20 @@ High disk temperatures can shutdown server= Increment frequency= Increment pause time= Increment resume time= -No +manual= ParityRead-Check History=Parity/Read-Check History= -Parity Check Tuning debug logging= -Parity Checks= +Parity Check= +Parity Check Tuning logging= Parity Sync= Pause an array operation at= Pause and Resume array operations if disks overheat= -Read Checks= +Read Check= Requires Unraid 67 or later=Requires Unraid 6.7 or later= Resume an array operation at= +Resume parity checks on next array start= Resume running Array operations on next array start= Run %s %s in increments= -Scheduled= +scheduled= Send notifications for Pause or Resume of increments= Send notifications for temperature related Pause or Resume= Shutdown server at= @@ -35,6 +40,26 @@ Use increments for Parity-SyncData Rebuild operations=Use increments for Parity- You require a parity disk present for this option to be relevant= Your Unraid release is too old to use this option= +; Parity Problems Assistant page + +The Parity Problems Assistant is part of the Parity Check Tuning plugin=The **Parity Problems Assistant** is part of the **Parity Check Tuning** plugin= +The current status is EXPERIMENTAL and it is always possible that this assistant may be removed in the future=The current status is **EXPERIMENTAL** and it is always possible that this assistant may be removed in the future +feedback is welcomed on the basic concept and ideas for improvement= +This assistant is intended to help pin down and resolve problems after a parity check has been run and errors have been reported= +The idea is that this assistant can be used after a parity check or read check has reported problems and logged the details of any problem sectors to the syslog= +In many cases such errors can be due to external factors such as cabling or the power supply rather than the actual disks= +If you think you have rectified whatever caused the problems to occur then you can use this assistant to run a partial check over a narrow range to see if the problem still occurs= +This can be much faster than having to run a full parity check or read check to see if you have resolved the issue or to run a disk extended SMART test to test the actual disk= +This assistant should never be used as an alternative to running a full parity check once you think the problem has been resolved= +End point for check= +Method used to specify start and stop points= +Percentage= +Sector Numbers= +Start Check= +Start point for check= +Write Corrections to Parity= + + ; PHP file messages Array being shutdown due to drive overheating= Array operation will not be restarted= @@ -45,9 +70,11 @@ Detected a change to the disk configuration= Drives cooled down= Elapsed Time= Following drives overheated= +IMPORTANT= Increments= Non-Correcting= Sent notification= +Shutdown= Starting Shutdown= Unclean shutdown detected= Unknown action= @@ -75,17 +102,20 @@ Scheduled pause= ; Swal warnings A crontab entry should have 5 space-separated values defining the minutes, hour, day of the month, month, day of the week= +At the moment there is no mechanism to stop this file from growing forever so it is up to you to manage this manually= Are you sure you have not got these the wrong way around= Before you can set this option to Yes you must first have enabled system notifications= Click on the crontab link to get more details on valid formats= -Debug mode can generate frequent additional entries in the syslog file so do not leave debug mode active if you are not interested in this information= +Debug mode can generate frequent additional log entries in the syslog file so do not leave debug mode active if you are not interested in this information= Debug mode is intended to give users a feel for when the plugin is active= +Do not leave this active if you are not interested in this information= Do you really want Debug logging mode= Do you really want Testing logging mode= +Do you really want to log to the flash drive= Do you really want this= Error in custom entry= extra time that will elapse before the system is once again in a protected state= -This might affect array integrity= +Logging to the flash drive can can cause a lot additional writes thus potentially shortening its lifetime) On most systems a disk Clear operation does not advesely affect performance so typically this option is left disabled= Error in custom entry= Notifications not enabled= @@ -93,14 +123,14 @@ On most systems a disk Clear operation does not advesely affect performance so t Only enable this option if the operation is adversely affecting system use and you are not worried about the extra time that will elapse before the system is once again in a protected state= Pause and Resume times= Pausing a disk Clear operation extends the time before the disk is successfully added to the array and becomes ready for formatting and then used for data storage= -Pausing an operation that is building parity or rebuilding a failed disk has a level of risk as your array is not back in a protected state until +Pausing an operation that is building parity or rebuilding a failed disk has a level of risk as your array is not back in a protected state until= Temperature Pause and Resume= The Resume value must be greater than the Pause one for the heat related Pause and Resume to work correctly as tney are both relative to the disk temperature warning value= This might affect array integrity= this operation completes successfully=Only enable this option if the operation is adversely affecting system use and you are not worried about the The Pause and Resume times would give an increment length of more than 12 hours which is unusual= Testing mode is normally only used by the plugin author or when gathering evidence of a suspected bug in the plugin= -Testing mode is very verbose and generates a lot of additional entries in the syslog file so you do not want it enabled unless this is really necessary= +Testing mode is very verbose and generates a lot of additional log entries so you do not want it enabled unless this is really necessary= Temperature Pause and Resume= The Resume value must be greater than the Pause one for the heat related Pause and Resume to work correctly as tney are both relative to the disk temperature warning value= @@ -139,11 +169,10 @@ hot= Loading progress file %s= No action specified= No array operation currently in progress= -no check in progress so no state saved= No cron events for this plugin are needed= No drives appear to have reached shutdown threshold= Not allowed as %s already running= -option not currently recognised= +Option not currently recognised= Parity check appears to be paused= Parity Check was in progress when array stopped at %s= Pause of= @@ -152,8 +181,6 @@ Removed existing state file %s= Resume request= so no further action to take= Temperature monitoring switched off= -to resume %s= -to pause %s= Unscheduled array operation in progress= using scheduled mode of %s= warm= @@ -165,7 +192,7 @@ with all drives below temperature threshold for a Pause= analyze previous progress before starting new one= Array not started so no action taken= Drive %s%s appears to be critical= -plugin temperature settings: pause %s, resume %s +Plugin temperature settings= shutdown %s= Shutdown not actioned as running in TESTING mode= updated cron settings are in %s= @@ -174,71 +201,216 @@ updated cron settings are in %s= ; These could perhaps be left in English to keep tranrlation task easier) :parity_tune_explain_plug: -> This main reason for this plugin is to allow you to limit parity checks to running at times that will not inconvenience you.
Setting this option to **Yes** specifies that parity checks should be run in increments spread over several days.

If you have set this to **No** then you get the default system behavior of parity checks running without a break to completion unless you manually stop/pause/cancel them.

As an example of what this plugin can do assume:
- You have a parity check you have scheduled to start on the first of every month at midnight
- Your past experience has shown that if the parity check runs uninterrupted it takes 30 hours to complete.
- You set this plugin to use 3 hour increments starting at midnight and finishing at 3.00 A.M.
- The parity check will now actually take 10 days elapsed time (10 x 3 = 30) so the parity check will complete on 10th of the month.
- You have scheduled these increments to run starting at midnight and finishing at 3:00 A.M. when you know the system is not being used.
- You are not worried about this increased elapsed time and will welcome the increased system responsiveness during normal use.
- The rest of the month this plugin will do nothing as there is no active parity check in progress when the start time for an increment comes around.

**CAUTION:** If the array is stopped while an array operation is incomplete then the progress so far is lost and it can only be restarted from the beginning +> The main purpose of this plugin is to allow you to limit array operations such as parity checks to running at times that will not inconvenience you. +> +>If you have set this to **No** then you get the default system behavior of parity checks running without a break to completion unless you manually stop/pause/cancel them. +> +>Setting this option to **Yes** specifies that parity checks should be run in increments spread over several days. +> As an example of what this plugin can do assume +>You have a parity check you have scheduled to start on the first of every month at midnight +>* Your past experience has shown that if the parity check runs uninterrupted it takes 30 hours to complete. +>* You set this plugin to use 3 hour increments starting at midnight and finishing at 3.00 A.M. +>* The parity check will now actually take 10 days elapsed time (10 x 3 = 30) so the parity check will complete on 10th of the month. +>* You have scheduled these increments to run starting at midnight and finishing at 3:00 A.M. when you know the system is not being used. +>* You are not worried about this increased elapsed time and will welcome the increased system responsiveness during normal use. +>* The rest of the month this plugin will do nothing as there is no active parity check in progress when the start time for an increment comes around. +> +>**CAUTION:** If the array is stopped while an array operation is incomplete then the progress so far is lost and it can only be restarted from the beginning +:end + +:parity_tune_increments_plug: +>Setting this option to **Yes** specifies that parity checks should be run in increments spread over several days. +> +>If you have set this to **No** then you get the default system behavior of parity checks running without a break to completion unless you manually stop/pause/cancel them. +> +>**CAUTION:** The default unRaid behaviour is that if the array is stopped while an array operation is incomplete then the progress so far is lost and it can only be restarted from the beginning. :end :parity_tune_frequency_plug: > The frequency at which parity check increments should be run.

In normal operation it is expected that the Daily option will be the one that most users will want to use so this is the default. To support any user looking for other frequencies there is the option to set up Custom schedules which will allow for more complicated schedules for the Pause and Resume times. When you use this option you are given the option to specify the time as used by the Linux crontab utility :end -:parity_tune_restart_plug: -> This is a place holder for a feature that cannot be implemented due to the lack of an ability to start a parity check at a defined offset, but the feature would be highly desirable. The plugin has been designed so that if/when Limetech provides a capability that allows this plugin to start a parity check at a defined offset then the feature can easily be implemented.

The idea behind the feature is that if a parity check was active (either running or paused) when the array is stopped then it would be restarted from the point it had reached when the array is restarted.

There would be some limitations around this
- The array must have been closed down tidily.
The user must not have made any changes to the array configuration +:parity_tune_manual_plug: +> Should parity checks that are started manually also be run in increments? +> +> It is quite likely that you will want such a check to run to completion without interruption and if so leave this option set to **No**. +> With this option set to **Yes** then if you manually start a Parity Check from the Main page and then manually Pause the check, this will result in the check being run in increments between the scheduled times until the Parity Check completes. +:end + +:parity_tune_automatic_plug: +> if the unRaid system is not shutdown cleanly then the next time the array is started unRaid will automatically start a non-correcting parity check (or a read check if you have no parity disk). This can happen for a wide variety of reasons ranging from power loss; hardware issues; and software issus. The automatic check is run because if there are any parity errors this can compromise the ability to recover from an array drive failure at a later date so you want to get back to having valid parity as soon as is practical. +> +> If this option is set then the check will be allowed to run for a few minutes (as any errors after an unclean sheutdown are most likely to be at the start of the disks as they were not unmounted cleanly) and then automatically put the check into a paused state (if outside the time specified for running increments) and then the remainder of the check subsequently run in increments according to the time slots specified for running increments. +:end + +:parity_tune_frequency_plug: +> The frequency at which parity check increments should be run. +> +>In normal operation it is expected that the **Daily** option will be the one that most users will want to use so this is the default. To support any user looking for other frequencies there is the option to set up **Custom** schedules which will allow for more complicated schedules for the Pause and Resume times. When you use this option you are given the option to specify the time as used by the Linux crontab utility. :end :parity_tune_resume_plug: -> The time at which a paused parity check should be resumed.
If no parity check is currently paused when this time comes around then no action will be taken.

Typically this time would be set to be the start of an idle period overnight. An appropriate value might be to use the same time that you have specified for a scheduled parity check to start.

If the increment period has been set to Custom then the hours/minutes fields are hidden and you are instead given the option to set the time in crontab format +> The time at which a paused parity check should be resumed.
If no parity check is currently paused when this time comes around then no action will be taken. +> +>Typically this time would be set to be the start of an idle period overnight. An appropriate value might be to use the same time that you have specified for a scheduled parity check to start. +> +>If the increment period has been set to **Custom** then the hours/minutes fields are hidden and you are instead given the option to set the time in crontab format. :end :parity_tune_pause_plug: -> The time at which a running parity check should be paused. Typically this would be set to be a time when you want other activity to not be affected by a running parity check.
If no parity check is actively running when this time comes around then no action will be.

Normally you want to make sure that this time is set to be after the time that you schedule regular parity checks to run. The first increment will then be from when the regular parity check is scheduled to start up to the time you have specified for the increment to end.

If the increment period has been set to Custom then the hours/minutes fields are hidden and you are instead given the option to set the time in crontab format.

You also want to make sure that the time allocated to running increments is sufficient to expect the parity check to run to completion before the next check is scheduled to start. Since most people only schedule parity checks to run infrequently (e.g. Monthly or Quarterly) then this is unlikely to be an issue but it is something to take into consideration +> The time at which a running parity check should be paused. Typically, this would be set to be a time when you want other activity to not be affected by a running parity check. +>If no parity check is actively running when this time comes around then no action will be. +> +>Normally you want to make sure that this time is set to be after the time that you schedule regular parity checks to run. The first increment will then be from when the regular parity check is scheduled to start up to the time you have specified for the increment to end. +> +>If the increment period has been set to **Custom** then the hours/minutes fields are hidden and you are instead given the option to set the time in crontab format. +> +>You also want to make sure that the time allocated to running increments is sufficient to expect the parity check to run to completion before the next check is scheduled to start. Since most people only schedule parity checks to run infrequently (e.g. Monthly or Quarterly) then this is unlikely to be an issue but it is something to take into consideration. :end -:parity_tune_unscheduled_plug: -> Should parity checks that are unscheduled also be run in increments?

The most likely scenario for this to occur is the case where an unclean shutdown has occurred and the system has therefore started an automatic parity check when the array is started. Another possibility is that you decided to manually start the parity check for some reason.

In both these case it is quite likely that you will want such a check to run to completion without interruption and if so leave this option set to No. If you instead set it to Yes then the increment schedule will be applied. After an unclean shutdown any parity errors are most likely to occur near the beginning of the disks so setting this option to Yes is normally reasonably safe as long as you do not mind that the check is likely to take much longer to complete.

TIP: With this option set to Yes then if you manually start a Parity Check from the Main page and then manually Pause the check, this will result in the check being run in increments between the scheduled times until the Parity Check complete +:parity_tune_notify_plug: +> Setting this option to Yes means that you will be sent a notification every time the plugin Pauses or Resumes an array operation. +>If you would rather not get such notifications then leave this option set to **No**. +>The notification is sent as a **Notice** category message to the targets specified under *Settings->Notification Settings*. :end :parity_tune_allops_plug: -> Should operations that involve building new parity or rebuilding a failed disk be run using increments?

This type of check will only be run if there is potentially some issue with your array and action is being taken to get it back into a protected state.

IMPORTANT: Until this operation completes your array is not fully protected so it is assumed that most people will want this option left at No. Do not select Yes unless you are absolutely certain that is what you want +> Should operations that involve building new parity or rebuilding a failed disk be run using increments? +> +>This type of check will only be run if there is potentially some issue with your array and action is being taken to get it back into a protected state. +> +>**IMPORTANT**: Until this operation completes your array is not fully protected so it is assumed that most people will want this option left at **No**. +> Do not select **Yes** unless you are absolutely certain that is what you want. :end + :parity_tune_clear_plug: -> Should disk Clear operations be run using increments.

A disk Clear operation occurs when you add a new drive (that has not been pre-cleared (using the Pre-Clear plugin) to an array that is parity protected. The Clear process writes zeroes to every sector on the new disk so that it can be added to the array without affecting the existing parity. Until the Clear operation has completed you are not able to format the disk in Unraid and start using it for storing data.

Since until the Clear operation completes the disk will not be available for use it is likely that most people will want this option left at No. In addition a Clear operation tends not to put much of a load on the system so is less likely to impact performance in normal daily use +> Should disk Clear operations be run using increments.

A disk Clear operation occurs when you add a new drive (that has not been pre-cleared (using the Pre-Clear plugin) to an array that is parity protected. The Clear process writes zeroes to every sector on the new disk so that it can be added to the array without affecting the existing parity. Until the Clear operation has completed you are not able to format the disk in Unraid and start using it for storing data. +> +>Since until the Clear operation completes the disk will not be available for use it is likely that most people will want this option left at **No**. In addition, a Clear operation tends not to put much of a load on the system so is less likely to impact performance in normal daily use. :end -:parity_tune_notify_plug: -> Setting this option to Yes means that you will be sent a notification every time the plugin Pauses or Resumes an array operation.
If you would rather not get such notifications then leave this option set to No.
The notification is sent as a Notice category message to the targets specified under Settings->Notification Settings +:parity_tune_restart_plug: +> Unraid will normally abandon a parity check if the sytem is shutdown, rebooted or the array is stopped (with the only option being to restart the parity check from the beginning). +> Setting this option allows parity checks to be restarted by this plugin from the point they had reached as long as the following criteria are met: +>* The array was shutdown tidily +>* The user must not have made any changes to the array configuration. +> +>As long as these criteria are met then when the array is next started the operation is resumed from the point previously reached. +> +>**NOTES:** +>* If the array operation was within the time set for a scheduled increment to be running then on restarting the array operation it will be set to be paused if now outside the time set for running increments. +>* If the array operation was manually paused then the restarted array operation will also be paused +>* If you want to use this feature by simply stopping the array without immediately using the **Reboot** or **Shutdown** buttons then you first need to manually **Pause** the array operation before using the **Stop** button. If you to this and successfully stop the array then the array operation will now be resumed if you simply **Start** the array again, and also on the next array start after **Reboot** or **Shutdown**. :end :parity_tune_restart_plug: -> Unraid will normally abandon an array operation (parity check. parity sync, disk rebuild, disk clear) if the array is stopped or ir the sytem is rebooted with the only option being to restart from the beginning. Setting this option allows such operations to be restarted from the point they had reached as long as the following criteria are met
- The array was shutdown tidily
- The user must not have made any changes to the array configuration.

As long as these criteria are met then when the array is started the operation is resumed from the point previously reached. +> Unraid will normally abandon a parity check if the sytem is shutdown, rebooted or the array is stopped (with the only option being to restart the parity check from the beginning). +> Setting this option allows parity checks to be restarted by this plugin from the point they had reached as long as the following criteria are met: +>* The array was shutdown tidily +>* The user must not have made any changes to the array configuration. +> +>As long as these criteria are met then when the array is next started the operation is resumed from the point previously reached. +> +>**NOTES:** +>* If the array operation was within the time set for a scheduled increment to be running then on restarting the array operation it will be set to be paused if now outside the time set for running increments. +>* If the array operation was manually paused then the restarted array operation will also be paused +>* If you want to use this feature by simply stopping the array without immediately using the **Reboot** or **Shutdown** buttons then you first need to manually **Pause** the array operation before using the **Stop** button. If you to this and successfully stop the array then the array operation will now be resumed if you simply **Start** the array again, and also on the next array start after **Reboot** or **Shutdown**. :end :parity_tune_hot_plug: -> Pause an array operation(Parity Check, Parity-Sync/Disk Rebuild, disk Clear) if the disk temperatures exceeds the limits you have set.

The temperatures are checked against the thresholds set for the Warning disk threshold levels. If a threshold has been defined for an individual drive (accessed by clicking on the drive in the Main tab) then this is the value used. If not the global setting (set via Settings->Display Settings) will be used.

A much better solution is to improve the cooling in your case so that the disks never overheat. In practise this may not always prove practical.

If the array operation was part of running an increment then it will not be resumed outside the time allotted for the increment. If the array operation was initiated for any other reason then the Pause/Resume behavior on temperature is always active +> Pause an array operation(Parity Check, Parity-Sync/Disk Rebuild, disk Clear) if the disk temperatures exceeds the limits you have set. +> +>The temperatures are checked against the thresholds set for the Warning disk temperature levels. If a threshold has been defined for an individual drive (accessed by clicking on the drive in the Main tab) then this is the value used. If not the global setting (set via *Settings->Display Settings*) will be used. +> +>A much better solution is to improve the cooling in your case so that the disks never overheat. In practise this may not always prove practical. +> +>If the array operation was part of running an increment then it will not be resumed outside the time allotted for the increment. If the array operation was initiated for any other reason then the Pause/Resume behavior on temperature is always active. :end :parity_tune_warn_plug: -> This value indicates how close to the value set for the Warning Disk Temperature Threshold a disks temperature is allowed to reach before a **pause** of a running array operation is triggered.
You normally want a small positive value to trigger the pause before Unraid gets around to sending you a notification that the temperature warning threshold has been reached for a disk.

If an explicit threshold has been defined for an individual drive then this is the value used. If not the global setting will be used.

If there is no active array operation then no action will be taken even if disk temperatures exceed the specified threshold.

If there is no running array operation then no action will be taken +> This value indicates how close to the value set for the Warning Disk Temperature Threshold a disks temperature is allowed to reach before a **pause** of a running array operation is triggered. +> You normally want a small positive value to trigger the pause before Unraid gets around to sending you a notification that the temperature warning threshold has been reached for a disk. +> +> If an explicit threshold has been defined for an individual drive then this is the value used. If not the global setting will be used. +> +>If there is no active array operation then no action will be taken even if disk temperatures exceed the specified threshold. +> +> If there is no running array operation then no action will be taken. :end :parity_tune_low_plug: -> This value indicates how much below the warning the temperature threshold of a drive must reach before a **resume** of an array operation is issued.
You need to get a good balance between array operations being resumed too soon (and thus quickly reaching the level to initiate another pause) and wasting a lot of time.

If a disk ever gets spun down the temperature is not readily available so it will be assumed that this criteria has been met

If there is no paused array operation then no action will be taken +> This value indicates how much below the Warning temperature threshold of a drive must reach before a **resume** of an array operation is issued. +>You need to get a good balance between array operations being resumed too soon (and thus quickly reaching the level to initiate another pause) and wasting a lot of time. +> +>If a disk ever gets spun down the temperature is not readily available so it will be assumed that this criteria has been met +> +>If there is no paused array operation then no action will be taken. :end :parity_tune_temp_notify_plug: -> Setting this option to **Yes** means that you will be sent a notification every time the plugin Pauses or Resumes an array operation due to the temperature of your drives.
If you would rather not get such notifications then leave this option set to **No**. The notification is sent as a **Notice**> category message to the targets specified under Settings->Notification Settings. +> Setting this option to **Yes** means that you will be sent a notification every time the plugin Pauses or Resumes an array operation due to the temperature of your drives.
If you would rather not get such notifications then leave this option set to **No**. The notification is sent as a **Notice** category message to the targets specified under *Settings->Notification Settings*. :end :parity_tune_shutdown_plug: -> If set to **Yes''** then automatically start a tidy shutdown of the server if any disk in the array or a cache pool reach the defined temperature threshold.
The temperatures are checked against the thresholds set for the **Critical** disk temperature levels. If a Critical temperature has been defined for an individual drive (accessed by clicking on the drive in the Main tab) then this is the value used. If not the global setting (set via Settings->Display Settings) will be used.

This option intended to be triggered if for some reason the system's cooling system is insufficient or if it has failed in some way. The idea is that you want to do a tidy shutdown before the disks become damaged due to overheating badly. The shutdown that is triggered is functionally the same as would be the case of pressing the Shutdown button on the Main page of the Unraid GUI. If notifications are enabled then you are sent one to indicate that this has happened.

When the server is started up again after such a shutdown then when the array is started you will be notified that a temperature related shutdown happened in case you were not aware of the reason.

**CAUTION:** If the array is stopped while an array operation is incomplete then the progress so far is lost and it can only be restarted from the beginning. +> If set to **Yes** then automatically start a tidy shutdown of the server if any disk in the array or a cache pool reach the defined temperature threshold. +> The temperatures are checked against the thresholds set for the **Critical** disk temperature levels. If a Critical temperature has been defined for an individual drive (accessed by clicking on the drive in the Main tab) then this is the value used. If not the global setting (*Settings->Display Settings) will be used. +> +>This option intended to be triggered if for some reason the system's cooling system is insufficient or if it has failed in some way. The idea is that you want to do a tidy shutdown before the disks become damaged due to overheating badly. The shutdown that is triggered is functionally the same as would be the case of pressing the Shutdown button on the Main page of the Unraid GUI. If notifications are enabled then you are sent one to indicate that this has happened. +> +>When the server is started up again after such a shutdown then when the array is started you will be notified that a temperature related shutdown happened in case you were not aware of the reason. +> +>**CAUTION:** If the array is stopped while an array operation is incomplete then the progress so far is lost and it can only be restarted from the beginning. :end :parity_tune_critical_plug: -> This value indicates how close to the value set for the Critical Disk Temperature Threshold a disks temperature is allowed to reach before a shutdown of the server is triggered.
You may want a small positive value to trigger the pause before Unraid gets around to sending you a notification that the temperature critical threshold has been reached for a disk.

If an explicit threshold has been defined for an individual drive then this is the value used. If not the global setting will be used. +> This value indicates how close to the value set for the Critical Disk Temperature Threshold a disks temperature is allowed to reach before a shutdown of the server is triggered. +> You may want a small positive value to trigger the pause before Unraid gets around to sending you a notification that the temperature critical threshold has been reached for a disk. +> +>If an explicit threshold has been defined for an individual drive then this is the value used. If not the global setting will be used. +:end + +:parity_tune_logging_plug: +> Control the level of detail in entries. The level of detail can be increased to help with debugging any problems using this plugin might encounter. +> +>Messages by this plugin are identified by the fact that they are shown as coming from +>* **Parity Check Tuning** +>* **Parity Problems Assistant** +>depending on which part of the plugin generated the messages +> +>With the **Basic** option set these will only be a small number of messages indicating that this plugin has taken some action. +> +>Setting this option to **Debug** will result in additional entries being written to the syslog that give more information on what is happening when this plugin is running. They show how some of the internal operation of how the plugin is functioning. These additional entries are identified by the fact that they will have the word **DEBUG** added to the start of messages. Some users (particularly those who have not used this plugin before) may like to use it to see more detail on how this plugin operates, but it is not expected that this option will be left enabled in normal running. +> +>Finally there is an additional setting of **Testing** that is only intended for use by the developer but is left here for convenience. It will write even more verbose messages to the syslog but these are not likely to be interesting (or even meaningful) to the average user. These messages will have the word **TESTING** added to the start of messages. You should only run this level of logging if you have been asked to as it can quickly fill up your syslog if you are not careful. +> +>Feedback is welcome as to whether it is worth introducing any intermediate option that outputs information type messages on the plugins activity, while omitting some of the lower level detail that is aimed at diagnosing any problems that might be encountered while the plugin is running. +> +>If you have Testing mode set for the logging then you can choose where you want log messages to be recorded. The default is the standard system syslog and this is the inly oti/n allowed in Basic mode. The syslog is held in RAM so does not cause excessive writes to the flash drive. +To facilitate with debugging problems then in Testing mode you can log the messages to the flash drive either instead of the syslog or in addition to the syslog. The resulting parityTuning.log file will be stored in the plugin's folder on the flzsh drive and providing this file to the developer will help with diagnosing any unexpected behaviour you encounter. +:end + +:parityProblems_type_plug: +> Select the way you want to specify the start and end points. +> +> You are likely to want to use absolute sector numbers if there are ones that have previously been listed in the syslog as being an error. +> Using absolute sector numbers tends to be more pecise and lead to shorter tests but can be more effort to set up. +> +> The alternative is to use percentages. When using percentages then the sector numbers these represent are calculated as percentages of the largest parity disk. +:end + +:parityProblems_start_plug: +> Select where you want the check to be started from. You can specify the start point as either a sector number or as a percentage of the size of the largest parity disk. +> +> Specifying absolute sectors is likely to be of particular use when you have extracted the sector numbers from the *syslog* when the original parity chesk reported errors on those sectors. In a future version of this plugin the plugin may be enhanced to automatically extract such sectors from the *syslog* and give you a drop down list but this feature is not yet implemented. +> +> In practice for technical reasons the check may start slighty earlier than the point you specify, but this will only be by a small amount. :end -:parity_tune_debug_plug: -> Write more verbose entries to the syslog file to help with debugging any problems using this plugin might encounter.

Messages written to the syslog by this plugin are identified by the fact that they are shown as coming from **Parity Check Tuning**. With the **Disabled** option set these will only be a small number of messages indicating that this plugin has taken some action.

Setting this option to **Enabled** will result in additional entries being written to the syslog that give more information on what is happening when this plugin is running. They show how some of the internal operation of how the plugin is functioning. These additional entries are identified by the fact that they will have the word **DEBUG** added to the start of messages. Some users (particularly those who have not used this plugin before) may like to use it to see more detail on how this plugin operates, but it is not expected that this option will be left enabled in normal running

Finally there is an additional setting of **Testing** that is only intended for use by the developer but is left here for convenience. It will write even more verbose messages to the syslog but these are not likely to be interesting (or even meaningful) to the average user. These messages will have the word **TESTING** added to the start of messages.

Feedback is welcome as to whether it is worth introducing any intermediate option that outputs information type messages on the plugins activity, while omitting some of the lower level detail that is aimed at diagnosing any problems that might be encountered while the plugin is running. +:parityProblems_end_plug: +> Select where you want the check to be ended. You can specify the start point as either a sector number or as a percentage of the size of the largest parity disk. +> +> In practice for technical reasons the check may end later than the point you specify as a check is only made once a minute to see if the end point has been reached. :end