Manual for SnapRAID.

There are also automatic translation to German, Spanish, French, Italian, Polish, Romanian.

1 Synopsis 

snapraid [-c, --conf CONFIG]
    [-f, --filter PATTERN] [-d, --filter-disk NAME]
    [-m, --filter-missing] [-e, --filter-error]
    [-a, --audit-only] [-h, --pre-hash] [-i, --import DIR]
    [-p, --plan PERC|bad|new|full]
    [-o, --older-than DAYS] [-l, --log FILE]
    [-s, --spin-down-on-error] [-w, --bw-limit RATE]
    [-Z, --force-zero] [-E, --force-empty]
    [-U, --force-uuid] [-D, --force-device]
    [-N, --force-nocopy] [-F, --force-full]
    [-R, --force-realloc]
    [-S, --start BLKSTART] [-B, --count BLKCOUNT]
    [-L, --error-limit NUMBER]
    [-A, --stats]
    [-v, --verbose] [-q, --quiet]
    status|smart|probe|up|down|diff|sync|scrub|fix|check
    |list|dup|pool|devices|touch|rehash


snapraid [-V, --version] [-H, --help] [-C, --gen-conf CONTENT]

2 Description

SnapRAID is a backup program designed for disk arrays, storing parity information for data recovery in the event of up to six disk failures.

Primarily intended for home media centers with large, infrequently changing files, SnapRAID offers several features:

For more information, please visit the official SnapRAID site: 

https://www.snapraid.it/

3 Limitations

SnapRAID is a hybrid between a RAID and a backup program, aiming to combine the best benefits of both. However, it has some limitations that you should consider before using it.

The main limitation is that if a disk fails and you haven't recently synced, you may not be able to fully recover. More specifically, you may be unable to recover up to the size of the changed or deleted files since the last sync operation. This occurs even if the changed or deleted files are not on the failed disk. This is why SnapRAID is better suited for data that rarely changes.

On the other hand, newly added files don't prevent recovery of already existing files. You will only lose the recently added files if they are on the failed disk.

Other SnapRAID limitations are:

4 Getting Started

To use SnapRAID, you need to first select one disk in your disk array to dedicate to `parity` information. With one disk for parity, you will be able to recover from a single disk failure, similar to RAID5.

If you want to recover from more disk failures, similar to RAID6, you must reserve additional disks for parity. Each additional parity disk allows recovery from one more disk failure.

As parity disks, you must pick the largest disks in the array, as the parity information may grow to the size of the largest data disk in the array.

These disks will be dedicated to storing the `parity` files. You should not store your data on them.

Then, you must define the `data` disks that you want to protect with SnapRAID. The protection is more effective if these disks contain data that rarely changes. For this reason, it's better to NOT include the Windows C:\ disk or the Unix /home, /var, and /tmp directories.

The list of files is saved in the `content` files, usually stored on the data, parity, or boot disks. This file contains the details of your backup, including all the checksums to verify its integrity. The `content` file is stored in multiple copies, and each copy must be on a different disk to ensure that, even in case of multiple disk failures, at least one copy is available.

For example, suppose you are interested in only one parity level of protection, and your disks are located at: 

/mnt/diskp <- selected disk for parity
/mnt/disk1 <- first disk to protect
/mnt/disk2 <- second disk to protect
/mnt/disk3 <- third disk to protect

You must create the configuration file /etc/snapraid.conf with the following options: 

parity /mnt/diskp/snapraid.parity
content /var/snapraid/snapraid.content
content /mnt/disk1/snapraid.content
content /mnt/disk2/snapraid.content
data d1 /mnt/disk1/
data d2 /mnt/disk2/
data d3 /mnt/disk3/

If you are on Windows, you should use the Windows path format, with drive letters and backslashes instead of slashes. 

parity E:\snapraid.parity
content C:\snapraid\snapraid.content
content F:\array\snapraid.content
content G:\array\snapraid.content
data d1 F:\array\
data d2 G:\array\
data d3 H:\array\

If you have many disks and run out of drive letters, you can mount disks directly in subfolders. See: 

https://www.google.com/search?q=Windows+mount+point

At this point, you are ready to run the `sync` command to build the parity information. 

snapraid sync

This process may take several hours the first time, depending on the size of the data already present on the disks. If the disks are empty, the process is immediate.

You can stop it at any time by pressing Ctrl+C, and at the next run, it will resume where it was interrupted.

When this command completes, your data is SAFE.

Now you can start using your array as you like and periodically update the parity information by running the `sync` command.

4.1 Scrubbing

To periodically check the data and parity for errors, you can run the `scrub` command. 

snapraid scrub

This command compares the data in your array with the hash computed during the `sync` command to verify integrity.

Each run of the command checks approximately 8% of the array, excluding data already scrubbed in the previous 10 days. You can use the -p, --plan option to specify a different amount and the -o, --older-than option to specify a different age in days. For example, to check 5% of the array for blocks older than 20 days, use: 

snapraid -p 5 -o 20 scrub

If silent or input/output errors are found during the process, the corresponding blocks are marked as bad in the `content` file and listed in the `status` command. 

snapraid status

To fix them, you can use the `fix` command, filtering for bad blocks with the -e, --filter-error option: 

snapraid -e fix

At the next `scrub`, the errors will disappear from the `status` report if they are truly fixed. To make it faster, you can use -p bad to scrub only blocks marked as bad. 

snapraid -p bad scrub

Running `scrub` on an unsynced array may report errors caused by removed or modified files. These errors are reported in the `scrub` output, but the related blocks are not marked as bad.

4.2 Pooling

Note: The pooling feature described below has been superseded by the mergefs tool, which is now the recommended option for Linux users in the SnapRAID community. Mergefs provides a more flexible and efficient way to pool multiple drives into a single unified mount point, allowing seamless access to files across your array without relying on symbolic links. It integrates well with SnapRAID for parity protection and is commonly used in setups like OpenMediaVault (OMV) or custom NAS configurations.

To have all the files in your array shown in the same directory tree, you can enable the `pooling` feature. It creates a read-only virtual view of all the files in your array using symbolic links.

You can configure the `pooling` directory in the configuration file with: 

pool /pool

or, if you are on Windows, with: 

pool C:\pool

and then run the `pool` command to create or update the virtual view. 

snapraid pool

If you are using a Unix platform and want to share this directory over the network to either Windows or Unix machines, you should add the following options to your /etc/samba/smb.conf: 

# In the global section of smb.conf
unix extensions = no


# In the share section of smb.conf
[pool]
comment = Pool
path = /pool
read only = yes
guest ok = yes
wide links = yes
follow symlinks = yes

In Windows, sharing symbolic links over a network requires clients to resolve them remotely. To enable this, besides sharing the pool directory, you must also share all the disks independently, using the disk names defined in the configuration file as share points. You must also specify in the `share` option of the configuration file the Windows UNC path that remote clients need to use to access these shared disks.

For example, operating from a server named `darkstar`, you can use the options: 

data d1 F:\array\
data d2 G:\array\
data d3 H:\array\
pool C:\pool
share \\darkstar

and share the following directories over the network: 

\\darkstar\pool -> C:\pool
\\darkstar\d1 -> F:\array
\\darkstar\d2 -> G:\array
\\darkstar\d3 -> H:\array

to allow remote clients to access all the files at \\darkstar\pool.

You may also need to configure remote clients to enable access to remote symlinks with the command: 

fsutil behavior set SymlinkEvaluation L2L:1 R2R:1 L2R:1 R2L:1

4.3 Undeleting

SnapRAID functions more like a backup program than a RAID system, and it can be used to restore or undelete files to their previous state using the -f, --filter option: 

snapraid fix -f FILE

or for a directory: 

snapraid fix -f DIR/

You can also use it to recover only accidentally deleted files inside a directory using the -m, --filter-missing option, which restores only missing files, leaving all others untouched. 

snapraid fix -m -f DIR/

Or to recover all the deleted files on all drives with: 

snapraid fix -m

4.4 Recovering

The worst has happened, and you have lost one or more disks!

DO NOT PANIC! You will be able to recover them!

The first thing you must do is avoid further changes to your disk array. Disable any remote connections to it and any scheduled processes, including any scheduled SnapRAID nightly sync or scrub.

Then proceed with the following steps.

4.4.1 STEP 1 -> Reconfigure

You need some space to recover, ideally on additional spare disks, but an external USB disk or remote disk will suffice.

Modify the SnapRAID configuration file to make the `data` or `parity` option of the failed disk point to a location with enough empty space to recover the files.

For example, if disk `d1` has failed, change from: 

data d1 /mnt/disk1/

to: 

data d1 /mnt/new_spare_disk/

If the disk to recover is a parity disk, update the appropriate `parity` option. If you have multiple failed disks, update all their configuration options.

4.4.2 STEP 2 -> Fix

Run the fix command, storing the log in an external file with: 

snapraid -d NAME -l fix.log fix

Where NAME is the name of the disk, such as `d1` in our previous example. If the disk to recover is a parity disk, use the names `parity`, `2-parity`, etc. If you have multiple failed disks, use multiple -d options to specify all of them.

This command will take a long time.

Ensure you have a few gigabytes free to store the fix.log file. Run it from a disk with sufficient free space.

Now you have recovered all that is recoverable. If some files are partially or totally unrecoverable, they will be renamed by adding the `.unrecoverable` extension.

You can find a detailed list of all unrecoverable blocks in the fix.log file by checking all lines starting with `unrecoverable:`.

If you are not satisfied with the recovery, you can retry it as many times as you wish.

For example, if you have removed files from the array after the last `sync`, this may result in some files not being recovered. In this case, you can retry the `fix` using the -i, --import option, specifying where these files are now to include them again in the recovery process.

If you are satisfied with the recovery, you can proceed further, but note that after syncing, you cannot retry the `fix` command anymore!

4.4.3 STEP 3 -> Check

As a cautious check, you can now run a `check` command to ensure that everything is correct on the recovered disk. 

snapraid -d NAME -a check

Where NAME is the name of the disk, such as `d1` in our previous example.

The -d and -a options tell SnapRAID to check only the specified disk and ignore all parity data.

This command will take a long time, but if you are not overly cautious, you can skip it.

4.4.4 STEP 4 -> Sync

Run the `sync` command to resynchronize the array with the new disk. 

snapraid sync

If everything is recovered, this command is immediate.

5 Commands

SnapRAID provides a few simple commands that allow you to:

Commands must be written in lowercase.

5.1 status

Prints a summary of the state of the disk array.

It includes information about parity fragmentation, how old the blocks are without checking, and all recorded silent errors encountered while scrubbing.

The information presented refers to the latest time you ran `sync`. Later modifications are not taken into account.

If bad blocks were detected, their block numbers are listed. To fix them, you can use the `fix -e` command.

It also shows a graph representing the last time each block was scrubbed or synced. Scrubbed blocks are shown with '*', blocks synced but not yet scrubbed with 'o'.

Nothing is modified.

5.2 smart

Prints a SMART report of all the disks in the system.

It includes an estimation of the probability of failure in the next year, allowing you to plan maintenance replacements of disks that show suspicious attributes.

This probability estimation is obtained by correlating the SMART attributes of the disks with the Backblaze data available at: 

https://www.backblaze.com/hard-drive-test-data.html

If SMART reports that a disk is failing, `FAIL` or `PREFAIL` is printed for that disk, and SnapRAID returns with an error. In this case, immediate replacement of the disk is highly recommended.

Other possible status strings are:

logfail In the past, some attributes were lower than the threshold.
logerr The device error log contains errors.
selferr The device self-test log contains errors.

If the -v, --verbose option is specified, a deeper statistical analysis is provided. This analysis can help you decide if you need more or less parity.

This command uses the `smartctl` tool and is equivalent to running `smartctl -a` on all devices.

If your devices are not auto-detected correctly, you can specify a custom command using the `smartctl` option in the configuration file.

Nothing is modified.

5.3 probe

Prints the POWER state of all disks in the system.

`Standby` means the disk is not spinning. `Active` means the disk is spinning.

This command uses the `smartctl` tool and is equivalent to running `smartctl -n standby -i` on all devices.

If your devices are not auto-detected correctly, you can specify a custom command using the `smartctl` option in the configuration file.

Nothing is modified.

5.4 up

Spins up all the disks of the array.

You can spin up only specific disks using the -d, --filter-disk option.

Spinning up all the disks at the same time requires a lot of power. Ensure that your power supply can sustain it.

Nothing is modified.

5.5 down

Spins down all the disks of the array.

This command uses the `smartctl` tool and is equivalent to running `smartctl -s standby,now` on all devices.

You can spin down only specific disks using the -d, --filter-disk option.

To automatically spin down on error, you can use the -s, --spin-down-on-error option with any other command, which is equivalent to running `down` manually when an error occurs.

Nothing is modified.

5.6 diff

Lists all the files modified since the last `sync` that need to have their parity data recomputed.

This command doesn't check the file data, but only the file timestamp, size, and inode.

After listing all changed files, a summary of the changes is presented, grouped by:

equal Files unchanged from before.
added Files added that were not present before.
removed Files removed.
updated Files with a different size or timestamp, meaning they were modified.
moved Files moved to a different directory on the same disk. They are identified by having the same name, size, timestamp, and inode, but a different directory.
copied Files copied on the same or a different disk. Note that if they are truly moved to a different disk, they will also be counted in `removed`. They are identified by having the same name, size, and timestamp. If the sub-second timestamp is zero, the full path must match, not just the name.
restored Files with a different inode but matching name, size, and timestamp. These are usually files restored after being deleted.

If a `sync` is required, the process return code is 2, instead of the default 0. The return code 1 is used for a generic error condition.

Nothing is modified.

5.7 sync

Updates the parity information. All modified files in the disk array are read, and the corresponding parity data is updated.

You can stop this process at any time by pressing Ctrl+C, without losing the work already done. At the next run, the `sync` process will resume where it was interrupted.

If silent or input/output errors are found during the process, the corresponding blocks are marked as bad.

Files are identified by path and/or inode and checked by size and timestamp. If the file size or timestamp differs, the parity data is recomputed for the entire file. If the file is moved or renamed on the same disk, keeping the same inode, the parity is not recomputed. If the file is moved to another disk, the parity is recomputed, but the previously computed hash information is retained.

The `content` and `parity` files are modified if necessary. The files in the array are NOT modified.

5.8 scrub

Scrubs the array, checking for silent or input/output errors in data and parity disks.

Each invocation checks approximately 8% of the array, excluding data already scrubbed in the last 10 days. This means that scrubbing once a week ensures every bit of data is checked at least once every three months.

You can define a different scrub plan or amount using the -p, --plan option, which accepts: bad - Scrub blocks marked bad. new - Scrub just-synced blocks not yet scrubbed. full - Scrub everything. 0-100 - Scrub the specified percentage of blocks.

If you specify a percentage amount, you can also use the -o, --older-than option to define how old the block should be. The oldest blocks are scrubbed first, ensuring an optimal check. If you want to scrub only the just-synced blocks not yet scrubbed, use the `-p new` option.

To get details of the scrub status, use the `status` command.

For any silent or input/output error found, the corresponding blocks are marked as bad in the `content` file. These bad blocks are listed in `status` and can be fixed with `fix -e`. After the fix, at the next scrub, they will be rechecked, and if found corrected, the bad mark will be removed. To scrub only the bad blocks, you can use the `scrub -p bad` command.

It's recommended to run `scrub` only on a synced array to avoid reported errors caused by unsynced data. These errors are recognized as not being silent errors, and the blocks are not marked as bad, but such errors are reported in the output of the command.

The `content` file is modified to update the time of the last check for each block and to mark bad blocks. The `parity` files are NOT modified. The files in the array are NOT modified.

5.9 fix

Fixes all the files and the parity data.

All files and parity data are compared with the snapshot state saved in the last `sync`. If a difference is found, it is reverted to the stored snapshot.

WARNING! The `fix` command does not differentiate between errors and intentional modifications. It unconditionally reverts the file state to the last `sync`.

If no other option is specified, the entire array is processed. Use the filter options to select a subset of files or disks to operate on.

To fix only the blocks marked bad during `sync` and `scrub`, use the -e, --filter-error option. Unlike other filter options, this one applies fixes only to files that are unchanged since the latest `sync`.

SnapRAID renames all files that cannot be fixed by adding the `.unrecoverable` extension.

Before fixing, the entire array is scanned to find any files moved since the last `sync` operation. These files are identified by their timestamp, ignoring their name and directory, and are used in the recovery process if necessary. If you moved some of them outside the array, you can use the -i, --import option to specify additional directories to scan.

Files are identified only by path, not by inode.

The `content` file is NOT modified. The `parity` files are modified if necessary. The files in the array are modified if necessary.

5.10 check

Verifies all the files and the parity data.

It works like `fix`, but it only simulates a recovery and no changes are written to the array.

This command is primarily intended for manual verification, such as after a recovery process or in other special conditions. For periodic and scheduled checks, use `scrub`.

If you use the -a, --audit-only option, only the file data is checked, and the parity data is ignored for a faster run.

Files are identified only by path, not by inode.

Nothing is modified.

5.11 list

Lists all the files contained in the array at the time of the last `sync`.

With -v or --verbose, the subsecond time is also shown.

Nothing is modified.

5.12 dup

Lists all duplicate files. Two files are assumed equal if their hashes match. The file data is not read; only the precomputed hashes are used.

Nothing is modified.

5.13 pool

Creates or updates a virtual view of all the files in your disk array in the `pooling` directory.

The files are not copied but linked using symbolic links.

When updating, all existing symbolic links and empty subdirectories are deleted and replaced with the new view of the array. Any other regular files are left in place.

Nothing is modified outside the pool directory.

5.14 devices

Prints the low-level devices used by the array.

This command displays the device associations in the array and is mainly intended as a script interface.

The first two columns are the low-level device ID and path. The next two columns are the high-level device ID and path. The last column is the disk name in the array.

In most cases, you have one low-level device for each disk in the array, but in some more complex configurations, you may have multiple low-level devices used by a single disk in the array.

Nothing is modified.

5.15 touch

Sets an arbitrary sub-second timestamp for all files that have it set to zero.

This improves SnapRAID's ability to recognize moved and copied files, as it makes the timestamp almost unique, reducing possible duplicates.

More specifically, if the sub-second timestamp is not zero, a moved or copied file is identified as such if it matches the name, size, and timestamp. If the sub-second timestamp is zero, it is considered a copy only if the full path, size, and timestamp all match.

The second-precision timestamp is not modified, so all the dates and times of your files will be preserved.

5.16 rehash

Schedules a rehash of the entire array.

This command changes the hash kind used, typically when upgrading from a 32-bit system to a 64-bit one, to switch from MurmurHash3 to the faster SpookyHash.

If you are already using the optimal hash, this command does nothing and informs you that no action is needed.

The rehash is not performed immediately but takes place progressively during `sync` and `scrub`.

You can check the rehash state using `status`.

