rt/snapraid
1
0
Fork 0
mirror of https://github.com/amadvance/snapraid.git synced 2026-10-26 02:49:02 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update TODO items

Browse source
This commit is contained in:
Andrea Mazzoleni 2016-01-02 17:37:51 +01:00
parent 1d7ba9a147
commit d796760e71
1 changed files with 14 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

19
TODO
View file

@ -5,6 +5,14 @@ This is the list of TODO items for SnapRAID.
- Next
* Handle someway moved file to a different disk.
In case of a silent error it should be possible to recover.
Likely an automatic prehash that verifies *only* moved/copied files,
and delay the content file saving only if everything is good.
It can be very similar at prehash, but checking only REP blocks
that already have a hash.
https://sourceforge.net/p/snapraid/discussion/1677233/thread/6615f0e3/
- Minor
* Some programs are misusing the FILE_ATTRIBUTE_TEMPORARY.
@ -99,8 +107,6 @@ File with the same name will get an extra extension like ".1", ".2".
- Major
* Use threads to scan all the disks at the same time.
* https://sourceforge.net/p/snapraid/discussion/1677233/thread/2cb97e8a/
Have two hashes for each file. One for the first segment, that may use only a part of the first parity block.
And a second hash that takes care of the final segment, also using only part of a parity block.
@ -138,6 +144,10 @@ Rejected TODO
This is a list of rejected TODO items.
* Use threads to scan all the disks at the same time.
After recent Windows changes it seems fast enough even
with a mono thread implementation.
* Enable storing of creation time NTFS, crtime/birth time EXT4.
But see: http://unix.stackexchange.com/questions/50177/birth-is-empty-on-ext4
coreutils stat has an example, but it doesn't work in Linux (see lib/stat-time.h)
@ -264,13 +274,12 @@ sys 0m4.398s
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.
* Implements a multithread sync command to share HASH and RAID computations
to different CPUs.
- 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.
Also, all the file operations are already done in background by the OS,
so no improvement is expect from this side.
* 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