user.emailandDevin be1ec2d7c7 s3sink: upload through a concurrent-safe ReaderAt so parts do not thrash ...

s3manager splits a seekable body into parallel section readers, and every
part's ReadAt landed on the single chunk buffer in ChunkStreamReader: parts
at different offsets kept evicting each other's chunk and refetching it
whole, which produced massive read amplification against the volume
servers and collapsed throughput.

Build the upload body from filer.ChunkReadAt instead, the same
concurrent-safe reader the mount and query paths use: each part's range is
served from a shared reader cache with parallel chunk fetches and
range-reads for clipped views, so every byte is fetched once per pass.

Generated with [Devin](https://devin.ai)

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>

2026-10-30 05:32:42 -07:00

..

repl_util

filer: authorize the chunk proxy and the root listing like the rest of the filer port (#11152)

2026-09-04 16:39:36 -07:00

sink

s3sink: upload through a concurrent-safe ReaderAt so parts do not thrash

2026-10-30 05:32:42 -07:00

source

filer.sync: unstick sync on chunks the source no longer has (#11845)

2026-10-19 18:11:51 -07:00

sub

filer.replicate: acknowledge notifications after the sink write, not on receipt (#10427)

2026-07-24 10:43:48 -07:00

replicator_test.go

filer.sync: skip superseded replays before fetching any chunks (#12212)

2026-10-29 13:37:27 -07:00

replicator.go

filer.sync: skip superseded replays before fetching any chunks (#12212)

2026-10-29 13:37:27 -07:00