diff --git a/HISTORY b/HISTORY index ccefee41..8949e68c 100644 --- a/HISTORY +++ b/HISTORY @@ -4,13 +4,13 @@ SnapRAID HISTORY 6.2 2014/5 ========== * Fixed the regression test when run as root. - * Added a new euristic to detect file copies. Now a file is assumed + * Added a new heuristic to detect file copies. Now a file is assumed to be a copy if name, size and nanosecond timestamp are matching, - but if the nanosecond part of the timestamp is 0, we require + but if the nanosecond part of the timestamp is 0, it requires the full path matching and not only the name. * Added the -N, --force-nocopy option to disable completely - the copy detection. SnapRAID also suggest to use this option - in the error message of a data mismatch if caused by the + the copy detection. SnapRAID also suggests to use this option + in the error message of a data mismatch if likely caused by the copy detection. 6.1 2014/4 @@ -99,7 +99,7 @@ SnapRAID HISTORY This improves the performance in sync for modified files. * Added a new "list" command to see the stored list of files. * Removed the detailed list of errors from the screen output. - To get it you must explicitely use the -l, --log option. + To get it you must explicitly use the -l, --log option. It's now too detailed for the screen, because it contains a lot of info. * Changed the output format of some commands to make it similar @@ -175,7 +175,7 @@ SnapRAID HISTORY * Fixed a directory creation problem in Windows when the "disk" option points to the root directory of a drive. Now SnapRAID won't complain about the inability to create such directory. - If you encouter this problem when trying to recover your data, just upgrade + If you encounter this problem when trying to recover your data, just upgrade to this version, and you'll be able to complete the recovering process. No need to upgrade for platforms different than Windows. @@ -205,7 +205,7 @@ SnapRAID HISTORY symlink is saved and not the linked file. Note that Windows Symlinks to dirs and junctions are still not supported. * Files without read permission generate an error instead of a warning. - You now must explicitely exclude them in the configuration file with + You now must explicitly exclude them in the configuration file with exclusion rules. * In 'check' and 'fix', if verbose is enabled, prints the result for each processed file. @@ -273,7 +273,7 @@ SnapRAID HISTORY * Fixed directory inclusion, in case the last rule is an "include" one. * Fixed very long paths in Windows. We now always use the special '\\?' prefix to remove the 260 chars limitation. - * If a file is excluded, it prints explicitely which attribute caused the + * If a file is excluded, it prints explicitly which attribute caused the exclusion. * Automatically excludes also the temporary copy of content file, the one with the ".tmp" extension. @@ -397,7 +397,7 @@ SnapRAID HISTORY * Added support for multiple 'content' files. You can save extra copies to be able to verify the checksums also if you lose all the 'content' files in the parity disks. -* Added a filtering include logic, where anything not explicitely included +* Added a filtering include logic, where anything not explicitly included is excluded. For example, it allow to include only the files in a predefined set of directories. * The check command returns with an error code if any kind of error is present. diff --git a/TEST b/TEST index 3672dbf5..dec4a379 100644 --- a/TEST +++ b/TEST @@ -25,7 +25,7 @@ the error conditions that result in an immediate termination of the program. You can recognize this excluded code because it's enclosed between the LCOV_EXCL_START and LCOV_EXCL_STOP keywords. -To test with the clang static anlayzer use: +To test with the clang static analyzer use: scan-build ./configure scan-build make diff --git a/TODO b/TODO index 383c7cbb..afafea4a 100644 --- a/TODO +++ b/TODO @@ -26,12 +26,12 @@ to estimate the speed of the last minute, for each second. * Checks if splitting hash/parity computation in 4K pages can improve speed in sync. That should increase cache locality, -becase we read the data two times for hash and and parity, +because we read the data two times for hash and and parity, and if we manage to keep it in the cache, we should save time. -* In the content file save the timestap of the parity files. +* In the content file save the timestamp of the parity files. If they do not match, stop the processing. -This can be done to avoid to use not syncronized parity and content files, +This can be done to avoid to use not synchronized parity and content files, resulting in wrong data. But if the sync process is killed we need a way to resyncronize them. Or maybe we should allow parity never than content, but not viceversa. @@ -80,8 +80,8 @@ rest of the block. The problem is that we don't have any hash to ensure that the block is partially recovered, or completely garbage. But it makes sense to anyway write the "most likely" correct one. -* In the repair() function the euristic to detect if we recovered after the sync, can be extended -to all the previous blocks, because we always proceeed in block order during a sync. +* In the repair() function the heuristic to detect if we recovered after the sync, can be extended +to all the previous blocks, because we always proceed in block order during a sync. So, if for a block we can detect that we recovered using updated parity data, also for all the previous blocks this is true. Anyway, the case where this information could be useful should be present @@ -117,7 +117,7 @@ This feature can be enabled with a specific option, and available in Windows using Shadow Copy, and in Linux using Btrfs, and in a generic Unix using ZFS. See Jens's Windows script at: http://sourceforge.net/p/snapraid/discussion/1677233/thread/a1707211/ -Note that a different between Windows and Unix is that in Windows old shapshots +Note that a different between Windows and Unix is that in Windows old snapshots are automatically deleted. * Use smaller hashes to reduce the memory occupation. We can truncate the 128 bits hash @@ -142,7 +142,7 @@ existing filesystem. In the order of 0.01%. Not really worth to do it. - With NTFS the saving is also limited, because the "reserved" MFT of 12.5% is not really exclusively reserved, but can be used also for normal files, -when all the remainig space is filled. +when all the remaining space is filled. * Split the parity in multiple files and allow it to coexist with data in the same disk. @@ -239,7 +239,7 @@ data doesn't overlap, do not recompute it. - It's going to work only in RAID5 mode and only in special cases. * Implements a multithread sync command. -- At now it's questionable if it will result in a performance improvment. +- At now it's questionable if it will result in a performance improvement. The murmur3 hash, and the RAID5/6 computations are so fast that even a single thread should be able to do them. Use the "snapraid -T" comment to see the speed. diff --git a/snapraid.1 b/snapraid.1 index c5f0cc55..216c37d7 100644 --- a/snapraid.1 +++ b/snapraid.1 @@ -762,7 +762,7 @@ read for the first time, This happens when the system is under heavy pressure due all disks spinning and CPU busy, and in such extreme conditions, if your machine has a latent hardware problem, it\'s possible to -encouter silent errors what cannot be detected because the data +encounter silent errors what cannot be detected because the data is not yet hashed. To avoid this risk, you can enable the \[dq]pre\-hash\[dq] mode and have all the data hashed two times to ensure its integrity. @@ -821,14 +821,14 @@ disk in the free space left in an already used disk. and this option allows you to continue anyway. .TP .B \-N, \-\-force\-nocopy -In the \[dq]sync\[dq] command, disables the copy detection optimization. -Withouth this option SnapRAID assumes that files with the +In the \[dq]sync\[dq] command, disables the copy detection heuristic. +Without this option SnapRAID assumes that files with the same name, size, and nanosecond timestamp are copies with the same data. This allows to identify copied files from one dir to another, and to reuse the already computed hash information to detect silent errors in the copy. -This behaviour, in some rare cases, may result in false positives, +This behavior, in some rare cases, may result in false positives, and this option allow to resolve them. .TP .B \-l, \-\-log FILE @@ -1036,7 +1036,7 @@ any wasted space. Note also, that any file in data disks that is excluded from the parity computation, counts for its size as extra parity space for such data disk. .SS autosave SIZE_IN_GIBIBYTES -Automatically save the state when synching after the specified amount +Automatically save the state when syncing after the specified amount of GiB processed. This option is useful to avoid to restart from scratch long \[dq]sync\[dq] commands interrupted by a machine crash, or any other event that @@ -1353,7 +1353,7 @@ For example, if you have moved away some files from other disks after the last \ you can retry to put them inplace, and retry the \[dq]fix\[dq]. .PP If you are satisfied of the recovering, you can now proceed further, -but take care that after synching you will no more able to retry the +but take care that after syncing you will no more able to retry the \[dq]fix\[dq] command! .SS STEP 3 \-> Check As paranoid check, you can now run a \[dq]check\[dq] command to ensure that everything diff --git a/snapraid.d b/snapraid.d index 223b3286..ff2f504e 100644 --- a/snapraid.d +++ b/snapraid.d @@ -525,7 +525,7 @@ Options This happens when the system is under heavy pressure due all disks spinning and CPU busy, and in such extreme conditions, if your machine has a latent hardware problem, it's possible to - encouter silent errors what cannot be detected because the data + encounter silent errors what cannot be detected because the data is not yet hashed. To avoid this risk, you can enable the "pre-hash" mode and have all the data hashed two times to ensure its integrity. @@ -584,14 +584,14 @@ Options option allows you to continue anyway. -N, --force-nocopy - In the "sync" command, disables the copy detection optimization. - Withouth this option SnapRAID assumes that files with the + In the "sync" command, disables the copy detection heuristic. + Without this option SnapRAID assumes that files with the same name, size, and nanosecond timestamp are copies with the same data. This allows to identify copied files from one dir to another, and to reuse the already computed hash information to detect silent errors in the copy. - This behaviour, in some rare cases, may result in false positives, + This behavior, in some rare cases, may result in false positives, and this option allow to resolve them. -l, --log FILE @@ -795,7 +795,7 @@ Configuration computation, counts for its size as extra parity space for such data disk. autosave SIZE_IN_GIBIBYTES - Automatically save the state when synching after the specified amount + Automatically save the state when syncing after the specified amount of GiB processed. This option is useful to avoid to restart from scratch long "sync" commands interrupted by a machine crash, or any other event that @@ -978,7 +978,7 @@ Recovering you can retry to put them inplace, and retry the "fix". If you are satisfied of the recovering, you can now proceed further, - but take care that after synching you will no more able to retry the + but take care that after syncing you will no more able to retry the "fix" command! STEP 3 -> Check diff --git a/snapraid.txt b/snapraid.txt index 48654aab..bf8e923e 100644 --- a/snapraid.txt +++ b/snapraid.txt @@ -570,7 +570,7 @@ SnapRAID provides the following options: This happens when the system is under heavy pressure due all disks spinning and CPU busy, and in such extreme conditions, if your machine has a latent hardware problem, it's possible to - encouter silent errors what cannot be detected because the data + encounter silent errors what cannot be detected because the data is not yet hashed. To avoid this risk, you can enable the "pre-hash" mode and have all the data hashed two times to ensure its integrity. @@ -629,14 +629,14 @@ SnapRAID provides the following options: option allows you to continue anyway. -N, --force-nocopy - In the "sync" command, disables the copy detection optimization. - Withouth this option SnapRAID assumes that files with the + In the "sync" command, disables the copy detection heuristic. + Without this option SnapRAID assumes that files with the same name, size, and nanosecond timestamp are copies with the same data. This allows to identify copied files from one dir to another, and to reuse the already computed hash information to detect silent errors in the copy. - This behaviour, in some rare cases, may result in false positives, + This behavior, in some rare cases, may result in false positives, and this option allow to resolve them. -l, --log FILE @@ -859,7 +859,7 @@ Note also, that any file in data disks that is excluded from the parity computation, counts for its size as extra parity space for such data disk. ---- 7.8.1 autosave SIZE_IN_GIBIBYTES ---- -Automatically save the state when synching after the specified amount +Automatically save the state when syncing after the specified amount of GiB processed. This option is useful to avoid to restart from scratch long "sync" commands interrupted by a machine crash, or any other event that @@ -1054,7 +1054,7 @@ For example, if you have moved away some files from other disks after the last " you can retry to put them inplace, and retry the "fix". If you are satisfied of the recovering, you can now proceed further, -but take care that after synching you will no more able to retry the +but take care that after syncing you will no more able to retry the "fix" command! 9.3 STEP 3 -> Check