[Imported from Trac: page KnownIssues, version 1]
parent
fdd647ac87
commit
46d95ba256
71
KnownIssues.md
Normal file
71
KnownIssues.md
Normal file
|
@ -0,0 +1,71 @@
|
|||
# Known Issues
|
||||
|
||||
This page describes known problems for recent releases of Tahoe. Issues are
|
||||
fixed as quickly as possible, however users of older releases may still need
|
||||
to be aware of these problems until they upgrade to a release which resolves
|
||||
it.
|
||||
|
||||
## Issues in [1.1 [/tahoe-lafs/trac-2024-07-25/milestone/127](/tahoe-lafs/trac-2024-07-25/milestone/127)]Tahoe (not quite released)
|
||||
|
||||
### Servers which run out of space
|
||||
|
||||
If a Tahoe storage server runs out of space, writes will fail with an
|
||||
`IOError` exception. In some situations, Tahoe-1.1 clients will not react
|
||||
to this very well:
|
||||
|
||||
* if the exception occurs during an immutable-share write, that share will
|
||||
be broken. The client will detect this, and will declare the upload as
|
||||
failing if insufficient shares can be placed (this "shares of happiness"
|
||||
threshold defaults to 7 out of 10). The code does not yet search for new
|
||||
servers to replace the full ones. If the upload fails, the server's
|
||||
upload-already-in-progress routines may interfere with a subsequent
|
||||
upload.
|
||||
* if the exception occurs during a mutable-share write, the old share will
|
||||
be left in place (and a new home for the share will be sought). If enough
|
||||
old shares are left around, subsequent reads may see the file in its
|
||||
earlier state, known as a "rollback" fault. Writing a new version of the
|
||||
file should find the newer shares correctly, although it will take
|
||||
longer (more roundtrips) than usual.
|
||||
|
||||
The out-of-space handling code is not yet complete, and we do not yet have a
|
||||
space-limiting solution that is suitable for large storage nodes. The
|
||||
"sizelimit" configuration uses a /usr/bin/du -style query at node startup,
|
||||
which takes a long time (tens of minutes) on storage nodes that offer 100GB
|
||||
or more, making it unsuitable for highly-available servers.
|
||||
|
||||
In lieu of 'sizelimit', server admins are advised to set the
|
||||
NODEDIR/readonly_storage (and remove 'sizelimit', and restart their nodes) on
|
||||
their storage nodes before space is exhausted. This will stop the influx of
|
||||
immutable shares. Mutable shares will continue to arrive, but since these are
|
||||
mainly used by directories, the amount of space consumed will be smaller.
|
||||
|
||||
Eventually we will have a better solution for this.
|
||||
|
||||
== Issues in Tahoe 1.0 ==
|
||||
|
||||
=== Servers which run out of space ===
|
||||
|
||||
In addition to the problems described above, Tahoe-1.0 clients which
|
||||
experience out-of-space errors while writing mutable files are likely to
|
||||
think the write succeeded, when it in fact failed. This can cause data loss.
|
||||
|
||||
=== Large Directories or Mutable files in a specific range of sizes ===
|
||||
|
||||
A mismatched pair of size limits causes a problem when a client attempts to
|
||||
upload a large mutable file with a size between 3139275 and 3500000 bytes.
|
||||
(Mutable files larger than 3.5MB are refused outright). The symptom is very
|
||||
high memory usage (3GB) and 100% CPU for about 5 minutes. The attempted write
|
||||
will fail, but the client may think that it succeeded. This size corresponds
|
||||
to roughly 9000 entries in a directory.
|
||||
|
||||
This was fixed in 1.1, as ticket #379. Files up to 3.5MB should now work
|
||||
properly, and files above that size should be rejected properly. Both servers
|
||||
and clients must be upgraded to resolve the problem, although once the client
|
||||
is upgraded to 1.1 the memory usage and false-success problems should be
|
||||
fixed.
|
||||
|
||||
=== pycryptopp compile errors resulting in corruption ===
|
||||
|
||||
Certain combinations of compiler, linker, and pycryptopp versions may cause
|
||||
corruption errors during decryption, resulting in corrupted plaintext.
|
||||
|
Loading…
Reference in a new issue