在相當長的一段時間內，人們不建議使用快閃記憶體來執行桌面系統，比如Windows。但是，是什麼讓它成為移動裝置的理想和可行的選擇呢？今天的超級使用者問答帖子回答了一位好奇的讀者的問題。

今天的問答環節是由SuperUser提供的，SuperUser是Stack Exchange的一個分支，是一個由社群驅動的問答網站分組。

問題

超級使用者閱讀器RockPaperLizard想知道是什麼讓eMMC快閃記憶體在移動裝置上可行，而不是在PC上：

Ever since USB flash drives were invented, people have wondered if they could run their operating systems on them. The answer was always “no” because the number of writes required by an operating system would quickly wear them out.

As SSDs have become more popular, wear-leveling technology has improved in order to allow operating systems to run on them. Various tablets, netbooks, and other slim computers use flash memory instead of a hard drive or SSD, and the operating system is stored on it.

How did this suddenly become practical? Do they typically implement wear-leveling technologies, for example?

是什麼讓eMMC快閃記憶體在移動裝置上可行，而不是在pc上？

答案

超級使用者貢獻者Speeddymon和Journeyman Geek為我們提供了答案。首先，Speeddymon：

All flash memory devices, from tablets to mobile phones, **art watches, SSDs, SD cards in cameras, and USB thumb drives use NVRAM technology. The difference is in the NVRAM architecture and how the operating system mounts the file system on whatever storage medium it is on.

For Android tablets and mobile phones, the NVRAM technology is eMMC based. The data I can find on this technology suggests between 3k to 10k write cycles. Unfortunately, none of what I have found so far is definitive, as Wikipedia is blank on this technology’s write cycles. All other places that I have looked happened to be various forums, so hardly what I would call a reliable source.

For comparison’s sake, the write cycles on other NVRAM technology such as SSDs, which use NAND or NOR technology, are between 10k and 30k.

Now, regarding the operating system’s choice of how to mount the file system. I cannot speak on how Apple does it, but for Android, the chip is partitioned out like a hard drive would be. You have an operating system partition, a data partition, and several other proprietary partiti*** depending on the device manufacturer.

The real root partition lives inside the bootloader, which is bundled as a compressed file (jffs2, cramfs, etc.) together with the kernel, so that when the device’s stage 1 boot is complete (the manufacturer’s logo screen usually), then the kernel boots and the root partition is simultaneously mounted as a RAM disk.

As the operating system boots up, it mounts the primary partition’s file system (/system, which is jffs2 on devices before Android 4.0, ext2/3/4 on devices since Android 4.0, and xfs on the latest devices) as read-only so that no data can be written to it. This can, of course, be worked around by so-called “rooting” of your device, which gives you access as a super user and allows you to remount the partition as read/write. Your “user” data is written to a different partition on the chip (/data, which follows the same convention as above based on the Android version).

With more and more mobile phones ditching SD card slots, you might think that you will hit the write cycle cap sooner because all of your data is now being saved to eMMC storage instead of an SD card. Fortunately, most file systems detect a failed write to a given area of storage. If a write fails, then the data is silently saved to a new area of storage and the bad area (known as a bad block) is cordoned off by the file system driver so that data is no longer written there in the future. If a read fails, then the data is marked as corrupt and either the user is told to run a file system check (or check disk), or the device automatically checks the file system during the next boot.

As a matter of fact, Google has a patent for automatically detecting and handling bad blocks: Managing bad blocks in flash memory for electronic data flash card

To get more to the point, your question on how this suddenly became practical is not the right question to ask. It was never impractical in the first place. It was strongly advised against installing an operating system (Windows) on an SSD (presumably) because of the number of writes it does to a disk.

For example, the registry receives literally hundreds of reads and writes per second, which can be seen with the Microsoft-SysInternals Regmon Tool.

Installing Windows was advised against on first generation SSDs because with the lack of wear leveling, the data written to the registry every second (likely) eventually caught up to early adopters and resulted in unbootable systems due to registry corruption.

With tablets, mobile phones, and pretty much any other embedded device, there is no registry (Windows Embedded devices being excepti***, of course) and thus, there is no worry of data c***tantly being written to the same parts of the flash medium.

For Windows Embedded devices, such as many of the kiosks found in public places (like Walmart, Kroger, etc.) where you may see a random BSOD from time to time, there is not a whole lot of configuration that can be done since they are pre-designed with configurati*** that are intended to never change. The only time changes take place is before the chip is written in most cases. Anything that needs to be saved, such as your payment to the grocery store, is done over the network to the store’s databases on a server.

然後是熟練工極客的回答：

The answer was always “no” because the number of writes required by an operating system would quickly wear them out.

They finally became cost effective for mainstream use. That “wear” is the only concern is a bit of an assumption. There have been systems running off solid state memory for a c***iderable period of time. Many folks who built car-puters booted off of CF cards (which were electrically compatible with PATA and trivial to install compared to PATA hard drives), and industrial computers have had **all, rugged flash based storage.

That said, there were not many opti*** for the average person. You could buy a pricy CF card and an adaptor for a laptop, or find a tiny, very pricy industrial disk on a module unit for a desktop. They were not very large compared to contemporary hard drives (modern IDE DOMs top out at 8GB or 16GB I think). I am pretty sure you could have gotten solid state system drives set up way before standard SSDs became common.

There have not really been any universal/magical improvements in wear leveling as far as I know. There have been incremental improvements while we have been moving away from pricy SLC to MLC, TLC, and even QLC along with **aller process sizes (all of which lower cost with some higher risk of wearing out). Flash has gotten a lot cheaper.

There were also a few alternatives that did not have wear issues. For example, running the entire system off a ROM (which is arguably solid state storage ) and battery backed RAM, which many early SSDs and portable devices like the Palm Pilot used. None of these are common today. Hard drives rocked compared to say, battery backed RAM (too expensive), early solid state devices (somewhat pricy), or peasants with flags (never caught on due to terrible data density). Even modern flash memory is a descendant of fast-erasing eeproms and eeproms have been used in electronic devices for storage of things like firmware for ages.

Hard drives simply were at a nice intersection of high volume (which is important), low cost, and relatively sufficient storage.

The reason you find eMMCs in modern, low end computers is the components are relatively cheap, large enough (for desktop operating systems) at that cost, and share commonality with mobile phone components, so they are produced in bulk with a standard interface. They also give great density of storage for their volume. C***idering many of these machines have a paltry 32GB or 64GB drive, on par with hard drives from the better part of a decade ago, they are a sensible option in this role.

We are finally reaching the point where you can store a reasonable amount of memory affordably and with reasonable speeds on eMMCs and flash, which is why people go for them.

有什麼要補充的解釋嗎？在評論中發出聲音。想從其他精通技術的Stack Exchange使用者那裡瞭解更多答案嗎？在這裡檢視完整的討論主題。

圖片來源：Martin Voltri（Flickr）