paritychecktuning.txt

; Translation text for the Parity Check Tuning plugin

; PART 1 - text strings

; Parity Check Settings Page
; ~~~~~~~~~~~~~~~~~~~~~~~~~~
; (should be translated)

Parity Check Tuning=
Array operation completed=
automatic=
Basic=
below critical disk temperature threshold=
below warning disk temperature threshold=
CA Backup or Restore running=
CA Backup or Restore no longer running=
CAUTION=
Click to show Array Operations history=
Data Rebuild=
Debug=
Disk Clear=
Docker containers to be paused=
Donate to plugin author=DONATE
Drives been above resume temperature threshold for %s minutes=
entry in %s format=
; %s is always substituted with link to how 'crontab' entries are formatted
High disk temperatures can shutdown server=
Incompatible options=
Increment frequency=
Increment pause time=
Increment resume time=
Mover no longer running=
Mover running=
Need to check temperatures of spundown drives=
No array operation in progress=
No parity check entries found in syslog=
Outside times for increments so not resuming=
Parity Check=
Parity Check Tuning logging=
Parity Sync=
Pause an array operation at=
Pause and Resume array operations if disks overheat=
Pause array operations while appdata backup or restore running=
Pause array operations while mover running=
Pause Docker Containers while array operations running=
Read Check=
Requires Unraid 6103 or later=Requires Unraid 6.10.3 or later
Resume an array operation at=
Resume array operations on next array start=
Resume running Array operations on next array start=
Run %s %s in increments=
; First %s is type (e.g. manual, automatic)
; Second %s is operation type (e.g Parity-Check, Parity-Sync)
scheduled=
Send notifications for mover or backup running=
Send notifications for Pause or Resume of increments=
Send notifications for temperature related Pause or Resume=
Server will be shutdown when array operation completes=
Shutdown server at=
Shutdown server when array operation completes=
spundown=
Stop array issued via Command Line=
Start array issued via Command Line=
Syslog only=
Syslog and Flash=
Flash only=
This option is only available if Appdata BackupRestore v2 plugin installed=This option is only available if Appdata Backup/Restore v2 plugin installed
unknown=
Unscheduled=
Use increments for %s %s=
Use increments for Clear operations=
Use increments for Parity-SyncData Rebuild operations=Use increments for Parity-Sync/Data Rebuild operations
Version=
Waiting=
You require a parity disk present for this option to be relevant=

; Parity Problems Assistant page
; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
; (should be translated)

Parity Problems Assistant=
; page intro text
:parityProblems_intro_plug:
The **Parity Problems Assistant** is part of the **Parity Check Tuning** plugin.<p/>
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)**.<p/>
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.<p/>
It is also not uncommon, particularly on **Ryzen/ThreadRipper** based systems, to get random parity errors if the RAM is overclocked
(an XMP profile **is** an overclock),  
and the motherboard/CPU combination may also impose limits that are lower than the RAM is capable of supporting.<p/>
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.<p/>
**IMPORTANT**: This assistant should never be used as an alternative to running a full parity check once you think the problem has been resolved.
:end
; fields
Click to show Parity check entries from syslog=
End point for check=
Method used to specify start and stop points=
Only read checks can be performed=
percent=
Percentage=
sector=
Sector Numbers=
Show Sector Numbers=
Start Check=
Start point for check=
Write Corrections to Parity=

; Notifications
; ~~~~~~~~~~~~~
; (should be translated)

aborted due to Unclean shutdown=
array stopping so progress will be lost=
; The type of array operation (parity check, clear, rebuild) will be appended to the following text
Automatic Unraid=
Average Speed=
completed=
Correcting Parity Check=
detected=
Drives cooled down=
errors=
finished=
Increments=
NonCorrecting Parity Check=Non-Correcting Parity Check
normal=
Pause=
Paused=
Resume=
Resumed=
Runtime=
Scheduled pause=
; The next threeo are used to construct the notification message pointing to 
; Troubleshooting in online manual after an Unclean shutdown
See=
Troubleshooting=
section of the Unraid OS Manual in the online documetaion to get guidance on resolving this=
Unclean shutdown detected=
warning=
will be started=

; PHP file messages
; ~~~~~~~~~~~~~~~~~

Analyze results from an array operation=
Array being shutdown due to drive overheating=
Array operation will not be restarted=
Array operation restarted=
Array shutdown=
Cancel a running parity check=
Command Line was=
Correcting=
Detected a change to the disk configuration=
Drives cooled down=
Elapsed Time=
ERROR=
Following drives overheated=
IMPORTANT=
Increments=
Manually Paused=
Manually Resumed=
Non-Correcting=
Pause a running array operation=
Resume a paused array operation=
Sent notification=
Show the status of a running parity check=
Shutdown=
Shutdown aborted=
Start a correcting parity check=
Start a correcting parity check=
Start a parity check with scheduled settings=
Starting Shutdown=
Unknown action=
Unrecognized option=
Usage=
where action is one of=

