With the technological refinements and economies of scale in solid-state drives have come a parallel set of refinements and price decreases for Compact Flash cards. With Compact Flash devices large enough to accommodate full Linux distributions and quick enough in some cases to rival hard disk drive operation, they comprise good candidates for upgrading thin clients to standalone systems or replacing 4200 RPM and 1.8" hard drives in ultraportable laptops and other small low power devices.
Various small Linux distributions such as Tiny Core are designed to load from flash and then run in RAM. In normal operation they rarely write to the storage medium. This article addresses the use of a Compact Flash card as a hard disk replacement running a conventional disk-based operating system.
A long standing concern with flash devices is wearing out the NAND flash memory. In a CF card, NAND flash is accessed via a controller that provides an IDE interface for standardised access, wear-levelling to distribute write wear over all available blocks, error checking and correction (ECC) to compensate for spontaneous bit failures of the medium, and bad block management (BBM) to identify and retire worn out blocks. NOR flash is excluded from in this discussion as it is no longer cost competitive and rarely used in Compact Flash.
The debate continues about how quickly flash devices wear out. A concrete empirical test[1] with an entry level Corsair SSD using MLC NAND Chips was carried out in October 2011. This test exhausted the write capacity of this SSD by repeatedly copying files to the drive formatted as a single NTFS partition. The result calculated that writing 20GiB/day to a 40GB device delivers a 33 year lifespan. The measured data rate was for file data only and did not include the filesystem meta-data written to directory and allocation blocks. Restated: filling more than half the free space of the drive daily with standard OS calls, it will last more than 33 years. Or equivalently: completely filling the device daily, it will last more than 17 years.
Assuming Compact Flash cards are outfitted with the same NAND as SSD (true for recent vintage and high capacity CF cards), then it is reasonable to project similar performance. Wikipedia sources indicate differences between premium NAND flash capable of 10,000 writes/block and other NAND capable of only 3,000 writes/block. If the tested SSD was manufactured with the "good stuff", we can infer the "bad stuff" should last at least 5 years when the device capacity is written daily.
What life span can be expected for a Compact Flash card hosting a Linux root filesystem? In the following assessment, it is assumed Compact Flash controllers use dynamic levelling as commonly implemented in cheaper controllers. Dynamic levelling only rotates wear among the rewritten ("available") blocks. A controller using static levelling rotates wear over ALL blocks of the device. Static levelling is more common in expensive controllers typical to solid-state drives.
Consider a severe use case: a 2GB CF card contains a cramped Linux installation of Crunchbang 10 with only 300MB of available space. A casual estimate of the daily OS overhead is 20-30MB/day. At idle, operating 24/7 the flash can be expected to wear out in 50 to 170 years. (Note: lifespan statements will be stated in a "bad stuff" to "good stuff" range). Writing 1GB daily to the same space gives a 1.5 to 5 year life. (If static levelling were implemented, the same 1GB would be written over the entire 2GB not 300MB and the lifespan for would be 10 to 33 years.)
Increasing the size of the card and thus the free space increases the lifespan. If this same CF card capacity is doubled from 2GB to 4GB, the free space increases more than seven times to 2.3GB, as does the lifespan. Under these conditions, writing 1GB daily would wear out the flash in 12 to 39 years.
Anecdotal references about "wearing out" Compact Flash cards abound at photography forums and other websites on the Internet. While the CF cards certainly failed, the issue seems to be the general reliability of the devices rather than reaching the flash write capacity of the device.
For example, if a photographer completely fills a card and wipes all photos off every day, 5 days a week it should take 3.5 to 11 years (projected from Corsair SSD empirical testing) or 3 to 10 years (calculated based on 3,000 to 10,000 writes, writing/erasing exercises four write cycles per block - guesstimated for "write amplification" and large linear blocks) to reach the design capacity. When a photographer reports a name brand (10,000 write cycle) device fails well under that period, equating the failure to reaching the design limits or "wearing it out" is not credible.
The reviews of Compact Flash cards at New Egg and Amazon contain plenty of entries where brand new devices are returned for failing immediately or after a few weeks. This indicates significant issues in manufacturing quality and reliability. In a casual observation of these same New Egg and Amazon reviews, the rate of complaints (1+2 star/egg reviews) for CF cards appear higher than both SSD and HDD devices. The likely interpretation: CF devices are less reliable. A regular backup plan appears to be more important using a Compact Flash card as a primary drive than a hard disk.
There are recommendations and howtos online about tuning flash devices for write minimisation when used as Linux root filesystems. However with adequate available space, there appears to be plenty of "life" to utilise a Compact Flash card like a normal hard disk drive. Note that Google made ext4 the official filesystem for Android flash filesystems as of version 2.3. The wear-levelling, ECC, and BBM on typical flash devices is adequate for the general write requirements of their Linux-based OS and typical users.
Compact Flash device reliability has not been demonstrated to be a function of over-rated write capacities. In fact, the opposite is true. The actual capabilities of USB NAND flash devices exceed rated capacities by a factor of 10 or more according to a paper[2] presented at the 8th USENIX Conference on File and Storage Technologies in 2010. As such, reliability issues should be addressed with effective data redundancy strategies not adjustments for write minimisation.
For a Compact Flash replacing a hard drive in a single user desktop system, the following write minimisation strategies commonly employed with flash devices are unnecessary: reducing swap use (kernel parameter vm.swappiness), eliminating swap space on the device, setting mount options to circumvent access time modification (nodiratime and noatime), disabling the filesystem journal, and using a RAM filesystem for /tmp and /var filesystems.
The read and write performance of a Compact Flash card is different than a hard disk. While the average read and write data rates of a hard drive are roughly the same, the write throughput for Compact Flash is slower, often half the read throughput (individual devices vary). Hard drives incur delays: the seek time waiting to position the read/write head and the latency waiting for data to rotate into position. Compact Flash access is nearly instantaneous, there is no effective seek time or latency. As the slower rate, the average write data rate is the generally of most interest.
Average write data rates for Compact Flash are difficult to discern. Rates vary widely, generally in proportion to cost. Current Compact Flash data rates are not as fast as Solid State Drives, and only the fastest rival the write speeds of hard disk drives. Standards for specifying the data rate associated with a Compact Flash device are ambiguous. Stated data speeds like 133x are read speeds compared to CD-ROM speeds. A rate of 133x is 133 times as fast as a CD-ROM, or 133 * 150 KB/s = 19950 KB/s or 20MB/s read rate. These may be average rates or maximum rates. Data rates stated by manufacturers in MB/s can be read or write speeds, and burst rates or average rates. Marketing claims about speed are generally insufficient to determine average data write performance.
The users/editors of the Linux ThinkPad Wiki (thinkwiki.org) have used and evaluated Compact Flash cards as a replacement for 4200rpm disk drives in ThinkPad ultraportable laptops[3]. Their experiences, analysis, and recommendations may be useful for identifying and selecting CF devices for use as a primary drive/root device in thin clients.
NAND flash memory used in Compact Flash cards is organized in 4K blocks of data called pages. When reading or writing the device, data can only be handled in complete pages. For best performance, the filesystem should use a 4K block size and be aligned at 4K block boundaries matching the page size and alignment of the device.
The performance penalty for a block size less than 4K is severe. For a filesystem with a 1K block size, writing a single block entails reading a page, inserting the 1K of data, and writing back the altered page. Writing four contiguous 1K blocks entails four page reads, four page modifications, and four page writes. Writing the same data using a 4K block size entails NO page reads, NO page modifications, and one page write. While NAND memory controllers mitigate some of the read penalty by buffering pages in RAM, they do not eliminate the problem.
An unaligned filesystem also incurs a significant penalty, even using an optimal block size. Writing an unaligned 4K block requires reading two pages, inserting parts of the data into the appropriate pages, and writing back two pages. Again, the memory controller buffers pages to reduce but not eliminate the problem. Note that Microsoft operating systems through Windows XP were standardized to start the first partition of a drive at sector 63, inherently misaligned for flash devices. Many older partitioning tools will apply this geometry by default.
In addition to pages, NAND flash is also organized by erase blocks. The erase block is the minimum unit of contiguous memory that can be erased in preparation for writing. While the read/programming page size is consistent across NAND from different manufacturers, the erase block size is not and varies from 128KiB to 1MiB (2MiB in some recent SSD devices). Online documentation can be cited both advocating and disputing partition alignment to a multiple of the erase block. Erase block alignment is NOT mentioned in the support FAQ at major USB Flash/SSD manufacturers Corsair or Crucial, so any performance impact would appear to be minimal.
The default partition alignment in recent Linux and other OS distributions is 1MiB. This is a multiple of the read/write page size and encompasses multiples of most NAND erase block sizes save 2MiB. Most recent distributions therefore create partitions that are page aligned, and even erase block aligned in most cases.
The recommended filesystem for Compact Flash cards is the ext4 filesystem because it provides faster performance than ext2 or ext3 filesystems[4]. The ext4 filesystem also uses a 4KB block size by default providing an optimal block size for flash devices.
Altering the disk scheduler is often recommended for flash drives. There are four types of disk schedulers, two that improve filesystem performance on a spinning disk: anticipatory and cfq (completely fair queueing); and two for other media: noop and deadline. Both noop and deadline appear in recommendations for SSD schedulers. The Wikipedia noop entry specifically cites noop for use with flash memory.
Theoretically, this change should improve performance but testing at Velobit[5] on solid-state drives shows little to no difference, save that 1) anticipatory scheduling has a significant penalty on writes, and 2) one test case actually showed a penalty for noop scheduling compared to cfq. The anticipatory scheduler has generally been unused except with Apache web server installations and was removed entirely in kernel 2.6.33; the cfq scheduler is generally the default. The tests conclude changing from cfq to noop is likely to have no effect, and possibly a negative one. Changing this parameter is not recommended unless performance testing is completed to verify improvement.
To change the scheduler, the noop scheduler also known as the elevator can be set with kernel parameter "elevator=noop". Edit /etc/default/grub with your favourite text editor as superuser. Find the GRUB_CMDLINE_LINUX_DEFAULT (Debian/Ubuntu) or GRUB_CMDLINE_LINUX (Fedora) entry, and add elevator=noop to the end of the entry with a space between elevator and the last word. Then run update-grub.
A full distribution can be installed to a Compact Flash card of adequate size and recent technology. It should be formatted with an ext4 filesystem for best performance. Partitions should be page aligned, as is generally the default with recent distributions. Otherwise a "standard installation" is acceptable as recent cards are robust enough to provide normal use without special accommodations for write minimisation or performance tweaking.
This article was contributed by Craig Oakes