mirror of
https://github.com/amadvance/snapraid.git
synced 2026-10-26 10:51:54 -04:00
69 lines
2.4 KiB
Text
69 lines
2.4 KiB
Text
SnapRAID TODO
|
|
=============
|
|
|
|
This is a list of possible TODO items for SnapRAID. The order is not relevant.
|
|
|
|
* If a file cannot be synched, for example because it was changing, of it
|
|
the file name cannot be supported, it's better to do not stop the sync process.
|
|
The sync process should stop only if the error could be caused by a disk
|
|
corruption.
|
|
|
|
* Adds a checksum for the content file. When reading if the file is invalid,
|
|
skip to another.
|
|
|
|
* Easy way to find duplicates using the computed hash.
|
|
|
|
* Easy way to find files using a specified block.
|
|
|
|
* Implement an "undelete" command to recover missing files, without the
|
|
integrity check of the existing ones.
|
|
It should restore only missing files, without recovering modified ones
|
|
or check validity of data of existing ones.
|
|
|
|
* Rename sync->backup and fix->restore. It seems to me a naming expressing
|
|
better the meaning of the commands. But not yet sure.
|
|
|
|
* Allow to filter the files to check/fix based on the drive where they reside.
|
|
|
|
* Filtered out files should be opened in read-only mode.
|
|
|
|
* When fixing, overwrite the present file only if the backuped one can be
|
|
completely restored.
|
|
|
|
* Support to backup also symlinks.
|
|
|
|
Delayed TODO
|
|
============
|
|
|
|
This is a list of low priority TODO items. The order is not relevant.
|
|
|
|
* Recognizes that a file is moved from one disk to another, and if the parity
|
|
data doesn't overlap, do not recompute it.
|
|
- It's going to work only in RAID5 mode and only in special cases.
|
|
|
|
* Uses the O_NOATIME flag if run as 'root'.
|
|
- A better solution is to mount the disk with the "noatime" mount option.
|
|
Note also that at mount time you can also use the "nodiratime", and this is
|
|
the only way to specify it.
|
|
|
|
* Implements a multithread sync command.
|
|
- At now it's questionable if it will result in a performance improvment.
|
|
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.
|
|
Also, all the file operations are already done in background by the OS,
|
|
so no improvement is expect from this side.
|
|
|
|
* The SSE2 RAID6 computation may be slower than the MMX version.
|
|
See for example this case on a AMD Zacate APU E-350 1.6GHz:
|
|
memset 1812 [MB/s]
|
|
MD5 252 [MB/s]
|
|
Murmur3 1116 [MB/s]
|
|
RAID5 int32x2 1692 [MB/s]
|
|
RAID5 mmxx2 1745 [MB/s]
|
|
RAID5 sse2x2 2481 [MB/s]
|
|
RAID6 int32x2 807 [MB/s]
|
|
RAID6 mmxx2 1304 [MB/s]
|
|
RAID6 sse2x2 787 [MB/s]
|
|
- Waiting for other similar reports. A single one may be a spurious case.
|
|
|