Accessing local storage outside the container when reading objects #1433

New issue

Open

opened 2025-12-28 17:22:59 +00:00 by sami · 0 comments

sami commented

2025-12-28 17:22:59 +00:00

Owner

Originally created by @cthulhu-rider on GitHub (Jun 23, 2025).

currently, SN object read (GET/HEAD/RANGE) handler always accesses local storage. If the object is present, SN does not access the container members

normally, SN outside the container does not store its objects on a permanent basis. There is a transitional state when SN, after the epoch change, leaves the container and begins to migrate data to a new location. The faster this is done, the more efficiently the cluster functions

in total:

local lookup makes sense, and sometimes even necessary
hitting an object is either completely impossible or possible, but the probability drops rapidly over time

i think all this makes unconditional touching of local storage impractical

Describe the solution you'd like

manage list of to-migrate containers for which SN stores data locally but does not belong to. Iff requested container is non-local and to-migrate one, skip local read

the list is update on:

SN init
new epoch in runtime
container migration finish

having this list, whole migration procedure may go faster. Afaik it is object-by-object now

Describe alternatives you've considered

no for now

Additional context

i've run 10m load to GET object of 4K payload size from REP 1 container through non-container SN. Here's cpu.pb.gz profile of proxy node. As we can see, local execution takes ~20% time

Originally created by @cthulhu-rider on GitHub (Jun 23, 2025). ## Is your feature request related to a problem? Please describe. currently, SN object read (GET/HEAD/RANGE) handler always accesses local storage. If the object is present, SN does not access the container members normally, SN outside the container does not store its objects on a permanent basis. There is a transitional state when SN, after the epoch change, leaves the container and begins to migrate data to a new location. The faster this is done, the more efficiently the cluster functions in total: 1. local lookup makes sense, and sometimes even necessary 2. hitting an object is either completely impossible or possible, but the probability drops rapidly over time i think all this makes unconditional touching of local storage impractical ## Describe the solution you'd like manage list of to-migrate containers for which SN stores data locally but does not belong to. Iff requested container is non-local and to-migrate one, skip local read the list is update on: * SN init * new epoch in runtime * container migration finish having this list, whole migration procedure may go faster. Afaik it is object-by-object now ## Describe alternatives you've considered no for now ## Additional context i've run 10m load to GET object of 4K payload size from `REP 1` container through non-container SN. Here's [cpu.pb.gz](https://github.com/user-attachments/files/20861427/cpu.pb.gz) profile of proxy node. As we can see, local execution takes ~20% time