How Kalstor qualifies flash storage: a data-backed OEM workflow

Kalstor qualifies a flash-storage project by connecting four things that are often separated: the application, the proposed configuration, the sample evidence and the repeat-order controls. The process applies across microSD, SSD, USB modules and embedded eMMC/UFS, but the exact test matrix changes with the product and risk.

Qualification does not mean “a sample powered on once.” It means the buyer and supplier can answer which device was tested, under what conditions, against which acceptance criteria, and whether the future production configuration is controlled relative to that approval.

Kalstor is the commercial and export interface for these projects. Production, assembly and manufacturing tests are performed by source partners. The value Kalstor must add is not a vague factory story: it is converting the buyer's application into a reviewable configuration, sample plan, evidence package and repeat-order rule.

What “data-backed” means in a Kalstor project

Data support is not the same as filling a page with benchmark numbers. A useful number has a unit, method, sample identity, condition and decision limit. Kalstor separates four evidence types:

Every project should label the source of a number. Calculations keep their assumptions; measurements keep raw logs; published ratings keep the document revision. A value copied from a marketplace listing without a test method is not equivalent evidence.

Turn the application into numerical requirements

Suppose an edge recorder writes 220GB per day, operates for five years and uses a buyer-selected 30% endurance allowance:

Five-year host writes = 220 × 365 × 5 = 401,500GB = 401.5TB
Budget with allowance = 401.5 × 1.30 = 521.95TB
Workload on a 1TB SSD = 220 ÷ 1,000 = 0.22 DWPD

This does not prove that a drive rated above 522TBW is suitable. The rating must apply to the quoted capacity and warranty conditions; the test must also cover sustained throughput, latency, power recovery, temperature and host compatibility. The calculation prevents a low-endurance candidate from entering the sample stage without explanation.

For a four-channel recorder writing an aggregate 32 Mbit/s, the host write load is 32 × 10.8 = 345.6GB/day, or about 126.1TB/year. That number connects the camera specification to both microSD and SSD endurance discussions. It also shows why “4K” is an inadequate requirement: measured aggregate bitrate is the actionable field.

A baseline evidence matrix, with explicit limits

The following is an example starting matrix for a medium-risk embedded program. It is not a universal Kalstor guarantee; quantities and durations must change with consequence, lot size, interface and buyer acceptance rules.

The numbers are deliberately visible so buyer and supplier can change them. “Power-cycle tested” is ambiguous; “five samples, 200 controlled cuts each, distributed before/during/after flush, zero prohibited recovery outcomes” can be reviewed.

The same clarity applies to pass criteria. “No errors” should identify which counters were observed, how long the test ran and what counts as an error. A recorder may continue writing while silently dropping timestamps; a storage benchmark can complete while missing the application deadline.

Sample size: what zero failures actually says

Qualification often overstates small samples. When zero failures are observed in n independent representative trials, the rule-of-three approximation places the upper 95% confidence bound near 3/n. It is an approximation to a one-sided binomial limit; exact binomial methods are preferable when the decision depends on the boundary [12].

This is not a substitute for a formal acceptance-sampling plan. Storage failures may be lot-correlated, tests may not be independent and accelerated conditions may not represent field use. The table prevents one common mistake: claiming a near-zero population failure rate because a few dozen hand-selected samples passed.

Use a small sample to find gross incompatibility early. Use multiple production lots, sufficient cycle counts and a statistically justified plan when the business claim concerns a low field-failure rate.

The tools have different observation boundaries

F3 writes and reads data across available flash capacity and is useful for detecting false capacity, address aliasing and unreadable data [6]. It does not expose raw NAND ECC margin or identify the controller's hidden spare blocks.

fio can define block size, read/write mix, queue depth, runtime, data verification and latency percentiles [7]. Its official documentation supports custom percentile lists such as p99.9 and distinguishes submission, completion and total latency. A useful log therefore keeps the complete job file, fio version and output instead of a screenshot of one bandwidth number.

The Linux MMC test framework exercises host-controller and MMC/SD interactions, including verified writes, varied transfer sizes, random access and non-blocking operations [8]. mmc-utils can capture CID/CSD and eMMC EXT_CSD and expose configuration functions such as cache, BKOPS and write reliability where supported [9]. For NVMe, NVMe-CLI exposes SMART/health fields including temperature, percentage used and data units written [10].

Kalstor does not treat these tools as interchangeable. Tool selection follows the failure mechanism and interface. A full-address utility does not replace a real-host boot test; a 30-second speed result does not replace sustained-state data; a health log does not prove power-loss recovery.

Gate 1: define the application before selecting the part

A capacity and interface are not enough. Kalstor begins with an application brief [1]:

These inputs expose false equivalence. Two 128 GB SSDs may fit the same connector but differ in protocol, sustained write, power-loss behavior and firmware. Two V30 microSD cards may meet a speed-class test yet behave differently under continuous overwrite, high temperature or long retention.

Gate 2: document the proposed configuration

The sample should be attached to a proposal, not handed over as an anonymous device. Depending on the product and confidentiality level, the proposal can identify:

• commercial part number and revision;
• capacity, interface, package or form factor;
• controller and NAND scope where available;
• firmware version or controlled branch;
• temperature/endurance grade and relevant options;
• label, packaging, preload or provisioning requirements;
• current sample terms, MOQ, lead time and quote validity.

