From ef4bed47e4d4cbe88471d0bbb4954285af826691 Mon Sep 17 00:00:00 2001
From: Andrea Mazzoleni <amadvance@gmail.com>
Date: Tue, 7 Jul 2026 12:23:15 +0200
Subject: [PATCH] Update TODO

---
 TODO | 35 +++++++++++++++++++++++++----------
 1 file changed, 25 insertions(+), 10 deletions(-)

diff --git a/TODO b/TODO
index 9fb691e5..de56cde3 100644
--- a/TODO
+++ b/TODO
@@ -3,7 +3,13 @@ SnapRAID TODO
 
 This is the list of TODO items for SnapRAID.
 
-- Next
+15.x Releases
+=============
+
+All done ?
+
+16.x Releases
+=============
 
 * Use statx() instead of lstat() when scanning directories.
 
@@ -16,6 +22,8 @@ This is the list of TODO items for SnapRAID.
 
 * Restore directory timestamps.
 
+* Enable MuseAir and disable random seed
+
 * Check Reliability Test. We can derive Failure probability from MBTF
 https://github.com/linuxhw/SMART
 https://github.com/linuxhw/EnterpriseDrive
@@ -32,6 +40,9 @@ The goal is a filelist that, for every file, includes full paths to the dependen
 on other data disks needed to repair that file (in addition to the parity data).
 See: https://sourceforge.net/p/snapraid/discussion/1677233/thread/6e872fdae0/
 
+Future
+======
+
 - Minor
 
 * Add a new scrub option for checking recent blocks. Like -n, --newer-than.
@@ -127,10 +138,14 @@ 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.
 
-* Rename sync->backup and fix->restore. It seems to me a naming expressing
+* Rename sync->backup and fix->restore/recover. It seems to me a naming expressing
 better the meaning of the commands. But not yet sure.
 
-- Pooling
+
+Rejected TODO
+=============
+
+This is a list of rejected TODO items.
 
 * Add a new "commit" command to move changes from the pool to the array.
 It should:
@@ -144,8 +159,7 @@ but kept in the same disk of the array.
 - Detect deletes, and move file in the array to a "/trash/" directory
 of the same disk. For safety no real deletion is done.
 File with the same name will get an extra extension like ".1", ".2".
-
-- Major
+- MergerFS is anyway better
 
 * Allocate parity minimizing concurrent use of it
 Each parity allocation should check for a parity
@@ -157,11 +171,12 @@ See: https://sourceforge.net/p/snapraid/discussion/1677233/thread/1797bf7d/
 enough parity, as the benefit of existing parity is maximized.
 - Possible increase of fragmentation of parity allocation
 - No real benefit when the array is filled
-
-Rejected TODO
-=============
-
-This is a list of rejected TODO items.
+- Slowing down operation that have to check the whole array.
+  10 disk at 10% utilization, will use the full parity, requiring to
+  read and write it completly. Essentially doubling the amount of data
+  needed to be read or written.
+- Rotating disks are faster at low sector addresses, allocating high
+  parity will slow down disks that could be instead faster.
 
 * Use a memory mapped file to read the content file
 - Tried. No speed gain.