[tahoe-lafs-trac-stream] [tahoe-lafs] #395: why are so many helper files being abandoned?
tahoe-lafs
trac at tahoe-lafs.org
Sun Mar 17 17:14:48 UTC 2013
#395: why are so many helper files being abandoned?
-----------------------------+-------------------------------------
Reporter: warner | Owner: somebody
Type: task | Status: new
Priority: major | Milestone: eventually
Component: operational | Version: 1.0.0
Resolution: | Keywords: helper space-efficiency
Launchpad Bug: |
-----------------------------+-------------------------------------
Changes (by davidsarah):
* keywords: helper => helper space-efficiency
* milestone: undecided => eventually
Old description:
> Our prodnet munin graphs show that our helper is receiving ciphertext for
> a lot of files which are then abandoned, either part-way through the
> ciphertext fetch phase, or during the encode+push phase. The clients then
> never try again.
>
> * add code (or admin tools) to delete old files from the helper's
> directory after a while. We have something like 38GB of files in
> there right now
> * figure out where these are coming from. It must be the windows
> FUSE plugin (that's the only deployment we have on prodnet that
> uses the helper), but what sorts of files are so large and then
> abandoned? It's possible that encode+push takes so long that
> the application gives up and tries again (with a new and
> different file).
New description:
Our prodnet munin graphs show that our helper is receiving ciphertext for
a lot of files which are then abandoned, either part-way through the
ciphertext fetch phase, or during the encode+push phase. The clients then
never try again.
* add code (or admin tools) to delete old files from the helper's
directory after a while. We have something like 38GB of files in
there right now
* figure out where these are coming from. It must be the windows
FUSE plugin (that's the only deployment we have on prodnet that
uses the helper), but what sorts of files are so large and then
abandoned? It's possible that encode+push takes so long that
the application gives up and tries again (with a new and
different file).
--
Comment:
According to [source:git/docs/helper.rst#setting-up-a-helper], "future
versions of tahoe" are supposed to delete abandoned upload files on the
helper:
{{{
If a client disconnects while the ciphertext is being fetched, the
partial ciphertext will remain in CHK_incoming/ until they reconnect
and finish sending it. If a client disconnects while the ciphertext
is being encoded, the data will remain in CHK_encoding/ until they
reconnect and encoding is finished. For long-running and busy helpers,
it may be a good idea to delete files in these directories that have
not been modified for a week or two. Future versions of tahoe will
try to self-manage these files a bit better.
}}}
--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/395#comment:3>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage
More information about the tahoe-lafs-trac-stream
mailing list