Put the Markdown punch list on the right branch.

1 files changed, 102 insertions, 0 deletions

diff --git a/doc/VFD_SWMR_Punch_List.md b/doc/VFD_SWMR_Punch_List.md
new file mode 100644
index 0000000..dd0496e
--- /dev/null
+++ b/doc/VFD_SWMR_Punch_List.md
@@ -0,0 +1,102 @@
+VFD SWMR Punch List
+
+4 November 2019
+
+1.  Design optimizations in index writes. Perhaps write deltas only,
+    with a full index every n ticks?
+
+2.  Design work for NFS and object store versions.
+
+3.  Design work for journaling variation.
+
+4.  Add support for opening multiple files in either VFD SWMR writer or
+    VFD SWMR writer mode. See addition of the EOT queue in section 3.2.2
+    of the RFC, and related changes in sections 3.3 and 3.3.2.
+
+5.  Add the pb\_expansion\_threshold field to the
+    H5F\_vfd\_swmr\_config\_t structure, and update
+    H5Pset\_vfd\_swmr\_config()and
+    H5Pget\_vfd\_swmr\_config()accordingly.
+
+6.  Implement end tick now API call. See section 3.1.2 of the RFC for
+    specifications.
+
+7.  Implement enable / disable EOT call. See section 3.1.3 of the RFC
+    for specifications.
+
+8.  Implement option to flush raw data as part of EOT -- write
+    performance test to characterize the performance hit.
+
+9.  Move VFD SWMR specific H5F code to its own file -- say
+    H5Fvfd\_swmr.c.
+
+10. Update the new page buffer to support the pb\_expansion\_threshold,
+    and trigger an early end of tick if the threshold is exceeded.
+
+11. Modify metadata file write call to allow the location of the index
+    to float and thus be of arbitrary size.
+
+12. Add code to remove entries from the index after they have been
+    written to the HDF5 file, and have not been modified for at least
+    max\_lag ticks.
+
+13. Tidy short cuts in the initial implementation. These include:
+
+    -   Odd behavior in the superblock refresh routine (see comments in
+        code). Figure out what is going on, and then either bypass the
+        issue or fix it as seems appropriate.
+
+    -   Comment H5F\_vfd\_swmr\_config\_t in H5Fpublic.h properly.
+
+    -   Cleanup EOA hack in H5FD\_read().
+
+    -   Address file open failures in SWMR tests. These appear to be
+        cases in which the writer finishes before the reader opens --
+        causing the reader to fail as the metadata file no longer
+        exists. If so, handle this more gracefully.
+
+14. Add support for specifying the VFD that sits under the VFD SWMR
+    reader VFD. Probably do this as part of the pluggable VFD design
+    that Jake is working on.
+
+15. Modify the metadata cache so that we don't allocate space for the
+    page hash table unless the file is opened in VFD SWMR reader mode.
+
+16. Implement the logging facility (section 3.14 RFC)
+
+17. Test code to expose existing page buffer bugs and fix same. Note
+    that they seem to appear primarily on Jelly.
+
+    -   DLL pre remove sanity check assertion failure
+
+    -   vfd\_swmr\_addrem\_writer: H5PB.c:2981:
+        H5PB\_\_mark\_entry\_dirty: Assertion
+        '(entry\_ptr)-\>delay\_write\_until \> (pb\_ptr)-\>cur\_tick'
+        failed.
+
+18. Flesh out designs for unit, integration and performance tests suites
+    as outlined in the RFC. Implement same.
+
+19. Fix memory leak in sparse-reader test.
+
+20. Test John's patch that repairs the superblock flags mismatch that
+    crashes the reader.
+
+21. Investigate a potential time-of-check, time-of-use race condition
+    involving EOA/EOF and the skip\_read variable in some of the H5PB
+    routines.
+
+22. Understand use of H5F\_t on branch feature/vfd\_swmr instead of
+    H5C\_t as on develop branch.
+
+23. *Temporarily* reserve a new superblock flag for VFD SWMR for
+    development purposes.
+
+24. Prior to feature merge, *permanently* reserve a new superblock flag.
+
+25. Revisit the global heap. The global heap receives data types (a form
+    of metadata) and variable-length (VL) data such as strings. It is
+    translated to raw data on its way down the HDF5 software stack. If
+    the global heap is modified/replaced as currently planned, then VFD
+    SWMR does not have to deal with it. However, if the global heap
+    overhaul does not take place, then we have more work to do.