Skip to content

analyze: unknown-size chunk-mode reads collapse to one chunk without disclosure #18

Description

@echemythia

Problem

In default chunk mode, to_blocks maps a GET with neither range nor size to object#0. Repeated unsized reads of a large object can therefore look like repeated accesses to one resident chunk.

I reproduced the shape with raw NormEvent input containing repeated GETs for one object and no size or range. analyze --fast in chunk mode reported distinct: 1, high LRU savings and a CACHE IT style recommendation.

Impact

When size or extent coverage is poor, default chunk mode can overstate cacheability and publish a chunk-count recommendation that is not tied to the true object footprint.

Normal s3tap GETs with Content-Length are less exposed because the adapter populates size and chunk mode expands from it. This mainly affects unsized raw NormEvent input and captures where Content-Length is absent.

Expected direction

Track size or extent coverage in TraceAnalysis and either disclose the unknown-size share or mark the chunk-mode verdict unjudged when too much of the workload collapses to the fallback chunk.

Relevant paths

  • crates/s3tap-replay/src/ibm.rs::to_blocks
  • crates/s3tap-advisor/src/analyze.rs::analyze_trace
  • crates/s3tap-advisor/src/analyze.rs::render

Metadata

Metadata

Assignees

No one assigned

    Labels

    analyzeDeep caching and prefetch analysis commandbugSomething isn't workingknown-limitationAccepted limitation documented for usersreplayOffline replay, cache and prefetch modeling

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions