-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Capacity attribute in testnet config #602
Comments
@fyrchik can look at Proof-of-Storage papers, maybe we can afford to make single capacity proof at the node bootstrap. |
For the PoC we need to run some sort of Proof-Of-Storage algorithm at the bootstrap stage. Then provide the results at bootstrap operation. Then Alphabet nodes verify the result and set confirmed capacity attribute. |
It shouldn't be configured, the node can get this data automatically (just look at statfs for shards). It can be overridden by the config at the same time. We can't prove this for now, but I believe it's more useful to have this data unverified than not have it all (node will reject data on overflow anyway). Refs. nspcc-dev/neofs-sdk-go#438, it should be fixed in the same release with update to RC10. |
It is done automatically (as a sum of existing space on every file system available on the configured shards) but can be overwritten if `Capacity` attribute is provided via the application configuration. Closes nspcc-dev#602. Signed-off-by: Pavel Karpy <[email protected]>
It is done automatically (as a sum of existing space on every file system available on the configured shards) but can be overwritten if `Capacity` attribute is provided via the application configuration. Closes nspcc-dev#602. Signed-off-by: Pavel Karpy <[email protected]>
It is done automatically (as a sum of existing space on every file system available on the configured shards) but can be overwritten if `Capacity` attribute is provided via the application configuration. Closes nspcc-dev#602. Signed-off-by: Pavel Karpy <[email protected]>
It is done automatically (as a sum of existing space on every file system available on the configured shards) but can be overwritten if `Capacity` attribute is provided via the application configuration. Closes nspcc-dev#602. Signed-off-by: Pavel Karpy <[email protected]>
It is done automatically (as a sum of existing space on every file system available on the configured shards) but can be overwritten if `Capacity` attribute is provided via the application configuration. Closes nspcc-dev#602. Signed-off-by: Pavel Karpy <[email protected]>
It is done automatically (as a sum of existing space on every file system available on the configured shards) but can be overwritten if `Capacity` attribute is provided via the application configuration. Closes nspcc-dev#602. Signed-off-by: Pavel Karpy <[email protected]>
It is done automatically (as a sum of existing space on every file system available on the configured shards) but can be overwritten if `Capacity` attribute is provided via the application configuration. Closes nspcc-dev#602. Signed-off-by: Pavel Karpy <[email protected]>
It is done automatically (as a sum of existing space on every file system available on the configured shards) but can be overwritten if `Capacity` attribute is provided via the application configuration. Closes #602.
Testnet config ignores capacity attribute right now, so everyone has the same zero capacity and it does not affect placement function. However in the main network this is gonna be different. Do we need to provide some capacity value in testnet? How do we motivate user to set realistic available capacity value in config?
/cc @realloc @anatoly-bogatyrev
The text was updated successfully, but these errors were encountered: