svn commit: r1161240 - /subversion/branches/fs-successor-ids/BRANCH-README

[da...@apache.org]

Author: danielsh
Date: Wed Aug 24 19:30:36 2011
New Revision: 1161240

URL: http://svn.apache.org/viewvc?rev=1161240&view=rev
Log:
On the fs-successor-ids branch:

* BRANCH-README
  (FSFS WHITEBOARD): Start this section by recording the first idea that crossed my
    mind during an IRC conversation.  Suggested by the 'abuse everyone's inbox as
    my backup scheme' department.

Modified:
    subversion/branches/fs-successor-ids/BRANCH-README

Modified: subversion/branches/fs-successor-ids/BRANCH-README
URL: http://svn.apache.org/viewvc/subversion/branches/fs-successor-ids/BRANCH-README?rev=1161240&r1=1161239&r2=1161240&view=diff
==============================================================================
--- subversion/branches/fs-successor-ids/BRANCH-README (original)
+++ subversion/branches/fs-successor-ids/BRANCH-README Wed Aug 24 19:30:36 2011
@@ -62,3 +62,36 @@ present.  That would need to be added fo
 Lacking also are C unit tests for this functionality.
 
 And, of course, the FSFS support for this enhancement is non-existent.
+
+
+FSFS WHITEBOARD
+===============
+
+Need an append-only key-value store.  (Values may be modified by appending
+to them.  Keys may be appended.)
+
+1. In revisions, all successors are copies, except at most one.
+   => that 'at most one' modification successor can be stored separately
+      from the copies.
+
+2. Storing copies:
+   - a directory per noderev that had been copied
+   - in the directory, a file per copy event
+   - each file contains the txn-id of the (txn creating the) revision
+     the copy/successor lives in
+   - directories are sharded, scheme TBD
+     - possibly: one directory serves several copied-from noderevs?
+   - non-copies (ie, 'modification' successors) are stored separately
+
+   Rationale:
+
+   - store the txn-id (and check it when reading the directory)
+     to handle issues with aborted commits (eg, mkdir db/revs/${youngest+1})
+
+   - shard/reuse directories to avoid burning through inodes
+     - may need to 'pack' directories occasionally?  The one-file-per-successor
+       isn't needed in the long term...
+
+   - store 'modification' successors separately as there is O(1) of them
+
+3. (append your FSFS design scheme to here):