From: Zooko O'Whielacronx Date: Tue, 10 Feb 2009 03:09:31 +0000 (-0700) Subject: immutable: tests: sigh, raise, again the limit of how many extra writes you can do... X-Git-Tag: allmydata-tahoe-1.3.0~53 X-Git-Url: https://git.rkrishnan.org/architecture.txt?a=commitdiff_plain;h=65c12b24b8ee356a51f4ef21285c081df3f8c7db;p=tahoe-lafs%2Ftahoe-lafs.git immutable: tests: sigh, raise, again the limit of how many extra writes you can do and still pass this test Obviously requiring the code under test to perform within some limit isn't very meaningful if we raise the limit whenever the test goes outside of it. But I still don't want to remove the test code which measures how many writes (and, elsewhere, how many reads) a client does in order to fulfill these duties. Let this number -- now 20 -- stand as an approximation of the inefficiency of our code divided by my mental model of how many operations are actually optimal for these duties. --- diff --git a/src/allmydata/test/test_repairer.py b/src/allmydata/test/test_repairer.py index e1a84d4d..8e9ac0a9 100644 --- a/src/allmydata/test/test_repairer.py +++ b/src/allmydata/test/test_repairer.py @@ -331,9 +331,9 @@ class Verifier(common.ShareManglingMixin, unittest.TestCase): ], judge) test_verify_server_invisible_corruption_share_hash_tree_TODO.todo = "Verifier doesn't yet properly detect this kind of corruption." -# We'll allow you to pass this test even if you trigger ten times as many +# We'll allow you to pass this test even if you trigger twenty times as many # block sends and disk writes as would be optimal. -WRITE_LEEWAY = 10 +WRITE_LEEWAY = 20 # Optimally, you could repair one of these (small) files in a single write. DELTA_WRITES_PER_SHARE = 1 * WRITE_LEEWAY