warn users about the performance issues of mutable files

[zooko]

Performance issues:

• mutable files are stored in their entirety in RAM briefly during upload
• creating a new mutable file requires creating a new RSA public/private key-pair, which can take as many as a billion CPU cycles

Currently, new users can carefully read the Tahoe-LAFS docs and then go on and decide to use mutable files without being aware of these issues. To close this ticket, fix that.

[zooko]

Here's the thread where new user Jody Harris made it clear that a new user who does read the docs still doesn't learn about these issues: ​http://allmydata.org/pipermail/tahoe-dev/2010-January/003478.html

[kevan]

I'll take care of this.

[kevan]

I added the documentation to ​known_issues.txt, since there are proposals and tickets open that hope to fix this (which would seem to imply that it is a known issue).

Thoughts? Things that should be there but aren't?

[kevan]

After reading a message (​http://allmydata.org/pipermail/tahoe-dev/2010-January/003488.html) on tahoe-dev, I realized that I had misunderstood mutable file modification when writing my first patch. While the process I described was accurate for certain operations (specifically directory modification), it didn't apply to file creation using the CLI or the WUI, the places where users would be creating mutable files, and the places where the warning would be relevant. I'm attaching a reworded patch that fixes this issue.

[zooko]

This ticket is a subset of #757 (there isn't a doc that says "which operations are efficient").

[zooko]

FWIW here are measurements of how many CPU cycles are needed to generate an RSA 2048 bit key: ​http://bench.cr.yp.to/results-sign.html (the ones labelled "ronald2048"). That is not measuring the same implementation of RSA as the one we use, but it is a good benchmark to show that generating RSA keys is expensive.

[davidsarah]

​http://allmydata.org/trac/tahoe/attachment/ticket/878/mutable_docs.txt#L21 : "will be invalidated if the file is modified" -> "would be invalidated if the file were modified".

[davidsarah]

"tahoe-lafs" -> "Tahoe-LAFS" (three times)

[warner]

while "billions of CPU cycles" is technically accurate, it would be more meaningful to users to say "perhaps an entire second on a desktop PC" (and maybe a parenthetical remark about small ARM boxes). We don't want to scare them away from using directories altogether, just help them understand why a loop that creates a million directories might take a million seconds.

Also, I believe the motivation for this ticket was specifically about *large* mutable files, so I'd emphasize the unfortunate-and-we-haven't-fixed-with-MDMF performance aspects (i.e. the cost=O(filesize) parts) rather than the unfortunate-and-we-haven't-fixed-with-ECDSA aspects (like the constant cost of creating new mutable files).

[zooko]

For Jody Harris, seconds elapsed on today's average PC might be more useful (or maybe not -- perhaps he prefers CPU cycles), but for Jonathan Ellis (the bug reporter of #757) CPU cycles is probably more useful. Also I wonder about people who are running their Tahoe-LAFS gateway on virtual machine. Would seconds-on-an-average-modern CPU significantly underestimate the cost to them?

[warner]

like I said, "billions of CPU cycles" is more accurate (and more universal), but I think the most likely audience for this document will be well-served by having at least one human-meaningful unit of measure in there somewhere, even if only anecdotally. For example, I tell people that the unit tests currently take about 240s on my 2008-era laptop, and I tell them that "tahoe mkdir" takes about 800ms on the same machine. And I expect that people will know how their own hardware compares to a reference point like that. Let's not refuse to offer them a translation hint just because we can't give them an exact number of seconds for their particular hardware.

[kevan]

I'm updating the patch to include David-Sarahs' suggestions. Thanks for the feedback. :)

[kevan]

zooko and I were talking in IRC, and concluded that the explanation of why RSA is used with mutable files is inappropriate for known_issues.txt. I'll remove it when I work on the cycles versus seconds issue.

[kevan]

I think I agree with Brian.

Without a meaningful human figure to put "billions of CPU cycles" into perspective, that paragraph is a tad scarier than it needs to be. My first instinct when reading this exchange was to try to work both figures in there, but the point of that paragraph seems a lot clearer with only seconds than with both cycles and seconds.

I moved the explanation of mutable file performance issues to docs/performance.txt, because that seemed like a more appropriate place for it.

[kevan]

mutable file documentation

[davidsarah]

Looks good to me.

[zooko]

Applied as 26c6b806d7922da1. Thank you!