shares should have a layout version number in them #90

Closed
opened 2007-07-14 06:55:52 +00:00 by warner · 4 comments
warner commented 2007-07-14 06:55:52 +00:00
Owner

having a version number in the shares would make it easier to preserve share data across layout changes in the future.

having a version number in the shares would make it easier to preserve share data across layout changes in the future.
tahoe-lafs added the
code
major
enhancement
0.4.0
labels 2007-07-14 06:55:52 +00:00
tahoe-lafs added this to the undecided milestone 2007-07-14 06:55:52 +00:00
zooko commented 2007-07-15 01:38:45 +00:00
Author
Owner

Good idea!

Good idea!
tahoe-lafs added
code-storage
and removed
code
labels 2007-08-14 18:55:29 +00:00
zooko commented 2007-08-20 17:51:46 +00:00
Author
Owner

This is part of the "long-term data reliability" task. I would like to see this ticket done for v0.6.

This is part of the "long-term data reliability" task. I would like to see this ticket done for v0.6.
tahoe-lafs modified the milestone from undecided to 0.6.0 2007-08-20 17:51:46 +00:00
warner commented 2007-09-04 15:50:26 +00:00
Author
Owner

Partially done, in changeset:94233b88134e9a00. The first four bytes of the file on disk are a version number for the benefit of the StorageServer: v=1 indicates that the lease information is stored immediately following the share data. The actual format is:

  • four bytes sharefile version number
  • four bytes share data length
  • four bytes number-of-leases
  • share data
  • leases

To complete this ticket, the share data itself needs to share with a version number, for the benefit of the client (rather than the StorageServer). The client only gets to see the share data, not the leases, and there is further structure inside the share data, so that needs its own version number as well.

Partially done, in changeset:94233b88134e9a00. The first four bytes of the file on disk are a version number for the benefit of the [StorageServer](wiki/StorageServer): v=1 indicates that the lease information is stored immediately following the share data. The actual format is: * four bytes sharefile version number * four bytes share data length * four bytes number-of-leases * share data * leases To complete this ticket, the share data itself needs to share with a version number, for the benefit of the client (rather than the [StorageServer](wiki/StorageServer)). The client only gets to see the share data, not the leases, and there is further structure inside the share data, so that needs its own version number as well.
warner commented 2007-09-04 16:03:32 +00:00
Author
Owner

Completed, in changeset:76be4a582c3487ea. The first four bytes of the share data (which is stored
inside the share file) now have a version number as well. v=1 indicates the
following layout:

0x00: version number (=00 00 00 01)
0x04: segment size
0x08: data size
0x0c: offset of data (=00 00 00 24)
0x10: offset of plaintext_hash_tree
0x14: offset of crypttext_hash_tree
0x18: offset of block_hashes
0x1c: offset of share_hashes
0x20: offset of uri_extension_length + uri_extension
0x24: start of data
?   : start of plaintext_hash_tree
?   : start of crypttext_hash_tree
?   : start of block_hashes
?   : start of share_hashes
       each share_hash is written as a two-byte (big-endian) hashnum
       followed by the 32-byte SHA-256 hash. We only store the hashes
       necessary to validate the share hash root
?   : start of uri_extension_length (four-byte big-endian value)
?   : start of uri_extension
Completed, in changeset:76be4a582c3487ea. The first four bytes of the share data (which is stored inside the share file) now have a version number as well. v=1 indicates the following layout: ``` 0x00: version number (=00 00 00 01) 0x04: segment size 0x08: data size 0x0c: offset of data (=00 00 00 24) 0x10: offset of plaintext_hash_tree 0x14: offset of crypttext_hash_tree 0x18: offset of block_hashes 0x1c: offset of share_hashes 0x20: offset of uri_extension_length + uri_extension 0x24: start of data ? : start of plaintext_hash_tree ? : start of crypttext_hash_tree ? : start of block_hashes ? : start of share_hashes each share_hash is written as a two-byte (big-endian) hashnum followed by the 32-byte SHA-256 hash. We only store the hashes necessary to validate the share hash root ? : start of uri_extension_length (four-byte big-endian value) ? : start of uri_extension ```
tahoe-lafs added the
fixed
label 2007-09-04 16:03:32 +00:00
warner closed this issue 2007-09-04 16:03:32 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac-2024-07-25#90
No description provided.