mirror of
https://github.com/amadvance/snapraid.git
synced 2026-10-26 10:51:54 -04:00
114 lines
4.2 KiB
Text
114 lines
4.2 KiB
Text
SnapRAID TODO
|
|
=============
|
|
|
|
This is the list of TODO items for SnapRAID.
|
|
|
|
- v1.8
|
|
|
|
* In fix an existing symlink with the same name of a file to be recovered may stop
|
|
the process making the create() operation to fail.
|
|
|
|
* Check why saving the content files is so slow. fprintf() is the bottleneck.
|
|
|
|
* Save all the content files in parallel. We can use a single thread writing
|
|
the same stuffs to all the file descriptors.
|
|
This is still safe, as the written data is going to replace the old one
|
|
with an atomic rename operation.
|
|
|
|
* 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.
|
|
|
|
* A new 'init' command to differentiate the first 'sync' operation.
|
|
This 'init' will work also without a content file, and parity files.
|
|
Instead 'sync' will require all of them.
|
|
This will also help when running with the parity filesystem unmounted.
|
|
|
|
* 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.
|
|
|
|
* 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.
|
|
|
|
* Triple parity also called RAID-TP. We can implement it in a compatible way
|
|
with the existing RAID-5 and RAID-6 definining a new r-parity file.
|
|
See http://blogs.oracle.com/ahl/entry/triple_parity_raid_z and
|
|
http://thread.gmane.org/gmane.linux.raid/34195/focus=34236
|
|
|
|
* 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.
|
|
|