netmap: Clarify MaxObjectSize parameter implication on object size #63
No reviewers
Labels
No labels
P0
P1
P2
P3
good first issue
triage
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No milestone
No project
No assignees
6 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-api#63
Loading…
Reference in a new issue
No description provided.
Delete branch "a-savchuk/frostfs-api:doc-max-object-size"
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?
Close #50
Signed-off-by: Aleksey Savchuk a.savchuk@yadro.com
8780d30a3f
tob0415c455d
b0415c455d
to83bb8cc4ba
83bb8cc4ba
to30f2eb344d
30f2eb344d
to56bdadd74d
56bdadd74d
toc1eba27379
@ -291,1 +291,4 @@
// Value: little-endian integer. Default: 0.
//
// This value refers to the maximum size of a **physically** stored object
// in NeoFS. However, from a user's perspective, the **logical** size of a
FrostFS
But NeoFS is used throughout the documentation. Should I change all occurrences to keep it consistent?
Yes, but in a separate commit, please
Done
@ -203,3 +203,2 @@
// * Continent \
// Node's continent name according to the [Seven-Continent model]
// (https://en.wikipedia.org/wiki/Continent#Number). Calculated
// Node's continent name according to the [Seven-Continent
How could it be misformatted if we have just merged PR where actions were green?
It's just an incorrectly formatted link e.g.
[frostfs] (git.frostfs.info)
, where an extra space in the middle will cause it to render as-is, rather than as the intended frostfs. It's not the responsibility of current actions to check for such issuesWIP: netmap: Clarify MaxObjectSize parameter implication on object sizeto netmap: Clarify MaxObjectSize parameter implication on object sizec1eba27379
to2a46a9ea0a