README.md: describe mmap problems with limited address spaces.

[bup.git] / README.md

diff --git a/README.md b/README.md
index 8187ddfd1c495a58355b8515f40a69b8b5f250be..19998d24f0c8817164b75ab11da9ed31c3a1a5e2 100644 (file)
--- a/README.md
+++ b/README.md
@@ -1,4 +1,3 @@
-
 bup: It backs things up
 =======================
 
@@ -72,7 +71,7 @@ Reasons you might want to avoid bup
    for you, but we don't know why.  It is also missing some
    probably-critical features.
    
- - It requires python >= 2.4, a C compiler, and an installed git version >=
+ - It requires python >= 2.5, a C compiler, and an installed git version >=
    1.5.3.1.
  
  - It currently only works on Linux, MacOS X >= 10.4,
@@ -89,7 +88,7 @@ From source
 
  - Check out the bup source code using git:
  
-        git clone git://github.com/apenwarr/bup
+        git clone git://github.com/bup/bup
 
  - Install the needed python libraries (including the development
    libraries).
@@ -100,9 +99,8 @@ From source
             apt-get install python-pyxattr python-pylibacl
             apt-get install linux-libc-dev
 
-   Substitute python2.5-dev or python2.4-dev if you have an older
-   system.  Alternately, on newer Debian/Ubuntu versions, you can try
-   this:
+   Substitute python2.5-dev if you have an older system.  Alternately,
+   on newer Debian/Ubuntu versions, you can try this:
     
             apt-get build-dep bup
 
@@ -328,13 +326,32 @@ mailing list (see below) if you'd like to help.
  
     On the plus side, they actually do have support now, but it's new,
     and not remotely as well tested as tar/rsync/whatever's.  If you'd
-    like to help test, please do; something like 'rsync -niaHAX src/
-    restore/' may be useful on that front.
+    like to help test, please do (see t/compare-trees for one
+    comparison method).
 
     In addition, at the moment, if any strip or graft-style options
     are specified to 'bup save', then no metadata will be written for
     the root directory.  That's obviously less than ideal.
 
+ - bup is overly optimistic about mmap.  Right now bup just assumes
+   that it can mmap as large a block as it likes, and that mmap will
+   never fail.  Yeah, right... If nothing else, this has failed on
+   32-bit architectures (and 31-bit is even worse -- looking at you,
+   s390).
+
+   To fix this, we might just implement a FakeMmap[1] class that uses
+   normal file IO and handles all of the mmap methods[2] that bup
+   actually calls.  Then we'd swap in one of those whenever mmap
+   fails.
+
+   This would also require implementing some of the methods needed to
+   support "[]" array access, probably at a minimum __getitem__,
+   __setitem__, and __setslice__ [3].
+
+     [1] http://comments.gmane.org/gmane.comp.sysutils.backup.bup/613
+     [2] http://docs.python.org/2/library/mmap.html
+     [3] http://docs.python.org/2/reference/datamodel.html#emulating-container-types
+
  - 'bup index' is slower than it should be.
  
     It's still rather fast: it can iterate through all the filenames on my
@@ -415,7 +432,7 @@ and you can subscribe by sending a message to:
 
        bup-list+subscribe@googlegroups.com
 
-Please see <a href="bup/blob/master/HACKING">./HACKING</a> for
+Please see <a href="HACKING">./HACKING</a> for
 additional information, i.e. how to submit patches (hint - no pull
 requests), how we handle branches, etc.