; Swal warnings
; ~~~~~~~~~~~~~
; (these are popups from web page as a result of field validation)
; (translation optional)

A crontab entry should have 5 space-separated values defining the minutes, hour, day of the month, month, day of the week=
As a safety measure if you switch off this option while an array operation is running then the shutdown will be aborted=
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 these are the right 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 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=
Logging to the flash drive can cause a lot additional writes thus potentially shortening its lifetime=
No check is made to see if there is any other activity running on the server at the time the array operation completes=
Notifications not enabled=
On most systems a disk Clear operation does not adversely affect performance so typically this option is left disabled=
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=
Temperature Pause and Resume=
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 log entries so you do not want it enabled unless it is really necessary=
The Pause and Resume times cannot be identical=
The Pause and Resume times would give an increment length of more than 12 hours which is unusual=
The Resume value must be greater than the Pause one for the heat related Pause and Resume to work correctly as they are both subtracted from the disk temperature warning value when calculating the desired temperature=
The Unraid 'Cumulative parity Check' setting must be set to No if you want to use the Parity Check Tuning plugin to handle pause and resume of scheduled Parity Checks=
The value you have specified seems unusually large as it is not an absolute value but is relative to the value specified for the drives Temperature Warning level at the Unraid level=
This might affect array integrity=
Unusually large value=

; Syslog messages (with debug logging disabled)
; ~~~~~~~~~~~~~~~
; (translation optional)

%s Cancelled=
Array not started so no action taken=
as drives now cooled down=
Cancel automatically started array operation=
Following drives overheated=
Only able to start a Read-Check due to number of disabled drives=
to get ready for restart=

; Syslog messages (with debug logging enabled)
; ~~~~~~~~~~~~~~~
; (May not be worth translating these as they are mainly of use to the plugin developer)

appears to be a regular scheduled check=
%s cancel request sent %s=
already running=
array drives=
Array operation paused but drives not cooled enough to resume=
Array operation paused but not for temperature related reason=
Array stopping=
Array stopping while %s was in progress %s=
but no action currently taken on started event=
but no parity check was in progress when array stopped=
Cancel request=
Configuration=
cool=
Created cron entries for %s=
; where %s will be one of the following 4 values
default monitoring=
monitoring disk temperatures=
monitoring partial parity checks=
Detected that array has not yet been started=
Detected that array has just been started=
detected that mdcmd had been called from %s with command %s=
ERROR=
hot=
idle=
Loading progress file %s=
No action specified=
No array operation currently in progress=
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 recognized=
Parity check appears to be paused=
Parity Check was in progress when array stopped at %s=
Pause of=
PAUSED=
Pause request=
Removed existing state file %s=
Resume ignored as paused because background task running=
Resume request=
scheduled pause and resume=
so no further action to take=
Temperature monitoring switched off=
Unraid version %s is too old to support restart=
Unscheduled array operation in progress=
Updated cron settings are in %s=
using scheduled mode of %s=
Versions Unraid %s, Plugin %s=Versions: Unraid %s, Plugin %s
warm=
will not be restarted=
with all array drives below temperature threshold for a Pause=

; Syslog messages (with testing logging enabled)
; ~~~~~~~~~~~~~~~
; (almost certainly not worth translating these as they are mainly of use to the plugin developer)

analyze previous progress before starting new one=
Array not started so no action taken=
Drive %s%s appears to be critical=
Plugin temperature settings=
shutdown %s=
Shutdown not actioned as running in TESTING mode=
updated cron settings are in %s=

; PART 2 - TEXT Blocks and HELP text

End point for check=
Method used to specify start and stop points=

; Help text on settings page
; ~~~~~~~~~~~~~~~~~~~~~~~~~~
; These could perhaps be left in English to keep translation task easier)

:parity_tune_explain_plug:
> 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.  You can avoid this if you set the plugin option to resume array operations on next array start.
: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.
:end

:parity_tune_frequency_plug:
> The frequency at which parity check increments should be run.<br><br>In normal operation it is expected that the <strong>Daily</strong> 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 <strong>Custom</strong> 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 <a href="https://en.wikipedia.org/wiki/Cron#Overview" target="_blank">crontab</a> utility
:end

: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 issues. 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 shutdown 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 users 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 <a href="https://en.wikipedia.org/wiki/Cron#Overview"  target="_blank">crontab</a> utility.   
:end

:parity_tune_resume_plug:
> The time at which a paused parity check should be resumed.<br>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 <a href="https://en.wikipedia.org/wiki/Cron#Overview" target="_blank">crontab</a> 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 <a href="https://en.wikipedia.org/wiki/Cron#Overview" target="_blank">crontab</a> 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_notify_plug:
> Setting this option to <strong>Yes</strong> 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**.
>Notifications that are deemed to be just informative are sent as a **Normal** (green) category message to the targets specified under *<a href="Settings/Notifications">Settings->Notification Settings</a>*, although more important ones will use the **Warning** (orange) or *Error** (red) type notifications where it seems appropriate.
: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.
:end


