Cross-posted from /r/android (u/BramblexD)
The press release refers to it as:
UltraSpace storage expansion is a patented Xiaomi technology implemented on Xiaomi 14 Series.² It makes use of available UFS memory to expand available storage beyond original capacity. This technology allows the 256GB version of Xiaomi 14 Pro’s storage to be expanded by 8GB, while the 512GB version of Xiaomi 14 and Xiaomi 14 Pro’s storage can be extended by 16GB,¹ allowing users more storage space to store more applications, photos, videos, and other data without unnecessarily increasing their hardware costs.
I’m not clear whether this refers to space for firmware or cache or both.
In the launch video (around 2:04:00) I would summarise what Lei Jun said as:
-
During writing HyperOS their engineers made a “discovery” that the UFS storage chips have 10GB+ storage reserved for “性能的优化” (Performance optimizations, so likely refers to UFS cache?)
-
They apparently optimised this to use much less space and so freeing up 8/16GB on their 256/512GB storage models, giving them “264/528GB” of actual usable storage.
-
Also interesting it doesn’t apply to the 1TB models, in which case either the full cache amount is more useful or the extra % storage is negligible.
This would be the first time we’ve seen a branch do this kind of optimisation.
Really skeptical of this feature. Could this be the overprovision space designed to improve longevity of the flash media? In that case, reclaiming the storage shortens the life of the device in exchange for increased capacity.
Of course, device sizes being what they are, that’s not a good trade.
Or they could have just added a SD card slot for an extra 1TB storage
Now that would be innovative. There are probably kids today who have never seen a phone with expandable storage or removable batteries.
So 3% more storage space in exchange of a slower, less reliable storage device. Thanks no.
I’m surprised compression isn’t a thing, like Stacker/DoubleSpace back in the DOS PC days. Even with mostly efficient data, I could imagine eking out 5% more capacity at the cost of lowered performance on disc-intensive tasks
I would guess it is probably mostly not worth the overhead at this point. Applications are generally compressed archives. The primary data created on mobile devices would be photos and videos, both of which use lossy compression algorithms to generate and wouldn’t compress any smaller. The remaining data that may be created on a phone like documents, PDFs, text files, would either already be semi-compressed, or so tiny in the grand scheme that the compression overhead wouldn’t buy much value.