During the rehash, SnapRAID maintains full functionality, with the only exception that `dup` cannot detect duplicated files using a different hash.

6 Options

SnapRAID provides the following options:
-c, --conf CONFIG
Selects the configuration file to use. If not specified, in Unix it uses the file `/usr/local/etc/snapraid.conf` if it exists, otherwise `/etc/snapraid.conf`. In Windows, it uses the file `snapraid.conf` in the same directory as `snapraid.exe`.
-f, --filter PATTERN
Filters the files to process in `check` and `fix`. Only the files matching the specified pattern are processed. This option can be used multiple times. See the PATTERN section for more details on pattern specifications. In Unix, ensure globbing characters are quoted if used. This option can be used only with `check` and `fix`. It cannot be used with `sync` and `scrub`, as they always process the entire array.
-d, --filter-disk NAME
Filters the disks to process in `check`, `fix`, `up`, and `down`. You must specify a disk name as defined in the configuration file. You can also specify parity disks with the names: `parity`, `2-parity`, `3-parity`, etc., to limit operations to a specific parity disk. If you combine multiple --filter, --filter-disk, and --filter-missing options, only files matching all the filters are selected. This option can be used multiple times. This option can be used only with `check`, `fix`, `up`, and `down`. It cannot be used with `sync` and `scrub`, as they always process the entire array.
-m, --filter-missing
Filters the files to process in `check` and `fix`. Only the files missing or deleted from the array are processed. When used with `fix`, this acts as an `undelete` command. If you combine multiple --filter, --filter-disk, and --filter-missing options, only files matching all the filters are selected. This option can be used only with `check` and `fix`. It cannot be used with `sync` and `scrub`, as they always process the entire array.
-e, --filter-error
Processes the files with errors in `check` and `fix`. It processes only files that have blocks marked with silent or input/output errors during `sync` and `scrub`, as listed in `status`. This option can be used only with `check` and `fix`.
-p, --plan PERC|bad|new|full
Selects the scrub plan. If PERC is a numeric value from 0 to 100, it is interpreted as the percentage of blocks to scrub. Instead of a percentage, you can specify a plan: `bad` scrubs bad blocks, `new` scrubs blocks not yet scrubbed, and `full` scrubs everything. This option can be used only with `scrub`.
-o, --older-than DAYS
Selects the oldest part of the array to process in `scrub`. DAYS is the minimum age in days for a block to be scrubbed; the default is 10. Blocks marked as bad are always scrubbed regardless of this option. This option can be used only with `scrub`.
-a, --audit-only
In `check`, verifies the hash of the files without checking the parity data. If you are interested only in checking the file data, this option can significantly speed up the checking process. This option can be used only with `check`.
-h, --pre-hash
In `sync`, runs a preliminary hashing phase of all new data for additional verification before the parity computation. Usually, in `sync`, no preliminary hashing is done, and the new data is hashed just before the parity computation when it is read for the first time. This process occurs when the system is under heavy load, with all disks spinning and a busy CPU. This is an extreme condition for the machine, and if it has a latent hardware problem, silent errors may go undetected because the data is not yet hashed. To avoid this risk, you can enable the `pre-hash` mode to have all the data read twice to ensure its integrity. This option also verifies files moved within the array to ensure the move operation was successful and, if necessary, allows you to run a fix operation before proceeding. This option can be used only with `sync`.
-i, --import DIR
Imports from the specified directory any files deleted from the array after the last `sync`. If you still have such files, they can be used by `check` and `fix` to improve the recovery process. The files are read, including in subdirectories, and are identified regardless of their name. This option can be used only with `check` and `fix`.
-s, --spin-down-on-error
On any error, spins down all managed disks before exiting with a non-zero status code. This prevents the drives from remaining active and spinning after an aborted operation, helping to avoid unnecessary heat buildup and power consumption. Use this option to ensure disks are safely stopped even when a command fails.
-w, --bw-limit RATE
Applies a global bandwidth limit for all disks. The RATE is the number of bytes per second. You can specify a multiplier such as K, M, or G (e.g., --bw-limit 1G).
-A, --stats
Enables an extended status view that shows additional information. The screen displays two graphs: The first graph shows the number of buffered stripes for each disk, along with the file path of the file currently being accessed on that disk. Typically, the slowest disk will have no buffer available, which determines the maximum achievable bandwidth. The second graph shows the percentage of time spent waiting over the past 100 seconds. The slowest disk is expected to cause most of the wait time, while other disks should have little or no wait time because they can use their buffered stripes. This graph also shows the time spent waiting for hash calculations and RAID computations. All computations run in parallel with disk operations. Therefore, as long as there is measurable wait time for at least one disk, it indicates that the CPU is fast enough to keep up with the workload.
-Z, --force-zero
Forces the insecure operation of syncing a file with zero size that was previously non-zero. If SnapRAID detects such a condition, it stops proceeding unless you specify this option. This allows you to easily detect when, after a system crash, some accessed files were truncated. This is a possible condition in Linux with the ext3/ext4 file systems. This option can be used only with `sync`.
-E, --force-empty
Forces the insecure operation of syncing a disk with all the original files missing. If SnapRAID detects that all the files originally present on the disk are missing or rewritten, it stops proceeding unless you specify this option. This allows you to easily detect when a data file system is not mounted. This option can be used only with `sync`.
-U, --force-uuid
Forces the insecure operation of syncing, checking, and fixing with disks that have changed their UUID. If SnapRAID detects that some disks have changed UUID, it stops proceeding unless you specify this option. This allows you to detect when your disks are mounted at the wrong mount points. It is, however, allowed to have a single UUID change with single parity, and more with multiple parity, because this is the normal case when replacing disks after a recovery. This option can be used only with `sync`, `check`, or `fix`.
-D, --force-device
Forces the insecure operation of fixing with inaccessible disks or with disks on the same physical device. For example, if you lost two data disks and have a spare disk to recover only the first one, you can ignore the second inaccessible disk. Or, if you want to recover a disk in the free space left on an already used disk, sharing the same physical device. This option can be used only with `fix`.
-N, --force-nocopy
In `sync`, `check`, and `fix`, disables the copy detection heuristic. Without this option, SnapRAID assumes that files with the same attributes, such as name, size, and timestamp, are copies with the same data. This allows identification of copied or moved files from one disk to another and reuses the already computed hash information to detect silent errors or to recover missing files. In some rare cases, this behavior may result in false positives or a slow process due to many hash verifications, and this option allows you to resolve such issues. This option can be used only with `sync`, `check`, and `fix`.
-F, --force-full
In `sync`, forces a full recomputation of the parity. This option can be used when you add a new parity level or if you reverted to an old content file using more recent parity data. Instead of recreating the parity from scratch, this allows you to reuse the hashes present in the content file to validate data and maintain data protection during the `sync` process using the existing parity data. This option can be used only with `sync`.
-R, --force-realloc
In `sync`, forces a full reallocation of files and rebuild of the parity. This option can be used to completely reallocate all files, removing fragmentation, while reusing the hashes present in the content file to validate data. This option can be used only with `sync`. WARNING! This option is for experts only, and it is highly recommended not to use it. You DO NOT have data protection during the `sync` operation.
-l, --log FILE
Writes a detailed log to the specified file. If this option is not specified, unexpected errors are printed to the screen, potentially resulting in excessive output in case of many errors. When -l, --log is specified, only fatal errors that cause SnapRAID to stop are printed to the screen. If the path starts with '>>', the file is opened in append mode. Occurrences of '%D' and '%T' in the name are replaced with the date and time in the format YYYYMMDD and HHMMSS. In Windows batch files, you must double the '%' character, e.g., result-%%D.log. To use '>>', you must enclose the name in quotes, e.g., `">>result.log"`. To output the log to standard output or standard error, you can use `">&1"` and `">&2"`, respectively. See the snapraid_log.txt file or man page for log tag descriptions.
-L, --error-limit NUMBER
Sets a new error limit before stopping execution. By default, SnapRAID stops if it encounters more than 100 input/output errors, indicating that a disk is likely failing. This option affects `sync` and `scrub`, which are allowed to continue after the first set of disk errors to try to complete their operations. However, `check` and `fix` always stop at the first error.
-S, --start BLKSTART
Starts processing from the specified block number. This can be useful for retrying to check or fix specific blocks in case of a damaged disk. This option is mainly for advanced manual recovery.
-B, --count BLKCOUNT
Processes only the specified number of blocks. This option is mainly for advanced manual recovery.
-C, --gen-conf CONTENT
Generates a dummy configuration file from an existing content file. The configuration file is written to standard output and does not overwrite an existing one. This configuration file also contains the information needed to reconstruct the disk mount points in case you lose the entire system.
-v, --verbose
Prints more information to the screen. If specified once, it prints excluded files and additional statistics. This option has no effect on the log files.
-q, --quiet
Prints less information to the screen. If specified once, it removes the progress bar; twice, the running operations; three times, the info messages; four times, the status messages. Fatal errors are always printed to the screen. This option has no effect on the log files.
-H, --help
Prints a short help screen.
-V, --version
Prints the program version.

7 Configuration

SnapRAID requires a configuration file to know where your disk array is located and where to store the parity information.

In Unix, it uses the file `/usr/local/etc/snapraid.conf` if it exists, otherwise `/etc/snapraid.conf`. In Windows, it uses the file `snapraid.conf` in the same directory as `snapraid.exe`.

It must contain the following options (case-sensitive):

7.1 parity FILE [,FILE] ...

Defines the files to use to store the parity information. The parity enables protection from a single disk failure, similar to RAID5.

You can specify multiple files, which must be on different disks. When a file cannot grow anymore, the next one is used. The total space available must be at least as large as the largest data disk in the array.

You can add additional parity files later, but you cannot reorder or remove them.

Keeping the parity disks reserved for parity ensures that they do not become fragmented, improving performance.

In Windows, 256 MB is left unused on each disk to avoid the warning about full disks.

This option is mandatory and can be used only once.

7.2 (2,3,4,5,6)-parity FILE [,FILE] ...

Defines the files to use to store extra parity information.

For each parity level specified, one additional level of protection is enabled:

Each parity level requires the presence of all previous parity levels.

The same considerations as for the 'parity' option apply.

These options are optional and can be used only once.

7.3 z-parity FILE [,FILE] ...

Defines an alternate file and format to store triple parity.

This option is an alternative to '3-parity', primarily intended for low-end CPUs like ARM or AMD Phenom, Athlon, and Opteron that do not support the SSSE3 instruction set. In such cases, it provides better performance.

This format is similar to but faster than the one used by ZFS RAIDZ3. Like ZFS, it does not work beyond triple parity.

When using '3-parity', you will be warned if it is recommended to use the 'z-parity' format for performance improvement.

It is possible to convert from one format to another by adjusting the configuration file with the desired z-parity or 3-parity file and using 'fix' to recreate it.

7.4 content FILE

Defines the file to use to store the list and checksums of all the files present in your disk array.

It can be placed on a disk used for data, parity, or any other disk available. If you use a data disk, this file is automatically excluded from the `sync` process.

This option is mandatory and can be used multiple times to save multiple copies of the same file.

You must store at least one copy for each parity disk used plus one. Using additional copies does not hurt.

7.5 data NAME DIR

Defines the name and mount point of the data disks in the array. NAME is used to identify the disk and must be unique. DIR is the mount point of the disk in the file system.

You can change the mount point as needed, as long as you keep the NAME fixed.

You should use one option for each data disk in the array.

You can rename a disk later by changing the NAME directly in the configuration file and then running a 'sync' command. In the case of renaming, the association is done using the stored UUID of the disks.

7.6 nohidden

Excludes all hidden files and directories. In Unix, hidden files are those starting with `.`. In Windows, they are those with the hidden attribute.

7.7 exclude/include PATTERN

Defines the file or directory patterns to exclude or include in the sync process. All patterns are processed in the specified order.

If the first pattern that matches is an `exclude` one, the file is excluded. If it is an `include` one, the file is included. If no pattern matches, the file is excluded if the last pattern specified is an `include`, or included if the last pattern specified is an `exclude`.

See the PATTERN section for more details on pattern specifications.

This option can be used multiple times.

7.8 blocksize SIZE_IN_KIBIBYTES

Defines the basic block size in kibibytes for the parity. One kibibyte is 1024 bytes.

The default blocksize is 256, which should work for most cases.

WARNING! This option is for experts only, and it is highly recommended not to change this value. To change this value in the future, you will need to recreate the entire parity!

A reason to use a different blocksize is if you have many small files, on the order of millions.

For each file, even if only a few bytes, an entire block of parity is allocated, and with many files, this may result in significant unused parity space. When you completely fill the parity disk, you are not allowed to add more files to the data disks. However, the wasted parity does not accumulate across data disks. Wasted space resulting from a high number of files on a data disk limits only the amount of data on that data disk, not others.

As an approximation, you can assume that half of the block size is wasted for each file. For example, with 100,000 files and a 256 KiB block size, you will waste 12.8 GB of parity, which may result in 12.8 GB less space available on the data disk.

You can check the amount of wasted space on each disk using `status`. This is the amount of space you must leave free on the data disks or use for files not included in the array. If this value is negative, it means you are close to filling the parity, and it represents the space you can still waste.

To avoid this issue, you can use a larger partition for parity. For example, if the parity partition is 12.8 GB larger than the data disks, you have enough extra space to handle up to 100,000 files on each data disk without any wasted space.

A trick to get a larger parity partition in Linux is to format it with the command: 

mkfs.ext4 -m 0 -T largefile4 DEVICE

This results in about 1.5% extra space, approximately 60 GB for a 4 TB disk, which allows about 460,000 files on each data disk without any wasted space.

7.9 hashsize SIZE_IN_BYTES

Defines the hash size in bytes for the saved blocks.

The default hashsize is 16 bytes (128 bits), which should work for most cases.

WARNING! This option is for experts only, and it is highly recommended not to change this value. To change this value in the future, you will need to recreate the entire parity!

A reason to use a different hashsize is if your system has limited memory. As a rule of thumb, SnapRAID typically requires 1 GiB of RAM for each 16 TB of data in the array.

Specifically, to store the hashes of the data, SnapRAID requires approximately TS*(1+HS)/BS bytes of RAM, where TS is the total size in bytes of your disk array, BS is the block size in bytes, and HS is the hash size in bytes.

For example, with 8 disks of 4 TB, a block size of 256 KiB (1 KiB = 1024 bytes), and a hash size of 16, you get: 

RAM = (8 * 4 * 10^12) * (1+16) / (256 * 2^10) = 1.93 GiB

Switching to a hash size of 8, you get: 

RAM = (8 * 4 * 10^12) * (1+8) / (256 * 2^10) = 1.02 GiB

Switching to a block size of 512, you get: 

RAM = (8 * 4 * 10^12) * (1+16) / (512 * 2^10) = 0.96 GiB

Switching to both a hash size of 8 and a block size of 512, you get: 

RAM = (8 * 4 * 10^12) * (1+8) / (512 * 2^10) = 0.51 GiB

7.10 autosave SIZE_IN_GIGABYTES

Automatically saves the state when syncing or scrubbing after the specified amount of GB processed. This option is useful to avoid restarting long `sync` commands from scratch if interrupted by a machine crash or any other event.

7.11 temp_limit TEMPERATURE_CELSIUS

Sets the maximum allowed disk temperature in Celsius. When specified, SnapRAID periodically checks the temperature of all disks using the smartctl tool. The current disk temperatures are displayed while SnapRAID is operating. If any disk exceeds this limit, all operations stop, and the disks are spun down (put into standby) for the duration defined by the `temp_sleep` option. After the sleep period, operations resume, potentially pausing again if the temperature limit is reached once more.

During operation, SnapRAID also analyzes the heating curve of each disk and estimates the long-term steady temperature they are expected to reach if activity continues. The estimation is performed only after the disk temperature has increased four times, ensuring that enough data points are available to establish a reliable trend. This predicted steady temperature is shown in parentheses next to the current value and helps assess whether the system's cooling is adequate. This estimated temperature is for informational purposes only and has no effect on the behavior of SnapRAID. The program's actions are based solely on the actual measured disk temperatures.

To perform this analysis, SnapRAID needs a reference for the system temperature. It first attempts to read it from available hardware sensors. If no system sensor can be accessed, it uses the lowest disk temperature measured at the start of the run as a fallback reference.

Normally, SnapRAID shows only the temperature of the hottest disk. To display the temperature of all disks, use the -A or --stats option.

7.12 temp_sleep TIME_IN_MINUTES

Sets the standby time, in minutes, when the temperature limit is reached. During this period, the disks remain spun down. The default is 5 minutes.

7.13 pool DIR

Defines the pooling directory where the virtual view of the disk array is created using the `pool` command.

The directory must already exist.

7.14 share UNC_DIR

Defines the Windows UNC path required to access the disks remotely.

If this option is specified, the symbolic links created in the pool directory use this UNC path to access the disks. Without this option, the symbolic links generated use only local paths, which does not allow sharing the pool directory over the network.

The symbolic links are formed using the specified UNC path, adding the disk name as specified in the `data` option, and finally adding the file directory and name.

This option is required only for Windows.

7.15 smartctl DISK/PARITY OPTIONS...

Defines custom smartctl options to obtain the SMART attributes for each disk. This may be required for RAID controllers and some USB disks that cannot be auto-detected. The %s placeholder is replaced by the device name, but it is optional for fixed devices like RAID controllers.

DISK is the same disk name specified in the `data` option. PARITY is one of the parity names: `parity`, `2-parity`, `3-parity`, `4-parity`, `5-parity`, `6-parity`, or `z-parity`.

In the specified OPTIONS, the `%s` string is replaced by the device name. For RAID controllers, the device is likely fixed, and you may not need to use `%s`.

Refer to the smartmontools documentation for possible options: 

https://www.smartmontools.org/wiki/Supported_RAID-Controllers
https://www.smartmontools.org/wiki/Supported_USB-Devices

For example: 

smartctl parity -d sat %s

7.16 smartignore DISK/PARITY ATTR [ATTR...]

Ignores the specified SMART attribute when computing the probability of disk failure. This option is useful if a disk reports unusual or misleading values for a particular attribute.

DISK is the same disk name specified in the `data` option. PARITY is one of the parity names: `parity`, `2-parity`, `3-parity`, `4-parity`, `5-parity`, `6-parity`, or `z-parity`. The special value * can be used to ignore the attribute on all disks.

For example, to ignore the `Current Pending Sector Count` attribute on all disks: 

smartignore * 197

To ignore it only on the first parity disk: 

smartignore parity 197

7.17 Examples

An example of a typical configuration for Unix is: 

parity /mnt/diskp/snapraid.parity
content /mnt/diskp/snapraid.content
content /var/snapraid/snapraid.content
data d1 /mnt/disk1/
data d2 /mnt/disk2/
data d3 /mnt/disk3/
exclude /lost+found/
exclude /tmp/
smartctl d1 -d sat %s
smartctl d2 -d usbjmicron %s
smartctl parity -d areca,1/1 /dev/sg0
smartctl 2-parity -d areca,2/1 /dev/sg0

