STORAGE WORKLOAD AND EVALUATION WORKSHEET
Yenra | Updated October 12, 2026
Guide: https://yenra.com/parallel-hybrid-file-storage-system/

Use before a storage demonstration or pilot. Complete requirements first,
then enter observed results. Mark unknowns explicitly. Use approved disposable
test data and vendor-approved procedures in a test environment. Do not run
failure tests on production data. Keep confidential identifiers out of shared
copies of this worksheet.

1. PURPOSE AND WORKLOAD
Owner / review date:
Application and task to complete:
Number of simultaneous clients and workers:
Client operating systems, versions, and supported storage clients:
Protocols / access methods:
File count and directory structure:
File-size distribution (state units and representative ranges):
Read/write mix and sequential/random pattern:
Peak and ordinary demand; checkpoint/backup overlap:
Existing usable capacity / current use / required working space:
Growth per month (GB or TB, identify decimal or binary units):
Planning horizon and retention requirements:

2. ACCEPTANCE CRITERIA (FILL BEFORE TESTING)
Required job completion time:
Per-worker and aggregate throughput (MB/s or GB/s):
Latency requirement (milliseconds; identify percentile or maximum):
Metadata operations and required rates (operations/second):
Longest acceptable interruption (recovery time objective, hours):
Maximum acceptable lost work (recovery point objective, hours):
Required restored dataset size and completion time:
Who approves the criteria:

3. BANDWIDTH SANITY CHECK
Simultaneous workers x required MB/s per worker = aggregate MB/s.
Multiply aggregate MB/s by 8 / 1000 to obtain decimal Gbit/s of payload.
Allow for protocol overhead and competing traffic; then measure end to end.

Fictional example: 8 x 250 MB/s = 2,000 MB/s = 2 GB/s = 16 Gbit/s.
A single shared 10 Gbit/s path has a 1,250 MB/s raw ceiling, before overhead.
A 25 Gbit/s path has a 3,125 MB/s raw ceiling. This is no guarantee of achieved
throughput. Check topology, client paths, storage, and real job completion.
Multiple links help only when the traffic can use them.

Our calculation and assumptions:
Shared bottlenecks and traffic competing for them:

4. TEST CONFIGURATION
Hardware/media and storage software versions:
Network topology, link rates, and gateways:
Client software/driver versions and protocol:
Raw capacity / protection overhead / operational reserve / usable capacity:
Test dataset size, file counts, and placement:
Cache state (cold/warm) and method used to establish it:
Tools, versions, command record, and log location:
Repetitions and concurrent background work:

5. RESULTS (REPEAT THIS BLOCK FOR EACH TEST)
Test / date / operator:
Clients and workload:
Aggregate throughput and per-client variation:
Latency metric and measured result:
Metadata operation type and measured rate:
Job completion time:
Errors and unexpected behavior:
Result against predeclared criterion: pass / fail / unknown:
Evidence file and follow-up:

6. RECOVERY AND OPERATIONS
Approved degraded-service / rebuild test and observed impact:
Independent backup destination and access controls:
Restore procedure, dataset size, elapsed time, and file checks:
Observed lost-work interval and interruption versus objectives:
Permissions and access-control verification:
Monitoring, escalation, maintenance, and staffing:
Expansion procedure and expected disruption:

7. COST AND DECISION
Hardware / network / software subscriptions / support:
Administration / spare capacity / backup and recovery costs:
Quote date, currency, term, and exclusions:
Unresolved compatibility or support questions:
Evidence supporting a selection, further pilot, or rejection:
Decision owner and next review trigger:

METHOD REFERENCES
IOR/mdtest project: https://github.com/hpc/ior
Cache effects: https://ior.readthedocs.io/en/latest/userDoc/tutorial.html
These tools measure selected behaviors. Validate results with the actual
application workload. The example above is arithmetic, not a product claim.