:parity_tune_clear_plug:
> Should disk Clear operations be run using increments?<br><br>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_restart_plug:
> Unraid will normally abandon a parity check if the system is shutdown, rebooted, or the array is stopped (with the only option being to restart the parity check from the beginning).  
> Other array operations will be restarted 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  
:end

:parity_tune_mover_plug:
>Pause an array operation (Parity Check, Parity-Sync/Disk Rebuild, disk Clear) if mover is running. An array operation being run in parallel to mover adversely affects the performance due to contention on the disk drives so it is more efficient to not have them running at the same time.
> 
> This setting takes effect even if you are not using any of the options to run an array operation in increments.
> 
> If you are running the array operation type in increments then the resume will only happen after mover finishes if you are still within the time windows for the increment.
:end

:parity_tune_backup_plug:
>Pause an array operation (Parity Check, Read-Check, Parity-Sync,. Disk Rebuild, Disk Clear) if the CA Appdata or Appdata Backup plugins are running a backup or restore of docker container data.  An array operation being run in parallel to the backup or restore adversely affects the performance due to contention on the disk drives so it is more efficient to not have them running at the same time.
> 
> This setting takes effect even if you are not using any of the options to run an array operation in increments.
> 
>If you are running the array operation type in increments then the resume will only happen after the backup or restore finishes if you are still within the time windows for the increment.
:end

:parity_tune_background_plug:
> Setting this option to <strong>Yes</strong> means that you will be sent a notification every
> time a background task such as Appdata Backup or mover starts or completes. If this option
> is set then the notification is sent whenever these operations start or stop while an array
> operation is active even if you have not set the operation to be paused or resume while
> such tasks are running. This can be helpful to help see when the performance of the array
> operation is likely to be interacting badly with the background task in terms of performance.
>
>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 target(s) specified under *<a href="Settings/Notifications">Settings->Notification Settings</a>*.
: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 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. It is assumed that normally you would want the array operation to be paused before the value set at the Unraid level as the Warning Threshold.
>
>A much better solution is to improve the cooling in your case so that the disks never overheat. In practice 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. 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.
>
> 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.
>
> As an example if the Warning threshold for a drive is 50C then setting a pause value of 5 would cause the plugin to pause the operation if that drive reached 45C (50-5).
>
>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 temperature threshold of a drive must reach before a **resume** of an array operation is considered. If using increments has been set for the type of operation being performed then the time mest be within the increments window or the resume wil be deferred until that window is rezched.
>
>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.<br>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 target(s) specified under *<a href="Settings/Notifications">Settings->Notification Settings</a>*.
: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 pools 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 (*<a href="Settings/DisplaySettings">Settings->Display Settings</a>) will be used.
>
>This option is 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. 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 (unless you have enabled the restart option **and** the shutdown is a tidy shutdown).
:end

:parity_tune_critical_plug:
> This value indicates how close to the value set for the Critical Disk Temperature Threshold the temperature is of a disk 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_complete_plug:
> If set to **Yes** then automatically start a tidy shutdown of the server when the current array operation completes.
>
> This option is only likely to be of use on a server that is powered off most of the time as it is used for something like backup purposes. The idea is that you can initiate the array operation (either manually or via a schedule) and then leave the server to power itself down without having to know how long the array operation will take to complete.
>
> When it is detected that you have this option set and an array operation is in progress  then a notification is raised that the shutdown will happen. As a safety mesure if this option is initially set at the start of the array operation, but is unset before it finishes then the shutdown will be aborted.
>
>**CAUTION:** No check is made to see if there is any other activity running on the server at the time the array operation completes before the shutdown is initiated
: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 do so to help in debugging a problem you have reported 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 plugin's 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 only option 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 flash drive and providing this file to the developer will help with diagnosing any unexpected behaviour you encounter.
:end

:parity_tune_defaults_plug:
> The **Apply** button will save the currently displayed values of the settings.
>
> The **Done** button exits the settings page.
>
> The **Defaults** button will reset the plugin settings to the default values that are used when the plugin is first installed.
: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 precise 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 check 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 slightly earlier than the point you specify, but this will only be by a small amount.
:end

: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

:parityProblems_correct_plug:
> Specify whether you want to attempt to update parity to correct any error found,
> or just do a read test to see if any parity errors are reported.
:end

:parityProblems_correct_plug:
> Specify whether you want to attempt to update parity to correct any error found,
> or just do a read test to see if any parity errors are reported.
:end

:parityProblems_check_plug:
> When you click on **Check** then a partial check is initiated that
> will cover at least the start and end points that you have specified. It will be a correcting check
> if the option to **Write Corrections** is set to **Yes**, and a read-check otherwise.
> Note that this check will run for a minimum of 1 minute even if you specify a very small number of sectors to be checked.
:end

:parityProblems_sectors_plug:
> When you click on the option to **Show Sector Numbers** then the a dialog will be shown
> that extracts entries from the syslog that have shown any sectors for which any parity
> sector is displayed and whether the it was being corrected or is a parity error.
:end