freon command to read a user-supplied list of existing keys

[greenwich]

Summary

A small new freon subcommand, OzoneClientKeyListReader (ocklr), that reads a caller-supplied list of existing keys with a warm, reused OzoneClient and reports per-read latency (DropWizard timer) plus aggregate read throughput. It's a read-path benchmark/load generator for real, already-present data.

Motivation

freon's existing client read tools can only read keys they generated:

• ockg/ockv use prefix+index naming, and ockv validates every read against key-0's digest (assumes all keys have identical content).
• SameKeyReader (ocokr) reads one fixed key from many threads.
  There's no freon command to point at an arbitrary, heterogeneous set of existing keys (e.g. a real dataset already in a bucket) and measure read throughput. We hit this doing read-path performance work: we wanted warm-client single-stream vs parallel-scaling numbers on production-like data, not on freshly-generated uniform keys (which are page-cache-hot and not representative). ocklr fills that gap.

It also cleanly separates two effects that matter for read benchmarking — client warmth (JIT + pooled datanode connections, amortized by the reused client) vs datanode page-cache — and lets you drive concurrency with -t to find where read throughput saturates.

What it does

• --key-file <path>: local file, one key name per line; blank lines and # comments ignored.
• Reuses BaseFreonGenerator: warm shared OzoneClient, -t threads, -n total reads (task i reads keys[i % keys.size()], so -n loops the list), DropWizard timer.
• Per read: bucket.readKey(key) → drains the stream into a fixed buffer and counts bytes (no content/digest assumptions). Reports the key-read timer + an aggregate bytes / wall-time MB/s line.
• Same end-to-end read path as ozone sh key get / the FileSystem open() (readKey → KeyInputStream → BlockInputStream → ChunkInputStream → datanode ReadChunk), so the numbers reflect the real client read stack.

Example

ozone freon ocklr -v <volume> -b <bucket> --key-file /tmp/keys.txt -t 8 -n 160

Questions for the community

1. Is there interest in having this upstream? It's been useful for read-path benchmarking and capacity/scaling tests on real data.
2. Naming — ocklr follows the ockv/ockg/ocokr pattern; open to something clearer.
3. Any preference on output (custom aggregate line vs extending freon's standard report)?

If there's interest I'll file an HDDS JIRA and open a PR (code is ready).

[kerneltime]

Sounds like a really good addition.

[greenwich]

Ticket: https://issues.apache.org/jira/browse/HDDS-15586