An example of a typical configuration for Windows is: 

parity E:\snapraid.parity
content E:\snapraid.content
content C:\snapraid\snapraid.content
data d1 G:\array\
data d2 H:\array\
data d3 I:\array\
exclude Thumbs.db
exclude \$RECYCLE.BIN
exclude \System Volume Information
smartctl d1 -d sat %s
smartctl d2 -d usbjmicron %s
smartctl parity -d areca,1/1 /dev/arcmsr0
smartctl 2-parity -d areca,2/1 /dev/arcmsr0

8 Pattern

Patterns are used to select a subset of files to exclude or include in the process.

There are four different types of patterns:

FILE
Selects any file named FILE. You can use any globbing characters like * and ?, and character classes like [a-z]. This pattern applies only to files, not directories.
DIR/
Selects any directory named DIR and everything inside. You can use any globbing characters like * and ?. This pattern applies only to directories, not files.
/PATH/FILE
Selects the exact specified file path. You can use any globbing characters like * and ?, but they never match a directory slash. This pattern applies only to files, not directories.
/PATH/DIR/
Selects the exact specified directory path and everything inside. You can use any globbing characters like * and ?, but they never match a directory slash. This pattern applies only to directories, not files.

When you specify an absolute path starting with /, it is applied at the array root directory, not the local file system root directory.

In Windows, you can use the backslash \ instead of the forward slash /. Windows system directories, junctions, mount points, and other Windows special directories are treated as files, meaning that to exclude them, you must use a file rule, not a directory one.

If the file name contains a '*', '?', '[', or ']' character, you must escape it to avoid having it interpreted as a globbing character. In Unix, the escape character is '\'; in Windows, it is '^'. When the pattern is on the command line, you must double the escape character to avoid having it interpreted by the command shell.

In the configuration file, you can use different strategies to filter the files to process. The simplest approach is to use only `exclude` rules to remove all the files and directories you do not want to process. For example: 

# Excludes any file named `*.unrecoverable`
exclude *.unrecoverable
# Excludes the root directory `/lost+found`
exclude /lost+found/
# Excludes any subdirectory named `tmp`
exclude tmp/

The opposite approach is to define only the files you want to process, using only `include` rules. For example: 

# Includes only some directories
include /movies/
include /musics/
include /pictures/

The final approach is to mix `exclude` and `include` rules. In this case, the order of rules is important. Earlier rules take precedence over later ones. To simplify, you can list all the `exclude` rules first and then all the `include` rules. For example: 

# Excludes any file named `*.unrecoverable`
exclude *.unrecoverable
# Excludes any subdirectory named `tmp`
exclude tmp/
# Includes only some directories
include /movies/
include /musics/
include /pictures/

On the command line, using the -f option, you can only use `include` patterns. For example: 

# Checks only the .mp3 files.
# In Unix, use quotes to avoid globbing expansion by the shell.
snapraid -f "*.mp3" check

In Unix, when using globbing characters on the command line, you must quote them to prevent the shell from expanding them.

9 Content

SnapRAID stores the list and checksums of your files in the content file.

It is a binary file that lists all the files present in your disk array, along with all the checksums to verify their integrity.

This file is read and written by the `sync` and `scrub` commands and read by the `fix`, `check`, and `status` commands.

10 Parity

SnapRAID stores the parity information of your array in the parity files.

These are binary files containing the computed parity of all the blocks defined in the `content` file.

These files are read and written by the `sync` and `fix` commands and only read by the `scrub` and `check` commands.

11 Encoding

SnapRAID in Unix ignores any encoding. It reads and stores the file names with the same encoding used by the file system.

In Windows, all names read from the file system are converted and processed in UTF-8 format.

To have file names printed correctly, you must set the Windows console to UTF-8 mode with the command `chcp 65001` and use a TrueType font like `Lucida Console` as the console font. This affects only the printed file names; if you redirect the console output to a file, the resulting file is always in UTF-8 format.

Log manual for SnapRAID.

1 Description

This document describes the structured log tags output by SnapRAID, which are designed to be used by tools monitoring the SnapRAID processing state. The tags provide information in an easy-to-parse format, ideal for automation and integration.

To capture these structured log tags, you must use the `--log` option with SnapRAID.

You can direct the output to a specific file, or force the output to the standard output or standard error using the special arguments `>&1` or `>&2`. Note that these arguments often need to be quoted on the command line to prevent the shell from interpreting them.

Example: 

snapraid status --log ">&2"

The output tags strictly adhere to the following format: 

NAME:VALUE:VALUE:VALUE...<EOL>
NAME
This is the primary tag identifier, always a lowercase string without spaces (e.g., `summary`, `block`, `info_time`).
VALUE
Following the `NAME`, these can be additional sub-identifiers, descriptive names (like a disk name), or numeric/string data values. They are separated by a colon `:`.
<EOL>
Each tag is terminated by an end-of-line character.

This document provides a summary of the tags generated by SnapRAID. For the most detailed and up-to-date information regarding the meaning and context of the values, it is recommended to check the source code's `log_tag()` statements.

When a path is output, it is always escaped using a backslash (\) as the escape character.

The following characters are escaped into sequences:

The colon is escaped to \d.
The newline is escaped to \n.
The carriage return is escaped to \r.
The backslash is escaped to \\.

Some tags are output only when the `--gui` option is used. They provide extra verbose state and runtime progress only useful for a GUI interface.

2 Configuration Tags

These tags report the memory usage and global configuration after scanning the disk and reading the list of files.
conf:file:<path>
Configuration file loaded (escaped).
conf:missing:
Operating without a configuration file.
blocksize:<bytes>
The configured block size in bytes (uint).
data:<disk_name>:<dir>
The data disks as defined in the configuration file.
<disk_name> The assigned name of the disk.
<dir> The directory entry point of the disk.
mode:<raidname>
The RAID mode used. One of `par1`, `par2`, `par3`, `par4`, `par5`, `par6` or `parz`. The number indicates the maximum number of simultaneous disk failures the array can withstand.
<parity_level>:<split_index>:<path>
The parity files as defined in the configuration file.
<parity_level> One of `parity`, `2-parity`, ..., `6-parity`. This corresponds to the level of redundancy.
<split_index> The split index (uint). If no multiple split parity is configured, there is only the index 0. A split parity configuration distributes parity blocks across multiple files.
<path> The path (escaped).
pool:<dir>
The configured dir to the pool mount point (escaped). This is the optional mount point for the 'pool' feature.
share:<dir>
The configured dir to the pool mount point (escaped). This is the optional mount point for the 'share' feature.
autosave:<bytes>
If the autosave feature is enabled, and after how many bytes (uint64). This specifies the interval for content file saving.
filter:<pattern>
All the active filters with their patterns. These patterns exclude specific files or directories from the SnapRAID array.
filter:nohidden:
If the no-hidden filter is enabled, meaning hidden files/directories (starting with '.') are excluded from the array.
content:<path>
The absolute path to a content file being used (escaped). Content files store the metadata (like file hashes and timestamps) for the array.
content:<parity_level>:<split_index>:<path>:<uuid>:<size>
The parity files as stored in the content file.
<parity_level> One of `parity`, `2-parity`, ..., `6-parity`.
<split_index> The split index (uint). If no multiple split parity is configured, there is only the index 0.
<path> The path (escaped).
<uuid> The UUID of the partition containing the path.
<size> The size of the parity file. Size is -1 if not yet fixed, meaning it can grow. This happens for the latest split.

3 Diagnostics Tags

version:<version>
The version of SnapRAID run.
unixtime:<time>
The current time in the unix format (uint64), representing seconds since the epoch.
time:<YYYY-MM-DD HH:MM:SS>
The current time in human format.
command:<command>
The command run. One of `sync`, `scrub`, `check`, `fix`, `status`, ...
argv:<number>:<argument>
All the arguments of the executable command. The 0 one is the executable run.
memory:used:<bytes>
The total memory currently used by the application in bytes (uint64).
memory:block:<bytes>
Size of the internal `snapraid_block` structure in bytes (uint64).
memory:extent:<bytes>
Size of the internal `snapraid_extent` structure in bytes (uint64).
memory:file:<bytes>
Size of the internal `snapraid_file` structure in bytes (uint64).
memory:link:<bytes>
Size of the internal `snapraid_link` structure in bytes (uint64).
memory:dir:<bytes>
Size of the internal `snapraid_dir` structure in bytes (uint64).

4 Scan Tags

These tags report detected differences between the filesystem and the content file. They are output for every discovered change, and `scan:equal` is only output when the `--gui` option is used.
scan:equal:<disk_name>:<path>
A file, link, or directory is equal (unchanged) (GUI only). No action is required for this item.
<disk_name> Name of the data disk.
<path> Path to the file/link/dir relative to the disk mount (escaped).
scan:add:<disk_name>:<path>
A new file, link, or directory was found that is not in the content file. This item will be added to the array in a `sync`.
scan:remove:<disk_name>:<path>
A file, link, or directory has been removed from the filesystem since the last sync. This item will be removed from the content file in a `sync`.
scan:update:<disk_name>:<path>
A file or link has been updated (size, timestamp, or link target changed). This item will have its content data blocks re-hashed in a `sync`.
scan:move:<disk_name>:<old_path>:<new_path>
A file was moved on the same disk. This is an efficient operation that only updates the path metadata without re-hashing blocks.
<old_path> The old path to the file (escaped).
<new_path> The new path to the file (escaped).
scan:copy:<disk_name>:<path>:<source_disk>:<source_path>
A new file was found to be a copy of a file from another disk. This is detected by matching file size and timestamp, and is an efficient operation that avoids re-hashing all blocks.
<source_disk> The original file's disk.
<source_path> The original file's location (escaped).
scan:restore:<disk_name>:<path>
A file's inode has changed but not its date-time and size, which suggests the file may be restored from backup. The file won't be re-hashed in `sync` as its precomputed hash is assumed to be correct.

These tags provide a final count of all detected changes.

summary:equal:<count>
Total number of equal (unchanged) files/links/firs found (uint).
summary:added:<count>
Total number of new files/links/dirs found (uint).
summary:removed:<count>
Total number of removed files/links/dirs found (uint).
summary:updated:<count>
Total number of updated files/links found (uint).
summary:moved:<count>
Total number of moved files found (uint).
summary:copied:<count>
Total number of copied files found (uint).
summary:restored:<count>
Total number of restored files found (uint).
summary:exit:equal
A zero-argument tag indicating that no differences were found. The array is already synchronized.
summary:exit:diff
A zero-argument tag indicating that differences were found. The array needs a `sync` operation.

5 General Progress and Execution Tags

These tags are used to report the runtime processing of the commands. Only produced when `--gui` option is used.
run:begin:<blockstart>:<blockend>:<countmax>
A tag indicating the start of the command execution.
<blockstart> Starting block index (uint).
<blockend> Ending block index + 1 (uint).
<countmax> Number of blocks to process. It may be less than <blockend> - <blockstart> + 1 if some blocks are going to be skipped (uint).
run:end
A zero-argument tag indicating the end of the command execution.
run:pos:<blockpos>:<countpos>:<countsize>:<perc>:<eta>:<size_speed>:<cpu>:<elapsed>
Detailed progress information during command execution.
<blockpos> Current block index position (uint).
<countpos> Current item count position (uint).
<countsize> Current size processed (uint64).
<perc> Percentage complete (uint).
<eta> Estimated time of arrival in minutes (uint).
<size_speed> Data processing speed in MiB/s (uint).
<cpu> CPU usage percentage (uint).
<elapsed> Elapsed time in seconds (uint64).
sigint:<blockpos>:<msg>
A user interruption (e.g., Ctrl+C) was signaled. The process is gracefully aborting.
<blockpos> Current block index position (uint).
<msg> Text message exactly as it's printed on screen.
msg:<level>:<msg>
Messages printed to the screen.
<level> One of `fatal`, `error`, `expected`, `status`, `progress` or `verbose`.
fatal A fatal error occurred. Program will abort after this message.
error A generic error condition that doesn't prevent the program to continue.
expected An expected error condition. At present it happens only when using the `-m` option with files expected missing.
status A status message, usually providing context or a summary.
progress A progress message, often part of an ongoing operation.
verbose A verbose informative message, only shown in verbose mode.
<msg> Text message exactly as it's printed on screen.

6 Thermal Tags

The following tags are produced by the thermal monitoring functions when SnapRAID is processing, typically during operations that involve disk access.
thermal:ambient:device:<hwmon_dir>:<name>:<temp_file>:<label>:<temp>
Logs a temperature reading found in the system using the Linux /sys/class/hwmon interface. Only present in Linux.
<hwmon_dir> The hwmon directory name (e.g., hwmon0).
<name> The name of the hwmon device (e.g., k10temp).
<temp_file> The temperature file name (e.g., temp1_input).
<label> The label associated with the temperature sensor (e.g., Tdie).
<temp> The temperature reading in degrees Celsius.
thermal:ambient:candidate:<temp>
Reports a temperature reading that is a candidate for the ambient temperature, used in the heating model calculation.
<temp> The candidate temperature in degrees Celsius.
thermal:system:candidate:<temp>
Logs a temperature reading from a connected disk that is being considered as a candidate for determining the ambient system temperature.
<temp> The current temperature read from the disk (uint, degrees Celsius).
thermal:system:final:<temp>
Logs the final ambient system temperature calculated. This value is the lowest valid temperature observed among all candidates, representing the room temperature.
<temp> The calculated ambient temperature in degrees Celsius.
thermal:current:<disk_name>:<device>:<temp>
Logs the most recent temperature reading for a specific disk device.
<disk_name> The configured name of the disk.
<device> The unique device ID (uint64).
<temp> The current temperature read from the disk in degrees Celsius.
thermal:highest:<temp>
Logs the highest temperature observed among all monitored disks in the current measurement cycle. This is used for thermal throttling.
<temp> The highest temperature observed in degrees Celsius.
thermal:heat:<disk_name>:<device>:<count>:<data_points>
Logs the entire history of temperature data points collected so far for a specific disk, used for fitting the heating model. Only monotone increasing temperatures are included in the history.
<disk_name> The configured name of the disk.
<device> The unique device ID (uint64).
<count> The total number of collected data points (uint).
<data_points> A comma-separated list of temperature/time pairs. Each pair is formatted as <temp>/<time_offset>.
<temp> Temperature reading in degrees Celsius.
<time_offset> Time offset from the start of the thermal monitoring (uint, seconds).
thermal:params:<disk_name>:<device>:<k_heat>:<t_ambient>:<t_steady>:<rmse>:<r_squared>:<max_error>
Logs the estimated parameters for the exponential heating model (fit using least squares) and associated quality metrics for a specific disk. The model is: T(t) = T_steady - (T_steady - T_0) e^(-kt), where T_0 is the initial temperature.
<disk_name> The configured name of the disk.
<device> The unique device ID (uint64).
<k_heat> The heating rate constant, k (double).
<t_ambient> The ambient temperature, T_ambient (double).
<t_steady> The estimated steady-state temperature, T_steady (double), which is the maximum expected temperature of the disk.
<rmse> Root Mean Square Error of the fit (double).
<r_squared> Coefficient of determination (R^2) of the fit (double).
<max_error> Maximum absolute error of the fit (double).
thermal:spindown
Indicates that the thermal alarm limit has been reached, and the process is initiating a disk spindown to begin the cooldown procedure, preventing overheating.
thermal:cooldown:<sleep_time>
Indicates the duration of the cooldown waiting period after spindown.
<sleep_time> The total time the system will wait for cooldown (uint, seconds).
thermal:spinup
Indicates that the cooldown period is complete, and the disks are being spun back up to resume the operation.

7 Command Status Tags

This section describes the tags output with the `status` command.

Summary Tags

These tags provide general information about the array configuration and overall state.
summary:block_size:<uint>
The size of a block in bytes. This is the unit of parity protection.
summary:parity_block_count:<uint>
The total number of blocks allocated for all parity levels combined.
summary:parity_block_total:<name>:<uint>
Total blocks available for a specific parity level (e.g., `parity`, `2-parity`).
summary:parity_block_free:<name>:<uint>
Free blocks available for a specific parity level.
summary:parity_block_free_min:<uint>
The minimum number of free blocks across all parity levels. This determines the maximum size of data that can be added.
summary:file_count:<uint>
Total number of files in the array.
summary:file_block_count:<uint64>
Total number of data blocks used by files.
summary:fragmented_file_count:<uint>
Total number of fragmented files, meaning files whose blocks are not contiguous.
summary:excess_fragment_count:<uint>
Total number of excess fragments (one less than the total fragments). This is a measure of data fragmentation overhead.
summary:zerosubsecond_file_count:<uint>
Total number of files with a zero sub-second timestamp. This can occur on certain filesystems and may affect change detection.
summary:file_size:<uint64>
Total size of all files in bytes.
summary:parity_size:<uint64>
Total size of allocated parity blocks in bytes.
summary:parity_size_max:<uint64>
Maximum possible parity size (allocated + min free) in bytes. This is the effective maximum protection size.
summary:hash:<name>
The current hash algorithm in use (e.g., `sha256`).
summary:prev_hash:<name>
The previous hash algorithm used, if a rehash is in progress.
summary:best_hash:<name>
The best hash algorithm for optimal performance based on system capabilities.
summary:total_wasted:<uint64>
Total wasted space (space on data disks exceeding parity capacity) in bytes.
summary:total_used:<uint64>
Total used space by data files in bytes.
summary:total_free:<uint64>
Total free space (usable by data) in bytes, limited by parity capacity.
summary:total_use_percent:<uint>
Overall array use percentage.
summary:has_unsynced:<uint>
Count of blocks that are unsynced (need a sync), meaning their parity data is out of date.
summary:has_unscrubbed:<uint>
Count of blocks that are unscrubbed (just synced), meaning they have never been verified since the last sync.
summary:has_rehash:<uint>
Count of blocks needing a rehash, usually due to a content file update or hash algorithm change.
summary:has_bad:<count>:<first>:<last>
Count of bad blocks, along with the first and last bad block index. Bad blocks indicate data or parity corruption.
summary:scrub_oldest_days:<uint>
Days ago the oldest block was last scrubbed.
summary:scrub_median_days:<uint>
Days ago the median block was last scrubbed.
summary:scrub_newest_days:<uint>
Days ago the newest block was last scrubbed.

Per-Disk Tags

