increase maximum mutable share size

[david-sarah@…]

In 33e2d2962e2bc6cc:

(The changeset message doesn't reference this ticket)

[david-sarah@…]

In 5526/1.9.2:

Change the maximum mutable share size to 69105 TB, and add a maximum-mutable-share-size field to the version announcement. Includes a test. refs #1778

[david-sarah <david-sarah@…>]

In 33e2d2962e2bc6cc:

Change the maximum mutable share size to 69105 TB, and add a maximum-mutable-share-size field to the version announcement. Includes a test. refs #1778

[zooko]

Hm...

        version = { "http://allmydata.org/tahoe/protocols/storage/v1" :
                    { "maximum-immutable-share-size": remaining_space,
                      "maximum-mutable-share-size": MAX_MUTABLE_SHARE_SIZE,
                      "tolerates-immutable-read-overrun": True,
                      "delete-mutable-shares-with-zero-length-writev": True,
                      "fills-holes-with-zero-bytes": True,
                      "prevents-read-past-end-of-share-data": True,
                      },
                    "application-version": str(allmydata.__full_version__),
                    }

Wouldn't it be more consistent for maximum-mutable-share-size to be equal to remaining_space? Also more meaningful to potential future clients that are curious about approximately big of a mutable share they could upload. With this version (above), they would have to look at maximum-immutable-share-size in order to answer that question, and they would ignore maximum-mutable-share-size.

[zooko]

But otherwise I like the patch -- it makes minimal changes to the code (which is appropriate for the imminent 1.9.2 release) and it includes a unit test.

[davidsarah]

The current storage code doesn't enforce remaining_space for mutables (#390). The filesystem will fill up at some point, but that would impose a limit of

min(MAX_MUTABLE_SHARE_SIZE, total_remaining_disk_space)

rather than remaining_space. We can always compute the limit more precisely if we fix #390; I don't think there's a significant forward-compatibility problem there.

[zooko]

Okay, good enough for 1.9.2 IMO.

[warner]

I'm cool with it. At this point, I somewhat prefer fixed-max-size advertisements over min(MAXSIZE, remaining_disk_space), mostly because the latter will prevent uploads if the disk is full when the node is started (and the announcement produced), but then later frees up some space. Really, it's a tradeoff between delivering information ahead of time (in the announcement) versus discovering available space at the time of upload.

I'm a little bit weirded out by the funny magic 69105TB limit (subtle in-jokes like that are cute, but at least one person is going to be flummoxed in the future trying to figure out why the limit is that particular number and not e.g. 69106TB). But I don't have any 70 petabyte mutable files that need uploading, nor do I anticipate anyone else having that need this decade, so I don't really care very much.

[david-sarah@…]

In 5885/cloud-backend:

[rebased for cloud-backend] Change the maximum mutable share size to 69105 TB, and add a maximum-mutable-share-size field to the version announcement. Includes a test. refs #1778