Implement metabase repairer #132

New issue

Open

opened 2025-12-28 17:18:31 +00:00 by sami · 2 comments

sami commented

2025-12-28 17:18:31 +00:00

Owner

Originally created by @cthulhu-rider on GitHub (Feb 17, 2021).

Proposal

Repairer - a background job that periodically (relatively rarely) checks the logical integrity of data in the local metabase. The main goal is to identify situations that should not arise during error-free operation of the base, but in the event of an actual occurrence they can and should be corrected.

Example

Metabase graveyard should not have a record Tombstone: Tombstone. Repairer can search for this type of records and remove them.

Originally created by @cthulhu-rider on GitHub (Feb 17, 2021). ## Proposal `Repairer` - a background job that periodically (relatively rarely) checks the logical integrity of data in the local metabase. The main goal is to identify situations that should not arise during error-free operation of the base, but in the event of an actual occurrence they can and should be corrected. ## Example Metabase graveyard should not have a record `Tombstone: Tombstone`. Repairer can search for this type of records and remove them.

sami added the

neofs-storage

feature

labels

2025-12-28 17:18:31 +00:00

sami commented

2025-12-28 17:18:31 +00:00

Author

Owner

@roman-khimov commented on GitHub (May 12, 2025):

Scrubber that is. With two threads in fact: one iterating over physical objects, checking their state and metabase representation and the other iterating over metabase and checking its contents relative to physical objects.

@roman-khimov commented on GitHub (May 12, 2025): Scrubber that is. With two threads in fact: one iterating over physical objects, checking their state and metabase representation and the other iterating over metabase and checking its contents relative to physical objects.

sami commented

2025-12-28 17:18:31 +00:00

Author

Owner

@End-rey commented on GitHub (Oct 15, 2025):

During check #2202, it was discovered that we also need to synchronize the write-cache objCounter, because if the object suddenly disappeared physically from the write-cache, its internal counter will not change and will always indicate that the objects are present.

@End-rey commented on GitHub (Oct 15, 2025): During check #2202, it was discovered that we also need to synchronize the write-cache [`objCounter`](https://github.com/nspcc-dev/neofs-node/blob/dba6c1744c6af561e948d50833019f8f1b4b15fd/pkg/local_object_storage/writecache/options.go#L31), because if the object suddenly disappeared physically from the write-cache, its internal counter will not change and will always indicate that the objects are present.