These tags provide statistics for individual data disks. <name> is the disk name.
summary:disk_file_count:<name>:<uint>
Number of files on the disk.
summary:disk_block_count:<name>:<uint>
Number of blocks used by files on the disk.
summary:disk_fragmented_file_count:<name>:<uint>
Number of fragmented files on the disk.
summary:disk_excess_fragment_count:<name>:<uint>
Number of excess fragments on the disk.
summary:disk_zerosubsecond_file_count:<name>:<uint>
Number of files with zero sub-second timestamp on the disk.
summary:disk_file_size:<name>:<uint64>
Total size of files on the disk in bytes.
summary:disk_block_allocated:<name>:<uint>
Highest block index used on the disk + 1.
summary:disk_block_total:<name>:<uint>
Total blocks on the disk (physical size).
summary:disk_block_free:<name>:<uint>
Free blocks on the disk.
summary:disk_block_max_by_space:<name>:<uint>
Total blocks by disk space (used + free blocks), representing the physical limit of the disk.
summary:disk_block_max_by_parity:<name>:<uint>
Total blocks limited by parity space (parity size + min parity free blocks). This is the logical limit imposed by the parity files.
summary:disk_block_max:<name>:<uint>
Maximum usable blocks (minimum of `..._by_space` and `..._by_parity`).
summary:disk_space_wasted:<name>:<int64>
Wasted space on the disk in bytes (positive if disk is larger than usable parity space).
summary:disk_used:<name>:<uint64>
Used space on the disk in bytes.
summary:disk_free:<name>:<uint64>
Free usable space on the disk in bytes, limited by `disk_block_max`.
summary:disk_use_percent:<name>:<uint>
Disk use percentage relative to `disk_block_max`.

File Timestamp Tags

These tags list files with zero sub-second timestamps.
zerosubsecond:<disk_name>:<file_path>
Lists files that have a zero sub-second timestamp. Up to 50 are logged per disk.

Block Information Tags

These tags are generated when the GUI option is enabled (`state->opt.gui`).
block_count:<uint>
The total number of blocks in the array.
block:<index>:<time>:<used>:<unsynced>:<bad>:<rehash>
Status of a specific block.
<index> Block index.
<time> Last scrub time (Unix timestamp). A value of 0 means the block has never been scrubbed.
<used> `used` if the block contains data, otherwise empty.
<unsynced> `unsynced` if the block needs a sync, otherwise empty.
<bad> `bad` if the block has errors, otherwise empty.
<rehash> `rehash` if the block needs a rehash, otherwise empty.
block_noinfo:<index>:<used>:<unsynced>
Status of an unused block (no info recorded) in the content file.
<index> Block index.
<used> `used` if the block contains data, otherwise empty.
<unsynced> `unsynced` if the block needs a sync, otherwise empty.

Scrub History Tags