Kalstor's role is to make the commercial boundary clear. Manufacturing partners perform production, assembly and testing. Applicable certificates, test reports and configuration details are confirmed for the proposed product; they are not inferred from a generic factory statement.

Gate 3: capture the sample identity

Before testing, record enough information to reproduce or investigate the result:

• model and serial number, where exposed;
• reported capacity and interface;
• firmware revision;
• CID/CSD for SD cards or NVMe/SATA identity fields for SSDs;
• label and package revision;
• sample lot, date code or supplier trace code where available;
• host, adapter, cable and test-software versions.

Photographs of both sides and screenshots of identity tools are inexpensive evidence. A file named “sample-final-2” is not traceability.

Gate 4: choose tests by failure mechanism

No single utility proves that storage is good. Each method has an observation boundary [2][3].

Capacity and addressability

A full-capacity write/read test can detect false capacity, address aliasing and unreadable regions. A read-only full-address scan is useful for host-visible readability but cannot prove that every address accepts and retains newly written data.

Host compatibility

Enumerate, initialize, format, mount, suspend, resume, reboot and recover in the intended platform. For soldered eMMC/UFS, include board assembly and boot-path checks. For removable media, repeat insertion and power transitions where relevant.

Performance and latency

Measure the workload that matters: sustained recording, random writes, queue behavior, cache exhaustion, thermal steady state and latency percentiles. A short sequential benchmark is not a substitute for a multi-hour production workload.

Data integrity

Use known data, cryptographic hashes or an application-level checksum. Preserve the expected hash, file manifest, test duration and mismatch count. For preload, compare the golden image or manifest after replication.

Power behavior

Where abrupt power loss is credible, test it with a controlled fixture and defined interruption points. Verify both user data and file-system or application recovery. Do not claim PLP merely because the device rebooted.

Temperature and retention

Exercise the configuration across the specified operating range and, where appropriate, controlled storage/retention conditions. Record when data was written, at what temperature, how long it was stored and how it was verified afterward.

Gate 5: write acceptance criteria before seeing the result

Acceptance criteria prevent a test from becoming a story written after the fact. A matrix might include:

A “Pass” without these fields is hard to compare later. The record should also state what was not observed. A host-visible test cannot see raw NAND RBER, hidden block retirement or the controller's proprietary ECC margin unless the device exposes those metrics.

Gate 6: review the evidence package

Before volume approval, a useful package may include:

1. proposed datasheet and configuration summary;
2. sample identity and photographs;
3. test plan, tools and acceptance limits;
4. raw logs, screenshots and checksum records;
5. exception list and engineering disposition;
6. applicable supplier or quality-system documents;
7. commercial scope: MOQ, lead time, packaging and validity;
8. configuration-control and change-notification terms.

Document availability varies by project and may require an NDA. The important point is to request evidence before the production purchase order, not after a field failure.

Gate 7: approve the configuration, not only the sample

The approval statement should identify the reference configuration and any allowed variation. Possible outcomes include:

• approved exactly as sampled;
• approved within a defined controller/NAND/firmware equivalence set;
• approved with application restrictions;
• conditionally approved pending one additional test;
• rejected with a documented failure mode.

If a fixed configuration is required, the commercial documents should say which fields are fixed. “Same performance” is not a complete substitution rule. A replacement could match sequential throughput and still change power-loss behavior, thermal throttling, endurance or host compatibility.

Gate 8: connect incoming lots to the approval

Repeat-order control begins when production arrives [4]. Incoming inspection can verify:

• purchase order, part number, quantity and packaging;
• label, serial range, date code or trace code;
• reported identity, capacity and firmware on a sampled basis;
• visual workmanship and connector/package condition;
• agreed functional, capacity or checksum tests;
• differences from the approved golden sample.

Sampling must match the risk. A small sample can detect common gross defects but cannot prove a near-zero field-failure rate. For high-consequence applications, use multiple lots, environmental conditioning, longer workloads and statistically defensible acceptance plans.

Change control and requalification

A PCN/EOL process should define which events require action:

The response should be proportional to the effect, not merely the supplier's name for the change. A “minor” firmware update can alter power recovery or host compatibility; a packaging change may be low risk if the controlled product remains identical.

When a field problem occurs

An RMA should preserve evidence before devices are reformatted or discarded [5]. Record the host, workload, power history, environment, symptom, timestamps, logs, device identity and a minimal reproduction path. Separate user-data recovery from root-cause analysis: destructive testing may help diagnosis but destroy the only recoverable copy.

Kalstor's useful role is to connect the field evidence to the approved configuration and manufacturing/supplier trace. A credible conclusion distinguishes confirmed root cause, contributing factors and unproven hypotheses.

The Kalstor qualification principle

Qualification is a chain of custody for technical decisions:

application -> proposed configuration -> identified sample -> controlled test -> approval record -> incoming lot -> repeat order -> change review

Breaking any link creates ambiguity. The purpose of the Kalstor workflow is not to promise that storage never fails. It is to make selection, evidence, acceptance and change control explicit enough that buyers can reduce avoidable risk and investigate the remainder.

For the brand definition, read What is Kalstor?. For the product map, read What does Kalstor supply?.