Conventional Universal Flash Storage presents overwrite-anywhere logical blocks. Its controller translates each 4KB logical page to NAND, but a 1TB device would need a mapping table too large for mobile SRAM. Hierarchical maps move entries between flash and cache. As the random address range expands, mapping misses add NAND reads and unpredictable latency.
Zoned UFS replaces most page mapping with a write pointer per large zone. Hosts write sequentially and reset a zone before reusing it. The compact zone mapping can remain in SRAM, and aligning zones with erase geometry reduces device garbage collection. That apparent simplification transfers responsibility upward: F2FS, the block scheduler, SCSI/UFS drivers, Android power management, and firmware must all preserve write order.
The paper reports a commercial flagship-phone path rather than a datacenter ZNS transplant. Mobile UFS has a small SRAM budget, half-duplex links, aggressive power states, Android per-file encryption, and an F2FS deployment history. The design modifies each layer instead of assuming the device interface alone supplies the benefit.
Several open zones compete for a few megabytes of SRAM
F2FS separates hot and cold data and metadata into concurrent write streams. A zoned device therefore needs several open zones. A naive controller assigns one full superpage buffer to each zone so NAND can be programmed across all dies. In the evaluated geometry, seven 768KB buffers would already consume more SRAM than the mobile controller can dedicate.
The proposed Zone-Aware Buffer Management allocates slots at the program-unit granularity of one die, 192KB in the prototype. Slots move dynamically toward zones receiving more writes. A zone can flush one die’s unit as soon as it fills, release the slot, and overlap host intake with NAND programming instead of waiting for a 768KB superpage.
Compared with an emulation of the earlier ZMS approach, 192KB flushing improved throughput 26%. Restricting the new scheme to 768KB produced nearly the same throughput as 192KB, indicating that dynamic allocation as well as granularity contributes. The paper could not use ZMS source code and reproduced its documented buffering behavior, so the comparison is an emulation rather than a direct implementation contest.
Ordering must survive power management
A zoned device accepts a write only at the current zone write pointer. Linux zone write locking serializes writes per zone, but correct issue order can still be lost below the block scheduler. SCSI command handling, error retry, queue reinsert, clock gating, and UFS power transitions can release or reorder a later request before an earlier one completes.
The implementation changes SCSI and UFS drivers so gating and ungating do not violate the zone sequence. Several fixes were upstreamed to Android and Linux kernels. This is a correctness requirement, not a tuning detail. One reordered write can fail the command or leave filesystem recovery with a write pointer different from its expected log position.
Per-file encryption adds another constraint because encryption units and metadata must follow the same ordered data path. Device reset and power loss require the host to report zones, reconstruct write pointers, and reconcile them with F2FS checkpoints before admitting new writes. Testing only steady-state throughput would miss the hardest deployment failures.
Large zones make filesystem garbage collection visible
F2FS normally uses selective in-place updates in some conditions, including fsync, to reduce write amplification. Zoned media forbids those overwrites, forcing pure log-structured operation for the zoned logical unit. Large zones also make reset the reclaim unit, so a few live segments can pin a much larger region.
The design migrates valid data between zones and performs background collection before free sections are exhausted. Policies divide operation into no-GC, normal-GC, and boosted-GC phases according to free and dirty segments. User reads preempt reclamation so background copying does not destroy perceived responsiveness.
This policy deliberately spends background bandwidth to avoid foreground collection. It is effective when the phone has idle or low-contention intervals, but energy and thermal cost still matter. A mobile rollout should record bytes migrated, wake time, energy per reclaimed GB, free-zone reserve, and the fraction of GC overlapping user activity.
A real handset exposes mapping-cache and aging effects
Experiments used a Google Pixel 10 Pro with 12GB LPDDR5X and a 512GB Zoned UFS device, Android 16, Linux 6.6, and F2FS. The conventional baseline used the same hardware’s conventional logical unit across the full volume, limiting differences to storage mode and its required software path. ZUFS mounted F2FS in pure log-structured mode.
With a 4GB random-read range, conventional and zoned modes were similar because the conventional mapping working set fit in controller SRAM. Expanding the range through 256GB increased conventional mapping misses and reduced throughput, while the zoned mapping table remained resident and throughput stayed stable. The advantage was greatest below 128KB request sizes; at larger sizes, one mapping lookup was amortized over more data.
The aging test repeatedly created 32,768 files of 128KB, deleted every second file, then wrote and read a 1GB test file until free space fell below 1GB. Around iteration 90, conventional UFS exhausted free F2FS segments. Sequential write throughput fell to about 100MB/s and read throughput dropped about 35% as foreground GC began.
Zoned UFS transitioned into normal and boosted background collection earlier. Write throughput dipped around policy transitions but stayed above 200MB/s, more than twice the conventional lower bound, and reads remained stable. The result combines zoned mapping, sequential placement, and proactive F2FS policy; it should not be attributed to hardware alone.
Application layout turns into user-visible time
The game test installed approximately 40GB of Genshin Impact resources on an aged device. Verification issued sequential and fragmented reads before launch. Zoned UFS completed verification and loading in 30 seconds versus 35 seconds for conventional UFS, a 14% reduction.
Request distributions explain the difference. Conventional F2FS selective segment reuse scattered extents, placing 66.3% of reads in the 4KB to 8KB bucket. Sequential zoned placement made most requests larger than 512KB, allowing the device to approach raw bandwidth. The improvement is therefore a long-term layout effect, not a five-second acceleration of a fresh empty phone.
The workload is one game and one aging recipe. Other applications may be CPU-bound during launch, use compressed asset archives, or read through a cache. User studies should include install, update, deletion, camera bursts, messaging databases, low-free-space operation, and months of idle background maintenance.
The product decision spans standards, firmware, and filesystem policy
Zoned UFS reduces mapping SRAM and exposes sequentiality that matches F2FS, but the interface must reveal enough geometry for efficient buffering without locking software to one NAND generation. Firmware needs per-zone telemetry, trim/reset latency, program-unit hints, and error recovery semantics. Standards must preserve portability while allowing controllers to evolve.
The host needs ordered queues, version-compatible kernel fixes, encryption correctness, and background GC thresholds tied to power and thermal state. Device qualification must age both modes on the same silicon, interrupt writes during every power transition, and verify F2FS recovery. Capacity reserve and open-zone limits should be treated as product resources, not hidden firmware constants.
Compatibility also extends through over-the-air updates. A phone can receive a new Android framework, kernel, filesystem tool, or firmware while retaining an existing zoned volume. Upgrade tests must cover open and closed zones, an interrupted background-GC phase, nearly full media, and rollback to the previous system image. Fsck needs to distinguish a recoverable host checkpoint mismatch from a device write-pointer error; resetting a zone as a generic repair would destroy every still-valid segment inside it. Fleet telemetry should therefore identify storage mode, format revision, kernel build, firmware, free-zone reserve, and the last successful consistency scan. Those fields let an operator correlate a performance regression or recovery failure with the layer that changed instead of attributing every zoned fault to flash.
The paper’s 14% application result and greater-than-twofold fragmented write floor show why this coordination can be worth it. They also establish the denominator: the benefit appears after mapping working sets exceed SRAM and conventional F2FS becomes fragmented. On a lightly used phone with small active data, the modes were close.
Zoned UFS is therefore not merely a lower-cost mapping table. It is a storage contract that makes placement and reclamation visible to Android. The commercial implementation succeeds because it carries that contract from F2FS to NAND and designs every power, buffer, and recovery transition around it.
Source and copyright notice
This article is an editorial analysis by Silicon & Systems. It restates the implementation, measurements, and limitations in our own words. No source sentence, table, or figure is reproduced; the figure was created for this article. The paper is available from the USENIX FAST 2026 presentation page. Copyright remains with the authors, 2026.