Importing old TODO file into the new repo

diff --git a/Documentation/device-mapper/dedup-TODO.txt b/Documentation/device-mapper/dedup-TODO.txt
new file mode 100644 (file)
index 0000000..888f37e
--- /dev/null
+++ b/Documentation/device-mapper/dedup-TODO.txt
@@ -0,0 +1,85 @@
+*** Tasks to complete for v2 ***
+
+- Address Bart Van Asshche's comment:
+
+"Regarding that documentation: shouldn't the on-disk data structures be
+documented? Shouldn't it be documented how dm-dedup recovers from a power
+failure? Since different storage devices are used for data and meta-data
+recovery from a power failure is nontrivial. How is it e.g.  guaranteed if a
+data block has been made persistent (e.g. via REQ_FUA) and the refcount is
+increased for that data block that neither the data nor the metadata for that
+data block is lost if a power failure occurs?"
+
+- Address Alasdair Kergon's comment:
+
+"Just a really quick comment before people look at this any further: there is
+a standard format we use for Documentation files now.
+
+Please change this into the same format as verity.txt or cache.txt.
+
+Remember, once this is in the tree, it is the Documentation file and the
+comments in the code itself that people see rather than the patch headers."
+
+- Address comments from Mike Snitzer:
+
+"I did start in on dm-dedup a month or so ago by staging a baseline of
+your work in a branch here:
+http://git.kernel.org/cgit/linux/kernel/git/snitzer/linux.git/log/?h=dm-dedup
+
+I found a few things that didn't look right, but they are more
+DM-specific mechanics and not anything to do with your approach for
+accomplishing dedup, see the FIXMEs I added to the documentation file in
+this commit:
+http://git.kernel.org/cgit/linux/kernel/git/snitzer/linux.git/commit/?h=dm-dedup&id=fed855928fba624c7a494db7519c37dcc7c9492d
+
+The reconstruct= param isn't needed.  In both dm-thinp and dm-cache we
+use __superblock_all_zeroes to checks if the metadata device's
+superblock is all zeros.  Ideally dm-dedup would do something
+comparable."
+
+"> 2) Few people mentioned that our documentation need to be formatted
+> better and be more detailed. We'll address this.
+
+Yes, it could be more comprehensive.  And it would be nice if it were
+updated to have the same kind of sections/flow that other targets'
+Documentation/device-mapper/ files have (e.g. cache.txt and
+thin-provisioning.txt)."
+
+- Basic testing framework
+
+*** Tasks to complete for v3 ***
+
+- Locking need to be verified (and most probably redesigned)
+  if multiple worker threads are used.
+- Validate superblock (and other blocks?) using dm_block_validator
+
+*** Task pool as of April 2014 ***
+
+- Add integrity checking to testing framework
+- Verify and test code for multiple instances creation.
+- Verify how the code works for block sizes other than 4KB.
+- Verify how the code works for hash sizes other than MD5.
+- Right now, inram backend marks a hash table entry as empty
+  by setting entry's bytes to EMPTY_ENTRY value. Not only
+  it is not safe, but also causes high CPU overhead.
+- Linear kvs in inram backend supports only 64bit keys.
+  Should support all keys that are less than 64bits.
+- Add more statistics: e.g.,  hash found, LBN found.
+- Currently only one linear and sparse KVSs are supported
+  per metadata backend. We probably should support an
+  arbitrary number of KVSs per backend.
+- Revise error handling.
+- seems like check_and_modify() (and related) check for
+  the mis-sized requests (smaller than chunk size), but not
+  for the mis-aligned ones.
+- Read-on-write handling looks insane
+- Revise mark-and-sweep
+- Change strcpy to strncpy and made other related changes in the code
+- Restore on-disk data statistics on target instance reconstruction
+- Respect SYNC/BARRIER flag
+- Better flushrq policy
+- implement set_private_data and get_private_data methods in CBT backend
+- Make sure that we don't acknowledge writes before metadata is updated
+  (for REQ_FLUSH and REQ_FUA requests)
+- Do right things on REQ_DISCARD
+- Support meta-data backend registration