Use well-known expiration attribute for SGs
To avoid ambiguity, let's use the common well-known attribute to control both Object and Storage Group expirations. Signed-off-by: Stanislav Bogatyrev <stanislav@nspcc.ru>
This commit is contained in:
parent
f741ea6f4a
commit
8bf98ec983
2 changed files with 14 additions and 3 deletions
|
@ -30,12 +30,17 @@ that require payed storage guaranties are gathered in `StorageGroups` with
|
|||
additional information used for proof of storage. `StorageGroup` only
|
||||
contains objects from the same container.
|
||||
|
||||
Being an object payload, StorageGroup may have expiration Epoch set with
|
||||
`__NEOFS__EXPIRATION_EPOCH` well-known attribute. When expired, StorageGroup
|
||||
will be ignored by InnerRing nodes during Data Audit cycles and will be
|
||||
deleted by Storage Nodes.
|
||||
|
||||
|
||||
| Field | Type | Label | Description |
|
||||
| ----- | ---- | ----- | ----------- |
|
||||
| validation_data_size | [uint64](#uint64) | | Total size of the payloads of objects in the storage group |
|
||||
| validation_hash | [neo.fs.v2.refs.Checksum](#neo.fs.v2.refs.Checksum) | | Homomorphic hash from the concatenation of the payloads of the storage group members. The order of concatenation is the same as the order of the members in the `members` field. |
|
||||
| expiration_epoch | [uint64](#uint64) | | Last NeoFS epoch number of the storage group lifetime |
|
||||
| expiration_epoch | [uint64](#uint64) | | DEPRECATED. Last NeoFS epoch number of the storage group lifetime |
|
||||
| members | [neo.fs.v2.refs.ObjectID](#neo.fs.v2.refs.ObjectID) | repeated | Strictly ordered list of storage group member objects |
|
||||
|
||||
<!-- end messages -->
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue