Skip to content
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

Node should *not* delete POST files when there is more on a disk than configured #4594

Closed
pigmej opened this issue Jun 26, 2023 · 9 comments
Closed
Assignees

Comments

@pigmej
Copy link
Member

pigmej commented Jun 26, 2023

In the situation when there are more post files than node expects node should error and give up, and not delete the files.

That should help not surprise users with "your data is gone because config was wrong".

In the situation when there are too less files, then node should clearly indicate that it will generate more.

There probably should be a flag that would change node behavior:

  • --do-not-touch-pos and then it should fail regardless of the found situation on the disk (smaller, bigger etc).
  • we could have a flag that would keep current behaviour too.
@schinzelh
Copy link

I just lost 1 TiB post data due to this "feature" - please fix this ASAP!

@lrettig
Copy link
Member

lrettig commented Sep 13, 2023

See also spacemeshos/post#236

@pigmej
Copy link
Member Author

pigmej commented Sep 25, 2023

It will be addressed with spacemeshos/pm#259

@lrettig
Copy link
Member

lrettig commented Sep 28, 2023

This is still happening

@Stizerg
Copy link

Stizerg commented Dec 1, 2023

I lost 4TiB today, when will you fix it?
--do-not-touch-pos should be default behavior.
there's so many complains since testnet, more than 6 month later the issue haven't been fixed

@pigmej
Copy link
Member Author

pigmej commented Dec 4, 2023

Post-service implementation will have that fixed, as mentioned #4594 (comment)

@ytx1991
Copy link

ytx1991 commented Dec 27, 2023

I believe the issue could be resolved in less than 10 minutes; however, it seems there is a lack of willingness to address user concerns promptly.

@lrettig
Copy link
Member

lrettig commented Dec 27, 2023

I believe the issue could be resolved in less than 10 minutes; however, it seems there is a lack of willingness to address user concerns promptly.

Our small development team is very busy focusing on network stability. This is an open source project. Feel free to make the desired change and submit it as a PR here! We're more than happy to review.

For the record, if it were a "ten minute change" we would've made it a long time ago. The change is more complex as it ties into the post service work that @pigmej mentioned above.

@pigmej
Copy link
Member Author

pigmej commented Feb 11, 2024

This is fully solved with post-service.

@pigmej pigmej closed this as completed Feb 11, 2024
@github-project-automation github-project-automation bot moved this from 🔖 Next to ✅ Done in Dev team kanban Feb 11, 2024
@pigmej pigmej reopened this Feb 11, 2024
@fasmat fasmat closed this as completed May 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

No branches or pull requests

7 participants