docs/historical/historical_known_issues.txt

   1 = Known Issues =
   2
   3 Below is a list of known issues in older releases of Tahoe-LAFS, and how to
   4 manage them.  The current version of this file can be found at
   5
   6 http://allmydata.org/source/tahoe/trunk/docs/historical/historical_known_issues.txt
   7
   8 Newer versions of this document describing issues in newer releases of
   9 Tahoe-LAFS can be found at:
  10
  11 http://allmydata.org/source/tahoe/trunk/docs/known_issues.txt
  12
  13 == issues in Tahoe v1.1.0, released 2008-06-11 ==
  14
  15 (Tahoe v1.1.0 was superceded by v1.2.0 which was released 2008-07-21,
  16 and then by v1.3.0 which was released 2009-02-13.)
  17
  18 === more than one file can match an immutable file cap ===
  19
  20 In Tahoe v1.0 and v1.1, a flaw in the cryptographic integrity check
  21 makes it possible for the original uploader of an immutable file to
  22 produce more than one immutable file matching the same capability, so
  23 that different downloads using the same capability could result in
  24 different files.  This flaw can be exploited only by the original
  25 uploader of an immutable file, which means that it is not a severe
  26 vulnerability: you can still rely on the integrity check to make sure
  27 that the file you download with a given capability is a file that the
  28 original uploader intended.  The only issue is that you can't assume
  29 that every time you use the same capability to download a file you'll
  30 get the same file.
  31
  32 ==== how to manage it ====
  33
  34 This was fixed in Tahoe v1.2.0, released 2008-07-21, under ticket
  35 #491.  Upgrade to that release of Tahoe and then you can rely on the
  36 property that there is only one file that you can download using a
  37 given capability.  If you are still using Tahoe v1.0 or v1.1, then
  38 remember that the original uploader could produce multiple files that
  39 match the same capability, so for example if someone gives you a
  40 capability, and you use it to download a file, and you give that
  41 capability to your friend, and he uses it to download a file, you and
  42 your friend could get different files.
  43
  44
  45 === server out of space when writing mutable file ===
  46
  47 If a v1.0 or v1.1 storage server runs out of disk space or is
  48 otherwise unable to write to its local filesystem, then problems can
  49 ensue.  For immutable files, this will not lead to any problem (the
  50 attempt to upload that share to that server will fail, the partially
  51 uploaded share will be deleted from the storage server's "incoming
  52 shares" directory, and the client will move on to using another
  53 storage server instead).
  54
  55 If the write was an attempt to modify an existing mutable file,
  56 however, a problem will result: when the attempt to write the new
  57 share fails (e.g. due to insufficient disk space), then it will be
  58 aborted and the old share will be left in place.  If enough such old
  59 shares are left, then a subsequent read may get those old shares and
  60 see the file in its earlier state, which is a "rollback" failure.
  61 With the default parameters (3-of-10), six old shares will be enough
  62 to potentially lead to a rollback failure.
  63
  64 ==== how to manage it ====
  65
  66 Make sure your Tahoe storage servers don't run out of disk space.
  67 This means refusing storage requests before the disk fills up. There
  68 are a couple of ways to do that with v1.1.
  69
  70 First, there is a configuration option named "sizelimit" which will
  71 cause the storage server to do a "du" style recursive examination of
  72 its directories at startup, and then if the sum of the size of files
  73 found therein is greater than the "sizelimit" number, it will reject
  74 requests by clients to write new immutable shares.
  75
  76 However, that can take a long time (something on the order of a minute
  77 of examination of the filesystem for each 10 GB of data stored in the
  78 Tahoe server), and the Tahoe server will be unavailable to clients
  79 during that time.
  80
  81 Another option is to set the "readonly_storage" configuration option
  82 on the storage server before startup.  This will cause the storage
  83 server to reject all requests to upload new immutable shares.
  84
  85 Note that neither of these configurations affect mutable shares: even
  86 if sizelimit is configured and the storage server currently has
  87 greater space used than allowed, or even if readonly_storage is
  88 configured, servers will continue to accept new mutable shares and
  89 will continue to accept requests to overwrite existing mutable shares.
  90
  91 Mutable files are typically used only for directories, and are usually
  92 much smaller than immutable files, so if you use one of these
  93 configurations to stop the influx of immutable files while there is
  94 still sufficient disk space to receive an influx of (much smaller)
  95 mutable files, you may be able to avoid the potential for "rollback"
  96 failure.
  97
  98 A future version of Tahoe will include a fix for this issue.  Here is
  99 [http://allmydata.org/pipermail/tahoe-dev/2008-May/000630.html the
 100 mailing list discussion] about how that future version will work.
 101
 102
 103 === pyOpenSSL/Twisted defect causes false alarms in tests ===
 104
 105 The combination of Twisted v8.0 or Twisted v8.1 with pyOpenSSL v0.7
 106 causes the Tahoe v1.1 unit tests to fail, even though the behavior of
 107 Tahoe itself which is being tested is correct.
 108
 109 ==== how to manage it ====
 110
 111 If you are using Twisted v8.0 or Twisted v8.1 and pyOpenSSL v0.7, then
 112 please ignore ERROR "Reactor was unclean" in test_system and
 113 test_introducer. Upgrading to a newer version of Twisted or pyOpenSSL
 114 will cause those false alarms to stop happening (as will downgrading
 115 to an older version of either of those packages).
 116 == issues in Tahoe v1.0.0, released 2008-03-25 ==
 117
 118 (Tahoe v1.0 was superceded by v1.1 which was released 2008-06-11.)
 119
 120 === server out of space when writing mutable file ===
 121
 122 In addition to the problems caused by insufficient disk space
 123 described above, v1.0 clients which are writing mutable files when the
 124 servers fail to write to their filesystem are likely to think the
 125 write succeeded, when it in fact failed. This can cause data loss.
 126
 127 ==== how to manage it ====
 128
 129 Upgrade client to v1.1, or make sure that servers are always able to
 130 write to their local filesystem (including that there is space
 131 available) as described in "issue 1" above.
 132
 133
 134 === server out of space when writing immutable file ===
 135
 136 Tahoe v1.0 clients are using v1.0 servers which are unable to write to
 137 their filesystem during an immutable upload will correctly detect the
 138 first failure, but if they retry the upload without restarting the
 139 client, or if another client attempts to upload the same file, the
 140 second upload may appear to succeed when it hasn't, which can lead to
 141 data loss.
 142
 143 ==== how to manage it ====
 144
 145 Upgrading either or both of the client and the server to v1.1 will fix
 146 this issue.  Also it can be avoided by ensuring that the servers are
 147 always able to write to their local filesystem (including that there
 148 is space available) as described in "issue 1" above.
 149
 150
 151 === large directories or mutable files of certain sizes ===
 152
 153 If a client attempts to upload a large mutable file with a size
 154 greater than about 3,139,000 and less than or equal to 3,500,000 bytes
 155 then it will fail but appear to succeed, which can lead to data loss.
 156
 157 (Mutable files larger than 3,500,000 are refused outright).  The
 158 symptom of the failure is very high memory usage (3 GB of memory) and
 159 100% CPU for about 5 minutes, before it appears to succeed, although
 160 it hasn't.
 161
 162 Directories are stored in mutable files, and a directory of
 163 approximately 9000 entries may fall into this range of mutable file
 164 sizes (depending on the size of the filenames or other metadata
 165 associated with the entries).
 166
 167 ==== how to manage it ====
 168
 169 This was fixed in v1.1, under ticket #379.  If the client is upgraded
 170 to v1.1, then it will fail cleanly instead of falsely appearing to
 171 succeed when it tries to write a file whose size is in this range.  If
 172 the server is also upgraded to v1.1, then writes of mutable files
 173 whose size is in this range will succeed.  (If the server is upgraded
 174 to v1.1 but the client is still v1.0 then the client will still suffer
 175 this failure.)
 176
 177
 178 === uploading files greater than 12 GiB ===
 179
 180 If a Tahoe v1.0 client uploads a file greater than 12 GiB in size, the file will
 181 be silently corrupted so that it is not retrievable, but the client will think
 182 that it succeeded.  This is a "data loss" failure.
 183
 184 ==== how to manage it ====
 185
 186 Don't upload files larger than 12 GiB.  If you have previously uploaded files of
 187 that size, assume that they have been corrupted and are not retrievable from the
 188 Tahoe storage grid.  Tahoe v1.1 clients will refuse to upload files larger than
 189 12 GiB with a clean failure.  A future release of Tahoe will remove this
 190 limitation so that larger files can be uploaded.
 191
 192
 193 === pycryptopp defect resulting in data corruption ===
 194
 195 Versions of pycryptopp earlier than pycryptopp-0.5.0 had a defect
 196 which, when compiled with some compilers, would cause AES-256
 197 encryption and decryption to be computed incorrectly.  This could
 198 cause data corruption.  Tahoe v1.0 required, and came with a bundled
 199 copy of, pycryptopp v0.3.
 200
 201 ==== how to manage it ====
 202
 203 You can detect whether pycryptopp-0.3 has this failure when it is
 204 compiled by your compiler.  Run the unit tests that come with
 205 pycryptopp-0.3: unpack the "pycryptopp-0.3.tar" file that comes in the
 206 Tahoe v1.0 {{{misc/dependencies}}} directory, cd into the resulting
 207 {{{pycryptopp-0.3.0}}} directory, and execute {{{python ./setup.py
 208 test}}}.  If the tests pass, then your compiler does not trigger this
 209 failure.