mirror of
https://github.com/amadvance/snapraid.git
synced 2026-10-26 10:51:54 -04:00
104 lines
3.5 KiB
Text
104 lines
3.5 KiB
Text
SnapRAID TODO
|
|
=============
|
|
|
|
This is the list of TODO items for SnapRAID.
|
|
|
|
- v1.7
|
|
|
|
* When scanning, ensure that each file is in the expected disk.
|
|
|
|
* If fix fails for unrecoverable parts, rename such files adding ".unrecoverable".
|
|
|
|
* Check and fix also empty file.
|
|
|
|
* When fixing, before overwriting the present file, make a copy of it just in
|
|
case that the original file cannot be completely recovered.
|
|
We can always open files in read-only mode, if a write is required, we close it,
|
|
rename it to with a .bak extension, and rewrite it up to the required size.
|
|
The same for symlink if a file with the same name exist or viceversa.
|
|
|
|
- v1.8
|
|
|
|
* Check why saving the content files is so slow. fprintf() is the bottleneck.
|
|
|
|
* Put the content files in the data disks in the default configuration file.
|
|
|
|
* Easy way to find duplicates using the computed hash.
|
|
|
|
* Easy way to find files using a specified block.
|
|
|
|
* Adds a checksum for the content file. When reading if the file is invalid,
|
|
skip to another.
|
|
|
|
* Add an option to exclude "hidden" file. In Windows files with the HIDDEN attributes,
|
|
in Unix files starting with '.'.
|
|
|
|
- v2.x
|
|
|
|
* Remove the old MD5 support.
|
|
|
|
* 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.
|
|
|
|
- v3.x
|
|
|
|
* In the content file, for each block store the last time the hash was checked
|
|
with both "check" and also "sync".
|
|
It will allow to define a new "check" command checking only aged blocks
|
|
and skipping recently checked ones.
|
|
This could be problematic for the increased memory occupation, and the need
|
|
to update the content file also in check.
|
|
|
|
* Save the content file in compressed .gz format to save space.
|
|
|
|
* In the content file save the timestap 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,
|
|
resulting in wrong data.
|
|
But if the sync process is killed we need a way to resyncronize them.
|
|
|
|
|
|
Rejected TODO
|
|
=============
|
|
|
|
This is a list of rejected TODO items.
|
|
|
|
* 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]
|
|
- It happens in some systems. At now not an high priority issue.
|
|
|