mirror of
https://github.com/amadvance/snapraid.git
synced 2026-10-25 18:40:19 -04:00
Some documentation changes.
This commit is contained in:
Andrea Mazzoleni
parent
10511499aa
commit
4d3d393586
6 changed files with 63 additions and 57 deletions
16
HISTORY
16
HISTORY
|
|
@ -3,15 +3,19 @@ SnapRAID HISTORY
|
|||
|
||||
1.1 2011/5
|
||||
==========
|
||||
* Fixed a bug in check when detecting garbage data over the expected end of the file.
|
||||
* Added RAID6 support and allow to specify multiple content files.
|
||||
* Added filtering include logic, where anything not explicitely included is excluded.
|
||||
* Fixed a bug in the check command when detecting garbage data over the
|
||||
expected end of the file. No special action is required to update.
|
||||
* Added RAID6 support, and allow to specify multiple content files.
|
||||
* Added a filtering include logic, where anything not explicitely included
|
||||
is excluded.
|
||||
* Changed the default checksum to Murmur3 hash. It's a lot faster than MD5.
|
||||
You can check the speed with the "snapraid -T" command.
|
||||
MD5 is still supported for backward compatibility.
|
||||
* The check command returns with an error code if any kind of error is present.
|
||||
Previously it was only if unrecoverable errors were present.
|
||||
* Opening the files in sequential mode in Windows. This should give
|
||||
a light speedup in Windows.
|
||||
Previously it was returning an error only if unrecoverable errors were
|
||||
present.
|
||||
* Opening the files in sequential mode in Windows. This should give a light
|
||||
speedup in Windows.
|
||||
|
||||
1.0 2011/4
|
||||
==========
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ SnapRAID INSTALL for Windows
|
|||
|
||||
To start using SnapRAID you have to change the example configuration
|
||||
file snapraid.conf.example to fit your needs and copy it with the
|
||||
name snapraid.conf in the directory where you executes snapraid.exe.
|
||||
name snapraid.conf in the directory where you run snapraid.exe.
|
||||
|
||||
To get more help, see the "Getting Started" section in snapraid.txt.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
dnl Process this file with autoconf to produce a configure script.
|
||||
AC_PREREQ([2.65])
|
||||
AC_INIT([snapraid], [1.1b1], [], [], [http://snapraid.sourceforge.net])
|
||||
AC_INIT([snapraid], [1.1], [], [], [http://snapraid.sourceforge.net])
|
||||
AM_INIT_AUTOMAKE([foreign no-dependencies -Wall])
|
||||
AC_CONFIG_SRCDIR([snapraid.c])
|
||||
AC_CONFIG_HEADER([config.h])
|
||||
|
|
|
|||
34
snapraid.1
34
snapraid.1
|
|
@ -78,7 +78,7 @@ amount of the changed or deleted files, from the last sync operation.
|
|||
This happens even if the files changed or deleted are not in the
|
||||
failed disk.
|
||||
New added files don\(cqt prevent the recovering of the already existing
|
||||
files. You may only lose the just added files, if they were on the failed
|
||||
files. You may only lose the just added files, if they are on the failed
|
||||
disk.
|
||||
.PP
|
||||
This is the reason because SnapRAID is better suited for data that
|
||||
|
|
@ -100,10 +100,6 @@ It\(cqs able to recover damages only from up to two disks.
|
|||
With a Backup you are able to recover from a complete
|
||||
failure of the whole disk array.
|
||||
.IP \(bu
|
||||
It identifies changes checking file time and size. If you have
|
||||
a program that arbitrarily restore the file time, such changes
|
||||
are not detected if the size doesn\(cqt change.
|
||||
.IP \(bu
|
||||
Only the file data is saved. Permissions, time, extended attributes,
|
||||
hard\(hylinks, symbolic\(hylinks are not saved.
|
||||
.PD
|
||||
|
|
@ -372,20 +368,20 @@ it doesn\(cqt get fragmented, improving the performance.
|
|||
This option is optional and it can be used only one time.
|
||||
.TP
|
||||
.B content FILE
|
||||
Defines the file to use to store the list and checksum of the
|
||||
content of your disk array.
|
||||
It can be placed in the same disk of the parity and q\(hyaparity file,
|
||||
or better in another disk, but NOT in a data disk of the array.
|
||||
Defines the file to use to store the list and checksums of all the
|
||||
files present in your disk array.
|
||||
It can be placed in the same disk of the parity and q\(hyaparity files,
|
||||
but NOT in a data disk of the array.
|
||||
This option is mandatory and it can be used more time to save
|
||||
more copies of the same files.
|
||||
It\(cqs suggested to store at least one copy for each parity disk.
|
||||
One more doesn\(cqt hurt, just in case you lose all the parity disks,
|
||||
and you to be still able to check the data integrity.
|
||||
and you want to be still able to check the data integrity.
|
||||
.TP
|
||||
.B disk NAME DIR
|
||||
Defines the name and the mount point of the disks of the array.
|
||||
NAME is used to identify the disk, and it must be unique.
|
||||
DIR is the mount point of the disk in the file\(hysystem.
|
||||
DIR is the mount point of the disk in the filesystem.
|
||||
You can change the mount point as you like, as long you
|
||||
keep the NAME fixed.
|
||||
The specification order is also important, if you change it,
|
||||
|
|
@ -397,8 +393,9 @@ You should use one option for each disk of the array.
|
|||
.B include PATTERN
|
||||
Defines the file or directory patterns to exclude and include
|
||||
in the sync process.
|
||||
All the patterns are processed in the specified order, and
|
||||
we get the result of the first pattern that matches.
|
||||
All the patterns are processed in the specified order.
|
||||
If the first pattern that matches is an \(a"exclude\(a" one, the file
|
||||
is excluded. If it\(cqs an \(a"include\(a" one the file is included.
|
||||
If no pattern matches, the file is excluded if the last pattern
|
||||
is an \(a"include\(a", or included if the last pattern is an \(a"exclude\(a".
|
||||
See the PATTERN section for more details in the
|
||||
|
|
@ -406,8 +403,8 @@ pattern specifications.
|
|||
This option can be used many times.
|
||||
.TP
|
||||
.B block_size SIZE_IN_KIBIBYTES
|
||||
Defines the basic block size in kibi bytes of
|
||||
the redundancy blocks. Where one kibi bytes is 1024 bytes.
|
||||
Defines the basic block size in kibi bytes of the redundancy
|
||||
blocks. Where one kibi bytes is 1024 bytes.
|
||||
The default is 256 and it should work for most conditions.
|
||||
You could increase this value if you do not have enough RAM
|
||||
memory to run SnapRAID.
|
||||
|
|
@ -629,18 +626,20 @@ SnapRAID stores the list and checksums of your files in the content file.
|
|||
.PP
|
||||
It\(cqs a text file, listing all the files present in your disk array,
|
||||
with all the checksums to verify their integrity.
|
||||
.PP
|
||||
You do not need to understand its format, but it\(cqs described here
|
||||
for documentation.
|
||||
.PP
|
||||
This file is read and written by the \(a"sync\(a" command, and only read by
|
||||
\(a"fix\(a" and \(a"check\(a".
|
||||
You should never change it manually, although the format of this file
|
||||
is described here.
|
||||
.TP
|
||||
.B blk_size SIZE
|
||||
Defines the size of the block in bytes. It must match the size
|
||||
defined in the configuration file.
|
||||
.TP
|
||||
.B checksum CHECKSUM
|
||||
Defines the checksum kind used. It can be \(a"md5\(a" or \(a"murmur3\(a".
|
||||
.TP
|
||||
.B file DISK SIZE TIME INODE PATH
|
||||
Defines a file in the specified DISK.
|
||||
The INODE number is used to identify the file in the \(a"sync\(a"
|
||||
|
|
@ -670,6 +669,7 @@ and q\(hyparity files.
|
|||
.PP
|
||||
They are binary files, containing the computed redundancy of all the
|
||||
blocks defined in the \(a"content\(a" file.
|
||||
.PP
|
||||
You do not need to understand its format, but it\(cqs described here
|
||||
for documentation.
|
||||
.PP
|
||||
|
|
|
|||
33
snapraid.d
33
snapraid.d
|
|
@ -49,7 +49,7 @@ Limitations
|
|||
This happens even if the files changed or deleted are not in the
|
||||
failed disk.
|
||||
New added files don't prevent the recovering of the already existing
|
||||
files. You may only lose the just added files, if they were on the failed
|
||||
files. You may only lose the just added files, if they are on the failed
|
||||
disk.
|
||||
|
||||
This is the reason because SnapRAID is better suited for data that
|
||||
|
|
@ -66,9 +66,6 @@ Limitations
|
|||
* It's able to recover damages only from up to two disks.
|
||||
With a Backup you are able to recover from a complete
|
||||
failure of the whole disk array.
|
||||
* It identifies changes checking file time and size. If you have
|
||||
a program that arbitrarily restore the file time, such changes
|
||||
are not detected if the size doesn't change.
|
||||
* Only the file data is saved. Permissions, time, extended attributes,
|
||||
hard-links, symbolic-links are not saved.
|
||||
|
||||
|
|
@ -267,20 +264,20 @@ Configuration
|
|||
This option is optional and it can be used only one time.
|
||||
|
||||
=content FILE
|
||||
Defines the file to use to store the list and checksum of the
|
||||
content of your disk array.
|
||||
It can be placed in the same disk of the parity and q-aparity file,
|
||||
or better in another disk, but NOT in a data disk of the array.
|
||||
Defines the file to use to store the list and checksums of all the
|
||||
files present in your disk array.
|
||||
It can be placed in the same disk of the parity and q-aparity files,
|
||||
but NOT in a data disk of the array.
|
||||
This option is mandatory and it can be used more time to save
|
||||
more copies of the same files.
|
||||
It's suggested to store at least one copy for each parity disk.
|
||||
One more doesn't hurt, just in case you lose all the parity disks,
|
||||
and you to be still able to check the data integrity.
|
||||
and you want to be still able to check the data integrity.
|
||||
|
||||
=disk NAME DIR
|
||||
Defines the name and the mount point of the disks of the array.
|
||||
NAME is used to identify the disk, and it must be unique.
|
||||
DIR is the mount point of the disk in the file-system.
|
||||
DIR is the mount point of the disk in the filesystem.
|
||||
You can change the mount point as you like, as long you
|
||||
keep the NAME fixed.
|
||||
The specification order is also important, if you change it,
|
||||
|
|
@ -291,8 +288,9 @@ Configuration
|
|||
=include PATTERN
|
||||
Defines the file or directory patterns to exclude and include
|
||||
in the sync process.
|
||||
All the patterns are processed in the specified order, and
|
||||
we get the result of the first pattern that matches.
|
||||
All the patterns are processed in the specified order.
|
||||
If the first pattern that matches is an "exclude" one, the file
|
||||
is excluded. If it's an "include" one the file is included.
|
||||
If no pattern matches, the file is excluded if the last pattern
|
||||
is an "include", or included if the last pattern is an "exclude".
|
||||
See the PATTERN section for more details in the
|
||||
|
|
@ -300,8 +298,8 @@ Configuration
|
|||
This option can be used many times.
|
||||
|
||||
=block_size SIZE_IN_KIBIBYTES
|
||||
Defines the basic block size in kibi bytes of
|
||||
the redundancy blocks. Where one kibi bytes is 1024 bytes.
|
||||
Defines the basic block size in kibi bytes of the redundancy
|
||||
blocks. Where one kibi bytes is 1024 bytes.
|
||||
The default is 256 and it should work for most conditions.
|
||||
You could increase this value if you do not have enough RAM
|
||||
memory to run SnapRAID.
|
||||
|
|
@ -414,18 +412,20 @@ Content
|
|||
|
||||
It's a text file, listing all the files present in your disk array,
|
||||
with all the checksums to verify their integrity.
|
||||
|
||||
You do not need to understand its format, but it's described here
|
||||
for documentation.
|
||||
|
||||
This file is read and written by the "sync" command, and only read by
|
||||
"fix" and "check".
|
||||
You should never change it manually, although the format of this file
|
||||
is described here.
|
||||
|
||||
=blk_size SIZE
|
||||
Defines the size of the block in bytes. It must match the size
|
||||
defined in the configuration file.
|
||||
|
||||
=checksum CHECKSUM
|
||||
Defines the checksum kind used. It can be "md5" or "murmur3".
|
||||
|
||||
=file DISK SIZE TIME INODE PATH
|
||||
Defines a file in the specified DISK.
|
||||
The INODE number is used to identify the file in the "sync"
|
||||
|
|
@ -456,6 +456,7 @@ Parity
|
|||
|
||||
They are binary files, containing the computed redundancy of all the
|
||||
blocks defined in the "content" file.
|
||||
|
||||
You do not need to understand its format, but it's described here
|
||||
for documentation.
|
||||
|
||||
|
|
|
|||
33
snapraid.txt
33
snapraid.txt
|
|
@ -59,7 +59,7 @@ amount of the changed or deleted files, from the last sync operation.
|
|||
This happens even if the files changed or deleted are not in the
|
||||
failed disk.
|
||||
New added files don't prevent the recovering of the already existing
|
||||
files. You may only lose the just added files, if they were on the failed
|
||||
files. You may only lose the just added files, if they are on the failed
|
||||
disk.
|
||||
|
||||
This is the reason because SnapRAID is better suited for data that
|
||||
|
|
@ -76,9 +76,6 @@ Other limitations are:
|
|||
* It's able to recover damages only from up to two disks.
|
||||
With a Backup you are able to recover from a complete
|
||||
failure of the whole disk array.
|
||||
* It identifies changes checking file time and size. If you have
|
||||
a program that arbitrarily restore the file time, such changes
|
||||
are not detected if the size doesn't change.
|
||||
* Only the file data is saved. Permissions, time, extended attributes,
|
||||
hard-links, symbolic-links are not saved.
|
||||
|
||||
|
|
@ -289,20 +286,20 @@ It should contains the following options:
|
|||
This option is optional and it can be used only one time.
|
||||
|
||||
content FILE
|
||||
Defines the file to use to store the list and checksum of the
|
||||
content of your disk array.
|
||||
It can be placed in the same disk of the parity and q-aparity file,
|
||||
or better in another disk, but NOT in a data disk of the array.
|
||||
Defines the file to use to store the list and checksums of all the
|
||||
files present in your disk array.
|
||||
It can be placed in the same disk of the parity and q-aparity files,
|
||||
but NOT in a data disk of the array.
|
||||
This option is mandatory and it can be used more time to save
|
||||
more copies of the same files.
|
||||
It's suggested to store at least one copy for each parity disk.
|
||||
One more doesn't hurt, just in case you lose all the parity disks,
|
||||
and you to be still able to check the data integrity.
|
||||
and you want to be still able to check the data integrity.
|
||||
|
||||
disk NAME DIR
|
||||
Defines the name and the mount point of the disks of the array.
|
||||
NAME is used to identify the disk, and it must be unique.
|
||||
DIR is the mount point of the disk in the file-system.
|
||||
DIR is the mount point of the disk in the filesystem.
|
||||
You can change the mount point as you like, as long you
|
||||
keep the NAME fixed.
|
||||
The specification order is also important, if you change it,
|
||||
|
|
@ -313,8 +310,9 @@ It should contains the following options:
|
|||
include PATTERN
|
||||
Defines the file or directory patterns to exclude and include
|
||||
in the sync process.
|
||||
All the patterns are processed in the specified order, and
|
||||
we get the result of the first pattern that matches.
|
||||
All the patterns are processed in the specified order.
|
||||
If the first pattern that matches is an "exclude" one, the file
|
||||
is excluded. If it's an "include" one the file is included.
|
||||
If no pattern matches, the file is excluded if the last pattern
|
||||
is an "include", or included if the last pattern is an "exclude".
|
||||
See the PATTERN section for more details in the
|
||||
|
|
@ -322,8 +320,8 @@ It should contains the following options:
|
|||
This option can be used many times.
|
||||
|
||||
block_size SIZE_IN_KIBIBYTES
|
||||
Defines the basic block size in kibi bytes of
|
||||
the redundancy blocks. Where one kibi bytes is 1024 bytes.
|
||||
Defines the basic block size in kibi bytes of the redundancy
|
||||
blocks. Where one kibi bytes is 1024 bytes.
|
||||
The default is 256 and it should work for most conditions.
|
||||
You could increase this value if you do not have enough RAM
|
||||
memory to run SnapRAID.
|
||||
|
|
@ -442,18 +440,20 @@ SnapRAID stores the list and checksums of your files in the content file.
|
|||
|
||||
It's a text file, listing all the files present in your disk array,
|
||||
with all the checksums to verify their integrity.
|
||||
|
||||
You do not need to understand its format, but it's described here
|
||||
for documentation.
|
||||
|
||||
This file is read and written by the "sync" command, and only read by
|
||||
"fix" and "check".
|
||||
You should never change it manually, although the format of this file
|
||||
is described here.
|
||||
|
||||
blk_size SIZE
|
||||
Defines the size of the block in bytes. It must match the size
|
||||
defined in the configuration file.
|
||||
|
||||
checksum CHECKSUM
|
||||
Defines the checksum kind used. It can be "md5" or "murmur3".
|
||||
|
||||
file DISK SIZE TIME INODE PATH
|
||||
Defines a file in the specified DISK.
|
||||
The INODE number is used to identify the file in the "sync"
|
||||
|
|
@ -487,6 +487,7 @@ and q-parity files.
|
|||
|
||||
They are binary files, containing the computed redundancy of all the
|
||||
blocks defined in the "content" file.
|
||||
|
||||
You do not need to understand its format, but it's described here
|
||||
for documentation.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue