The history and future of Linux filesystems
Publicerad 2010-07-02
Filesystems have always been a very important concept in the world of Linux. One of the first decisions a new user is faced with is how to partition the hard drive, and which filesystem to use. For a very long time the Second Extended File System (ext2) was the de facto standard for most Linux installations, but when the Third Extended Filesystem (ext3) was merged to the mainline kernel in November 2001 this started to change.
The ext3 filesystem, which is now the dominant filesystem, is built on top of ext2. It adds a couple of features to its predecessor; the most noteworthy being journaling. A journaling filesystem records all changes to a journal before actually committing them to disk, thus becoming more crash-resistant. Even though ext3 is the default filesystem in most major Linux distributions it has some major competitors, including JFS, ReiserFS and XFS.
While ext3 is still the most common filesystem, it has been superseded by the Fourth Extended Filesystem (ext4). On 11 October 2008 the ext4 filesystem was marked as stable in the Linux kernel, but has only recently started to gain momentum. It is now presented as an alternative during installation of most major Linux distributions, although ext3 is still the default choice in many cases. Ext4 originally started as a set of extensions to ext3, but was later forked to a separate project to avoid affecting the stability of ext3.
It is possible to upgrade an existing ext3 (or ext2) filesystem to ext4, but doing so has some side effects. Ext4 adds new features which are not compatible with ext3, so if those features are used it will not be possible to easily convert back to ext3. However, since ext4 has a number of advantages over ext3, there should normally be little need to revert the change.
To further complicate the choice of filesystem another major filesystem called Btrfs, short for B-tree File System, is in development. Btrfs implements an impressive array of features such as snapshots, compression and online defragmentation and is thought to replace both ext3 and ext4 as the standard Linux filesystem. As of June 2010 it is, however, not ready for production use.
What about embedded systems?
All of these filesystems are primarily designed for normal hard drives, and have limited uses in the embedded world. The reason for this is that most embedded systems still use Memory Technology Devices (MTD), such as raw NAND or NOR flash chips, for storage. An MTD is different from a hard drive in several ways. The writable unit of a hard drive is the sector, which is small (typically 512 or 1024 bytes) and can be written directly. An MTD, on the other hand, has its data grouped in larger erase blocks (typically 128KiB), which need to be erased before writing. This means that the filesystems above cannot be used on MTD devices directly, since they do not make use of the erase operation.
Designing a filesystem for an MTD is complicated even more by the fact that these erase blocks only support a limited number of erases before becoming unusable. The filesystem must keep track of which blocks are bad and also distribute data writes evenly across the entire MTD, a technique called wear leveling, to increase the life length of the device.
There are currently two dominant filesystems in use for MTD's: JFFS2 and YAFFS2. YAFFS2 is often considered the superior alternative but it has one major drawback; it is currently not included in the mainline kernel sources, and is not expected to ever be. JFFS2 also has support for a wider range of devices.
LogFS is a new filesystem for MTD's which is thought to replace JFFS2. It was included in the recent 2.6.34 kernel release, but is still considered experimental. The main focus of the LogFS project is to improve the mount times and lower RAM usage compared to JFFS2. LogFS also works on regular block devices, such as hard drives.
Another project aiming to replace JFFS2 is a project called UBIFS. UBIFS is different from other MTD filesystems in that it doesn't run directly on top of the MTD subsystem. Instead, it uses an additional layer called Unsorted Block Images (UBI) which aims to simplify the handling of MTD's by making them look and behave more like a normal block device. It is not, however, trying to look exactly like a block device. UBIFS is included in the Linux kernel from version 2.6.27.
Note that MMC devices, SD cards and similar are normal block devices and should be handled as a hard drive, but they do suffer from the same reliability problem that MTD's suffer from. After a number of write cycles, they can become unreliable and it is therefore often considered a good practice to choose a filesystem with a low write intensity. However, this problem is very dependent on how the devices are constructed and how they handle wear leveling internally, and hence it is widely debated if it really is a problem.
Claes Gustafsson, Embedded Systems Consultant, Altran Technologies Sweden AB
Further reading:
http://en.wikipedia.org/wiki/Ext2
http://en.wikipedia.org/wiki/Ext3
http://en.wikipedia.org/wiki/Ext4
http://en.wikipedia.org/wiki/Btrfs
http://www.ibm.com/developerworks/linux/library/l-ext4/
http://linux-mtd.infradead.org/~dwmw2/jffs2.pdf
http://linux-mtd.infradead.org/doc/ubifs.html
http://logfs.org/logfs/
http://www.yaffs.net/yaffs-2-specification-and-development-notes
http://www.storagesearch.com/ssdmyths-endurance.html
Simulate By Open Source Tools
Publicerad 2009-10-12
Open Source, tools and solutions, are nowadays a given part of software development. Every day we hear about Linux digging new ground. GCC, the GNU compiler, supports more and more platforms and Open Source code gets into more and more products.
The same happens within the hardware market, though more silently. Last spring, I saw one or two articles about the OpenCores site that has been along for some time. Even so, I’ve heard little of it in my everyday work.
In this article I will look at the GNU HDL Simulator, GHDL. This is an open source simulator based on the GCC compiler. Using the compiler, it compiles VHDL code into an executable program. Running the program exercises the code. By built-in add-on code, you can get the waveforms that later is analyzed by any waveform viewer supporting the formats used. In my case, GTKWave is the viewer of choice.
I became curious on GHDL as it is an Open Source tool, providing me with an alternative to the tools that I’ve learned to know from my daily work. GHDL provided me a simulator that does not have the limitations of the free-of-charge versions of simulators from out silicon providers. The drawback is that you do not get the macro block simulation models of commonly used devices. Hence, I have to write these models myself. When I saw some hardware companies referring to the simulator on their home pages, I started to think about how I can benefit from it professionally.
An Open Source simulator you say…? Maybe you feel a little skeptical about the idea. What about provider support? What about quality assurance? In plain language, can I trust the tool to be well tested? If I find an issue, who will fix it?
Having a company providing you the simulator, if you are important enough as a customer, they will fix the problems for you. In other cases, you might just need to adapt. Looking at the quality issues, sometimes you may gain insights to the quality processes. Often, you tend to trust a tool since everybody else is using it.
The same goes with the Open Source tools… Since the Open Source tools are often used by a large number of developers, the limitations tend to be well known and the tool itself heavily tested. With this in mind, it is important to choose a tool that is supported by a large community. If the community is small, the tool may not be mature enough yet. Another important factor to me; is the project alive and how long has it been alive?
In the case of GHDL, the first downloads are from 2002 and the last release is done in July 2008. According to its home page, it implements VHDL according to IEEE 1076-1987 (VHDL 87) or IEEE 1076-1993 (VHLD 93). Event VHDL 00 and VHDL 02 are on the roadmap. It is said to successfully compile and simulate both a DLX processor and the LEON 1 Sparc processor.
My experience is: Open Source tools have a hard time gaining acceptance in my field of work. The arguments are many, often there are underlying quality issues as well as legal issues. For example, the GPL license is sometimes described as the lawyer’s nightmare. Over time the Open Source solutions have proven their quality, due to the masses of developers contributing, and started to gain ground within the software world. Today, the interest in Open Source formally explodes. Just look at the attention around LINUX and Android.
The commonly used simulator today often comes with high license costs. This is for sure an issue for small companies or the project working with dedicated licenses and tight resources. In these cases, I see simulators such as GHDL as an extra tool to speed up your project group. Having limited number of licenses means that developers will be pending on one another and the group becomes less effective. In this case, a free tool may be an answer to bring the team up to pace, still using the well known and commonly accepted tools for final verification. This way the project will be able to show assured quality with acceptable tools and at the same time waste no time waiting for licenses.
The setup would be that the team members use the free simulator for their every day development. Once the test bench of a certain component runs successfully and all test cases are covered, principally the work of the component is done. At that time, the developer uses proprietary accepted tools for a final checkup. (The choice of tool is of course depended on you customer.) This might be one way for a project team to cut cost and still be able to assure great quality even if anyone should doubt the quality of free simulators. However, over time, I would like to think that tools like GHDL will become accepted and supported just as GCC.
Mattias Almljung,
Embedded Systems Consultant, Altran Technologies Sweden AB
F-RAM, Back to Basics
Publicerad 2009-06-26
F-RAM or Fe-RAM stands for Ferroelectric Random Access Memory. When one hears that term, one may tend to think about the memory of the early computers. Memories that were made up by a grid of wires, where each intersection point has a little ferrite bead to store the bit. F-RAMs are however a little different story, but there are similarities. It is a non-volatile memory that stores data in an internal crystal structure. The centre atom of the crystal will become oriented to the applied current. Recently, one of the leading developers of F-RAMs, Rampton, announced that new parts are being released.
F-RAM is one of many types of non-volatile memory available today. In spite of not being well known among today’s developers, it can be used as a drop-in replacement of EEPROM or Flash memory modules having the same size. When using a Flash memory, one has to choose between NOR- or NAND-flash. This is basically choosing between slow write- /fast read access or the opposite. Also, the Flash memory often requires a complex state machine for performing operations such as erase- or write (where the flash must be polled for completion). Here the F-RAM has the advantage providing faster and simpler write cycles. You don’t need to care about any special erase cycles, just write your new data to the memory address. Looking at the data sheet of F-RAM devices from one of the leading providers, the write cycle time is about 100 ns and the access time about 60 ns.
Let’s have a short look at the F-RAM’s power performance. Again looking at the data sheets for available devices, at normal operation it consumes about 7 mA and it can be as low as 5 ?A in sleep mode. Another example shows an operating current of about 15 mA. Some articles claim that the operating current can be as low as 150 ?A, at 100 kHz. The data retention time is normally 10 years and the number of write cycles is between 1010-1016 times. Comparing this to the EEPROM and Flash technology, the number of write cycles is doubled. Some even say virtually unlimited.
Looking at these properties, the F-RAM is well suited for a system that requires a fast access non-volatile storage system. I’m thinking about distributed data acquisition systems, or industrial systems where using a flash memory either limits the speed or there is a risk of losing data due to the write latency. Other system uses log-buffers to buffer debug data, error-logs for later failure analysis or storing the state before being shut down. Since a Flash memory sometimes is too limited in these applications, today a capacitor–backup or battery-backup RAM is used.
The process of manufacturing F-RAM is similar to that of DRAM. In fact, they can be manufactured using almost the same process. In the DRAM case, the memory is implemented using a capacitor together with a signal transistor. A capacitor and transistor pair is called 1C-1T cell. The DRAM capacitor stores data by charging the capacitor. In short, exchange the dielectric from the DRAM capacitor to a ferroelectric material and you get F-RAM. One common ferroelectric dielectric is lead zicronate titanate, short PZT. Instead of storing data by the lack or presence of electrical change, the F-RAM stores data using positive and negative polarization.
Even though it has been around since the 1980’s, the F-RAM has not made a huge breakthrough. Comparing it to today’s Flash memories, the cost of the flash is about the half of the F-RAM. The Flash memory is well established, accepted and serves its purpose. However, Flash does not provide the same advantages such as the high write speed combined with the simple interfacing. There are many applications where an F-RAM would serve better then the flash (or backed-up RAM). In some cases the F-RAM can provide a non-volatile memory where the Flash would be too expensive or complicated (sometimes due to the need of Flash file system in order to extend the memory’s lifetime). Therefore, I think the F-RAM is an interesting alternative to other non-volatile technologies that may prove cost effective in some applications.
Mattias Almljung, Altran Technologies Sweden
Sources (2009-04-19):
http://www.embeddedtechjournal.com/articles_2009/20090407_flash.htm
http://embeddedtechjournal.com/news_2009/03/20090331_10.htm
http://www.eecg.toronto.edu/~ali/ferro/tutorial.html
http://en.wikipedia.org/wiki/Ferroelectric_RAM
MB85R1001, FUJITSU MICROELECTRONICS DATA SHEET
FM28V100, Ramton Data Sheet
Programmable Logic, a Diverging World
Publicerad 2009-05-28
Looking at the recent years of the FPGA business, we have seen that FPGAs are growing bigger and with more and more macro blocks. For each new generation, the silicon process has taken the steps to even more compact silicon. Recently FPGAs manufactured with 40 nm silicon process was announced and the race is still ongoing. The competitors focus their marketing on high-end devices aimed at high-speed serial communication.
Of course, FPGA families targeting smaller embedded applications are provided by the same manufacturer, following the same basic patterns. Large macro blocks and more dense deigns. Some of these are also being equipped with more communication support. These are often seen together with the addition of soft processors.
The soft processor is of course not a bad idea, and almost every FPGA producer does provide a soft processor solution. There are even companies that do business only by providing soft processors and System On Chip (SOC) solutions. Personally I think the SOC concept is very appealing, as it provides the advantages of both software design and programmable logic on the same chip. From an engineering perspective, it is neat to be able to provide a solution based on an optimized balance between software and hardware (as many algorithms successfully are boosted within the hardware domain).
On the other hand, during the race for more dense devices with high speed serial IOs, a new trend has started focusing on small battery powered devices. These are FPGAs that have very good power efficiency and small form factors. This trend has even brought new FPGA manufacturers to the market. These simple FPGAs are going in the totally opposite direction, competing with the smallest amount of power consumption and being cheap. These tend to not focus on any macro blocks and are often FLASH based, removing the need of extra circuits on the board.
Looking at Scandinavia, the market has been controlled by a few silicon producers. Personally I have seen little focus on the new energy optimized devices that are becoming available. These devices are interesting, not only because they are focused on battery applications. As they are cheap (the smallest ones can be bought for a few dollars), they open new markets where FPGAs are considered too expensive, too complex... In time, as these devices become more available, the classical arguments are failing as many designs can benefit from the new small FPGAs. Can it be that an expensive DSP can be replaced by a microcontroller and an FPGA implementing complex protocol and accelerating computations? – At least in some applications. On other cases, a microcontroller may be completely replaced by a small FPGA due to a simple task that the FPGA could do better. Although the focus has been battery held application, I like to think of the less obvious applications that can benefit from this trend.
So what does it mean for us in our daily life? Nothing if we choose not to care and proceed in the direction we have been walking for the last years. Or if we choose to stop and look around for a moment, we will see that there are many new interesting opportunities. I feel that if we don’t do this, we will not be able to produce as good and cost effective deigns as we should. My aim with this article is to call attention to some ongoing trends in the world of programmable logic.
In this column the world of FPGAs, DSPs, ASICs, Processors and Processes, will be further explored. We will look into subjects related to technical development and the embedded market. I hope you will enjoy the journey into the hidden lands of technology and embedded systems. Stay tuned.
Mattias Almljung, Altran Technologies Sweden
Sources:
Serial Soirée
Altera Tempts with Tons of Transceivers,
Kevin Morris, FPGA and Structured ASIC Journal
February 10, 2009
http://www.siliconbluetech.com/
http://www.actel.com/
http://www.altera.com/
http://www.xilinx.com/
|