These tags provide details on the scrub/sync time distribution.
info_count:<uint>
Total number of info records about past scrub and sync operations stored in the content file.
info_time:<time>:<count>:<status>
All the info records.
<time> Unix timestamp of the scrub/sync.
<count> Number of blocks processed at this timestamp.
<status> "scrubbed" (for blocks verified to be correct) or "new" (for synced blocks that haven't been scrubbed yet).
scrub_graph_range:<max_columns>:<max_height>
Dimensions of the scrub history graph obtained from the `info_time` records. This provides the boundary for the precomputed graph data available in the `scrub_graph_bar` tags.
<max_columns> The number of columns in the graph (constant GRAPH_COLUMN).
<max_height> The maximum height (peak count) of blocks found in any column (the highest sum of scrubbed and new blocks).
scrub_graph_bar:<index>:<days_ago>:<scrubbed>:<new>
Data for a column of the scrub history graph. Each column represents a time period.
<index> Column index. From 0 to max_columns - 1.
<days_ago> Days ago for this column's time range.
<scrubbed> Count of scrubbed blocks in that day range.
<new> Count of newly synced (unscrubbed) blocks in that day range.

8 Command Sync/Scrub Tags

Tags specific for the `sync` and `scrub` commands. Also the error tags are possible.

Summary Tags

These tags provide summary statistics at the end of the command.
hash_summary:error_file:<count>
Logs the total count of file-related errors that caused a block to be skipped during the hashing phase. These are often due to file changes (missing, size/time change) during the sync operation. This happens only in `sync`.
<count> Total number of file errors (uint).
summary:error_file:<count>
Logs the total count of file-related errors encountered during the process (e.g., missing files, file attribute changes).
<count> The total number of file errors encountered (uint).
summary:error_io:<count>
Logs the total count of input/output errors encountered on data or parity disks.
<count> The total number of I/O errors encountered (uint).
summary:error_data:<count>
Logs the total count of "silent data errors" (data blocks not matching their expected hash) encountered during the sync process.
<count> The total number of silent data errors encountered (uint).
summary:exit:<status>
Logs the overall exit status of the command. The `status` is one of the following:
ok No errors were found.
error If any errors were found (file, I/O, or data errors).

9 Command Check/Fix Tags

Tags specific for the `check` and `fix` commands. Also the error tags are possible.

Fixed/Recovered Tags

These tags log successful repairs during fix operations.
fixed:<block_pos>:<disk_name>:<file_path>:<msg>
Indicates that a file was successfully fixed using parity data.
<block_pos> The block position being processed (uint).
<disk_name> The name of the disk.
<file_path> The file path relative to disk root (escaped).
<msg> A descriptive message indicating the nature of the fix (e.g., `Fixed size`, `Fixed data error at position...`).
parity_fixed:<block_pos>:<parity>:<msg>
Indicates that corrupted parity data was successfully recomputed and written.
<block_pos> The block position being processed (uint).
<parity> The name of the parity level (e.g., "parity", "2-parity").
<msg> A descriptive message indicating the nature of the fix (e.g., `Fixed data error`).
empty_fixed:<disk_name>:<file_path>:<msg>
Logs successful recreation of a missing or corrupted empty file.
<disk_name> The name of the disk.
<file_path> The file path relative to disk root (escaped).
<msg> A descriptive message indicating the nature of the fix (e.g., `Fixed empty file`).
hardlink_fixed:<disk_name>:<link_path>:<msg>
Logs successful recreation of a hard link during fix operation.
<disk_name> The name of the disk.
<link_path> The hard link path relative to disk root (escaped).
<msg> A descriptive message indicating the nature of the fix (e.g., `Fixed hardlink error`).
symlink_fixed:<disk_name>:<link_path>:<msg>
Logs successful recreation of a symbolic link during fix operation.
<disk_name> The name of the disk.
<link_path> The symlink path relative to disk root (escaped).
<msg> A descriptive message indicating the nature of the fix (e.g., `Fixed symlink error`).
dir_fixed:<disk_name>:<dir_path>:<msg>
Logs successful recreation of a missing directory during fix operation.
<disk_name> The name of the disk.
<dir_path> The directory path relative to disk root (escaped).
<msg> A descriptive message indicating the nature of the fix (e.g., `Fixed dir error`).

Unrecoverable Error Tags

These tags log errors that could not be recovered.
unrecoverable:<block_pos>:<disk_name>:<file_path>:<msg>
Indicates that a block error could not be fixed due to insufficient parity or other recovery limitations.
<block_pos> The block position being processed (uint).
<disk_name> The name of the disk.
<file_path> The file path relative to disk root (escaped).
<msg> A descriptive message indicating the nature of the problem (e.g., `Unrecoverable error at position <file_pos>`, `Unrecoverable unsynced error at position <file_pos>`).
collision:<disk_name>:<file_path>:<collision_path>:<msg>
Logs that the modification time was not set on a recovered file to avoid inode collision with another file.
<disk_name> The name of the disk.
<file_path> The file path relative to disk root (escaped).
<collision_path> The path of the colliding file (escaped).
<msg> A descriptive message indicating the nature of the problem (e.g., `Not setting modification time to avoid inode collision`).

File Status Tags

These tags log the final status of files after processing.
status:unrecoverable:<disk_name>:<file_path>
Indicates that a file has unrecoverable errors and was renamed to `.unrecoverable` (in fix mode) or cannot be recovered (in check mode).
<disk_name> The name of the disk.
<file_path> The file path relative to disk root (escaped).
status:recovered:<disk_name>:<file_path>
Logs that a file was successfully recovered during fix operation.
<disk_name> The name of the disk.
<file_path> The file path relative to disk root (escaped).
status:damaged:<disk_name>:<file_path>
Indicates that a file is damaged (in audit-only mode, e.g., using `check`).
<disk_name> The name of the disk.
<file_path> The file path relative to disk root (escaped).
status:recoverable:<disk_name>:<file_path>
Logs that a file has errors but could be recovered in fix mode.
<disk_name> The name of the disk.
<file_path> The file path relative to disk root (escaped).
status:correct:<disk_name>:<file_path>
Indicates that a file passed all checks successfully (verbose mode only).
<disk_name> The name of the disk.
<file_path> The file path relative to disk root (escaped).

Summary Tags

These tags provide summary statistics at the end of the command.
summary:error:<error_count>
Logs the total number of errors encountered.
<error_count> Total number of errors (uint).
summary:error_recovered:<recovered_count>
Logs the total number of errors successfully recovered (fix mode only).
<recovered_count> Number of recovered errors (uint).
summary:error_unrecoverable:<unrecoverable_count>
Logs the total number of unrecoverable errors (not in audit-only mode).
<unrecoverable_count> Number of unrecoverable errors (uint).
summary:exit:<status>
Logs the overall exit status of the command. The `status` is one of the following:
`ok` Indicates that the operation completed with no errors.
`recovered` Indicates that the operation completed with all errors successfully recovered (fix mode only).
`recoverable` Indicates that errors were found but are all recoverable (check mode only).
`unrecoverable` Indicates that unrecoverable errors were found.
`error` Indicates that errors were found (audit-only mode).

10 Command List Tags

This section describes the tags output with the `list` command.

List Tags

These tags log details about individual files and links processed during the listing operation.
file:<disk_name>:<subpath>:<size>:<mtime_sec>:<mtime_nsec>:<inode>
Logs details for a regular file found on a disk.
<disk_name> The configured name of the disk.
<subpath> The path of the file relative to the disk's root (escaped).
<size> The size of the file in bytes (uint64).
<mtime_sec> The file's modification time in seconds since the Epoch (int64).
<mtime_nsec> The file's modification time nanosecond component (uint).
<inode> The file's inode number (int64).
link_<type>:<disk_name>:<subpath>:<linkto>
Logs details for a link found on a disk. The `<type>` component varies based on the kind of link.
<type> The type of link, one of: `hardlink`, `symlink`, `symdir` (symlink to a directory), `junction` (Windows-specific reparse point).
<disk_name> The configured name of the disk (string).
<subpath> The path of the link relative to the disk's root (escaped).
<linkto> The target path of the link (escaped).

Summary Tags

These tags log final statistics about the entire listing operation.
summary:file_count:<count>
Logs the total number of regular files processed.
<count> The total number of files (uint).
summary:file_size:<size>
Logs the total size of all regular files processed.
<size> The cumulative size of all files (uint64, bytes).
summary:link_count:<count>
Logs the total number of links processed (hardlinks, symlinks, symdirs, junctions).
<count> The total number of links (uint).
summary:exit:ok
Indicates a successful completion of the listing operation. Note that if a fatal error happens, the program will abort, and you won't get this tag.

11 Command Dup Tags

This section describes the tags output with the `dup` command.

Duplicate Tags

These tags log information about detected duplicate files and provide a summary of the duplicate finding process. The content hash of the whole file is used to determine duplicates.
dup:<diskname1>:<file_path1>:<diskname2>:<file_path2>:<size>: dup
Logs the information about a pair of duplicate files found. The first file listed is the one just processed, and the second file is the previously processed file that has the same content hash.
<diskname1> The configured name of the disk containing the newly processed duplicate file.
<file_path1> The path of the newly processed duplicate file relative to its disk's mount point (escaped).
<diskname2> The configured name of the disk containing the previously processed file that is the duplicate of `<file_path1>`.
<file_path2> The path of the previously processed duplicate file relative to its disk's mount point (escaped).
<size> The size of the duplicate file in bytes (uint64). This size corresponds to the file `<file_path2>`.

Summary Tags

These tags provide a final summary of the duplicate finding process.
summary:dup_count:<count>
Logs the total number of duplicate files found. A file is counted as a duplicate if its hash matches a hash already seen.
<count> The total count of duplicate files (uint).
summary:dup_size:<size>
Logs the total size of all duplicate files found. This size is the sum of the sizes of all files considered duplicates.
<size> The total size of duplicate files in gigabytes (uint64).
summary:exit:unique
Logs the final exit status indicating that no duplicate files were found. This tag is logged if `<count>` is zero.
summary:exit:dup
Logs the final exit status indicating that at least one duplicate file was found. This tag is logged if `<count>` is greater than zero.

12 Command Pool Tags

This section describes the tags output with the `pool` command.
summary:link_count:<count>
Logs the total number of links created (symlinks, junctions).
<count> The total number of links (uint).
summary:exit:ok
Indicates a successful completion of the pool operation. Note that if a fatal error happens, the program will abort, and you won't get this tag.

13 Command Rehash Tags

This section describes the tags output with the `rehash` command.

Summary Tags

These tags provide a final summary of the rehash scheduling process.
summary:exit:scheduled
Logs the final exit status indicating that a rehash operation has been successfully scheduled. The rehash will be performed incrementally in future `sync` or `scrub` commands.
summary:exit:already_in_progress
Logs the final exit status indicating that a rehash is already in progress and cannot be scheduled again. This causes the program to exit with a fatal error.
summary:exit:not_required
Logs the final exit status indicating that the current hash algorithm is already the `best hash` for the platform, and thus a rehash is not required. This causes the program to exit with a fatal error.

14 Command Smart Tags

This section describes the tags output with the `smart` command.

Note that a `<disk_name>` may be associated with more `<device_file>`, in case the logical disk uses more physical disks. In such a case, you'll see multiple tags for the same `<disk_name>` but with different `<device_file>`.

SMART Attributes

Tags logging specific disk identification and raw SMART attribute values.
smart:<device_file>:<disk_name>
Logs the start of the SMART report for a device.
<device_file> The file path of the device (e.g., /dev/sdb).
<disk_name> The configured name of the disk.
attr:<device_file>:<disk_name>:serial:<serial_number>
Logs the disk's serial number.
<serial_number> The disk's serial number (escaped).
attr:<device_file>:<disk_name>:vendor:<vendor>
Logs the disk's vendor string.
<vendor> The disk's vendor identifier (escaped).
attr:<device_file>:<disk_name>:model:<model>
Logs the disk's model string.
<model> The disk's model identifier (escaped).
attr:<device_file>:<disk_name>:afr:<afr_value>:<afr_prob>
Logs the estimated Annual Failure Rate (AFR) and the probability of one failure in the next year based on SMART attributes. The AFR is calculated using the maximum rate reported by specific SMART attributes (5, 187, 188, 197, 198).
<afr_value> The computed Annual Failure Rate (double).
<afr_prob> The probability of one or more failures in the next year (double).
attr:<device_file>:<disk_name>:size:<size_bytes>
Logs the size of the disk.
<size_bytes> The disk size in bytes (uint64).
attr:<device_file>:<disk_name>:error:<error_count>
Logs the raw value of the total error count (e.g., from SMART attribute 199, if used for the report).
<error_count> The total error count (uint64).
attr:<device_file>:<disk_name>:rotationrate:<rate>
Logs the disk's rotation rate. A value of 0 indicates an SSD.
<rate> The rotation rate (uint64, RPM).
attr:<device_file>:<disk_name>:flags:<flags_decimal>:<flags_hex>
Logs the SMART status flags from the utility (e.g., smartctl).
<flags_decimal> The raw flags value (uint64, decimal).
<flags_hex> The raw flags value (uint64, hexadecimal).
attr:<device_file>:<disk_name>:<id>:<value_decimal>:<value_hex>
Logs the raw value of any assigned SMART attribute.
<id> The SMART attribute ID (uint).
<value_decimal> The raw attribute value (uint64, decimal).
<value_hex> The raw attribute value (uint64, hexadecimal).

Summary

Tags logging the overall failure probabilities for the array.
summary:array_failure:<array_afr>:<array_prob>
Logs the total estimated failure rate for the entire array (sum of individual disk AFRs) and the probability of at least one disk failure in the next year.
<array_afr> The sum of AFRs of all disks in the array (double).
<array_prob> The probability of at least one disk failure in

the next year (double).

15 Command Probe Tags

This section describes the tags output with the `probe` command.

Note that a `<disk_name>` may be associated with more `<device_file>`, in case the logical disk uses more physical disks. In such a case, you'll see multiple tags for the same `<disk_name>` but with different `<device_file>`.

Device Power State

Tags used to report the power state of each device.
probe:<device_file>:<disk_name>:<power_state>
Logs the detected power state of a device.
<device_file> The file path of the device (e.g., /dev/sdb).
<disk_name> The configured name of the disk.
<power_state> The numerical power state: 0: Unknown, 1: StandBy, 2: Active.

16 Error Tags

These tags report specific errors that occur on data disks during the commands that access files and parities.
error:<block>:<disk_name>:<file>:<msg>
Logs file access errors (open, read, file changed) during the data disk read operation for parity calculation or verification.
<block> The zero-based index of the block where the error occurred (uint).
<disk_name> The name of the data disk.
<file> The path (relative to the disk mount point) of the file containing the block (escaped).
<msg> A descriptive message indicating the nature of the error (e.g., `Open/Read/Write EIO error`, `Open/Read/Write error`, `Data error at position <pos>, diff bits <diff>/<bits>`).
parity_error:<block>:<level>:<msg>
Logs errors during parity disk read or write operations.
<block> The zero-based index of the block where the error occurred (uint).
<level> The configuration name of the parity level (e.g., `parity`, `2-parity`).
<msg> A descriptive message indicating the nature of the error (e.g., `Read/Write EIO error`, `Read/Write error`, `Data error, diff bits <diff>/<bits>`).
hardlink_error:<disk_name>:<link_path>:<target_path>:<msg>
Indicates an error when attempting to access a hard link.
<disk_name> The name of the disk.
<link_path> The hard link path relative to disk root (escaped).
<target_path> The target path of the hard link (escaped).
<msg> A descriptive message indicating the nature of the error (e.g., `Hardlink stat error`, `Hardlink error for not regular file`, `Hardlink to stat error`, `Hardlink-to error for not regular file`, `Hardlink mismatch for different inode`).
symlink_error:<disk_name>:<link_path>:<msg>
Indicates an error when attempting to access a symbolic link.
<disk_name> The name of the disk.
<link_path> The symlink path relative to disk root (escaped).
<msg> A descriptive message indicating the nature of the error (e.g., `Symlink read error`, `Symlink data error '<actual>' instead of '<expected>'`).
dir_error:<disk_name>:<dir_path>:<msg>
Indicates an error when attempting to access a directory.
<disk_name> The name of the disk.
<dir_path> The directory path relative to disk root (escaped).
<msg> A descriptive message indicating the nature of the error (e.g., `Dir stat error`, `Dir error for not directory`).
outofparity:<disk_name>:<file_path>
Logs that a file's blocks extend beyond the available parity space, indicating that the parity files are too small to protect all data. This occurs when data requires more parity than is available on the parity disk(s) and is a critical warning.
<disk_name> The name of the disk containing the file.
<file_path> The file path relative to the disk root (escaped).