mirror of
https://github.com/nspcc-dev/neofs-node.git
synced 2026-03-01 04:29:10 +00:00
Shard doesn't switch to read-only mode when shard_ro_error_threshold reached ("error": "could not save the object in any blobovnicza") #873
Labels
No labels
I1
I2
I3
I4
S0
S1
S2
S3
S4
U0
U1
U2
U3
U4
blocked
bug
config
dependencies
discussion
documentation
enhancement
enhancement
epic
feature
go
good first issue
help wanted
neofs-adm
neofs-cli
neofs-cli
neofs-cli
neofs-ir
neofs-lens
neofs-storage
neofs-storage
performance
question
security
task
test
windows
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
nspcc-dev/neofs-node#873
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @anikeev-yadro on GitHub (Nov 9, 2022).
Originally assigned to: @fyrchik on GitHub.
Related to https://github.com/nspcc-dev/neofs-node/issues/1857
Expected Behavior
Shard should switch to read-only mode when when shard_ro_error_threshold reached.
Current Behavior
Shard doesn't switch to read-only mode when shard_ro_error_threshold reached
Steps to Reproduce (for bugs)
1.Make some WRITE disk errors on the shard:
2.shard_ro_error_threshold reached, but shard doesn't switch to read-obly mode according to config:
Config: config.zip
Config of unreliablefs:
Versions:
Your Environment
Server setup and configuration:
cloud, 4 VMs, 4 SN, 4 http qw, 4 s3 gw
Operating System and version (uname -a):
linux vedi 5.10.0-16-amd64 https://github.com/nspcc-dev/neofs-node/issues/1 SMP Debian 5.10.127-1 (2022-06-30) x86_64 GNU/Linux
@fyrchik commented on GitHub (Nov 9, 2022):
Related #2013. This is currently an expected behaviour. Let's think if we can do better.
To be clear, background errors accumulate without switching mode. All user operations still trigger mode switch.
@anikeev-yadro commented on GitHub (Nov 9, 2022):
Logs :bug_err_count2.tar.gz.zip
@anikeev-yadro commented on GitHub (Nov 9, 2022):
As example we can use 2 different counters: internal operation errors and user operation errors. Switching mode will happen only if the user operational errors reached threshold.
@fyrchik commented on GitHub (Nov 12, 2022):
Closed via #2032