Last week was one of pride and excitement for the JBLopen’s development team as we released our latest product, the TREEspan File System (TSFS). After the official announcement and presentation, we feel the need to introduce the newcomer in a more personal way, such as we see it from the inside. Above all, we would like to answer this fundamental question: what are the motivations behind TSFS, or, to put it bluntly, why on earth devoting so much time and energy to designing (and coding, and testing, and re-testing) a new embedded file system?
Well, as much as engineers strive for rational answers, we must admit that this ambitious quest initially stems from our passion for embedded design and storage technologies. Without this initial impulse, we could not possibly have reached the level of commitment and care that it takes to create such a complex piece of software.
That being said, TSFS development orientations have been largely driven by an intimate understanding of embedded designer’s needs, and fed by the development team’s own experience with storage-related embedded design. Before we share with you our thoughts on how TSFS may fill your needs, let’s first recall what TSFS is about.
TSFS is a low-footprint, RTOS-agnostic, embedded transactional file system with native flash support, offering concurrent access management, snapshots and high-speed random accesses.
That was for the encyclopedic definition. Let’s now take some time to break this down into something you can relate to.
Low-footprint. When we say low-foot print, we mean it. With a minimum RAM requirement of 4 KiB, TSFS is certainly on the light side. But that’s not the most important. TSFS RAM requirement is constant. That is, the amount of needed memory does not increase with the size of the underlying media. Nor does it with the number of files and directories. This means that huge media, containing terabytes of data, can be attached to even the most modest processors.
RTOS-agnostic. TSFS is written in pure ANSI C (C99) and has been designed to run on any combination of RTOS/platform. What’s more, TSFS comes complete with your choice of RTOS and platform integration so that you can start working on your application code from day one.
Transactional. If not handled carefully, power losses and other untimely interruptions can lead to deleterious data corruptions. TSFS transactional nature prevents such catastrophic failures by providing strict atomicity guarantees on update operations. Unlike typical journaled file systems, TSFS protects both file system metadata and user data. From the application designer standpoint, this means that power fail-safe applications can be built effortlessly, as TSFS does all the heavy lifting internally.
Flash support. Flash memories (e.g. NOR flash) are complex and intricate devices. First and foremost, flash memories do not allow data to be overwritten without the containing block being first erased. Knowing that a block can only be erased a limited number of times before it becomes irreversibly unusable, handling this restriction is no trivial task. To cope with these peculiarities, most file systems need the adjunction of an additional adaptation layer. But not TSFS. Through its native flash support, TSFS keeps overall complexity, RAM usage and cost to a minimum, independent of the underlying storage technology.
Concurrent access management. Concurrent access management. How do you read from a file that is being updated? Simple question, not so simple answer. For instance, what happens if a partially updated piece of data is read? Sure, all write operations could be suspended for the time it takes for the application-level read operation to complete. Although it certainly guarantees data coherency, this approach would be detrimental to the overall application performances. In an attempt to mitigate performance loss, one could try to stall write operations on a more granular basis. Again, this is far from ideal as such an approach typically introduces complex synchronization issues and/or coupling between otherwise isolated reader and writer modules. Through snapshots and transactions support, TSFS provides a read/write transaction abstraction that naturally enables complex concurrent access scenarios.
Snapshot support. TSFS provides the application designer with the ability to save the current state of the whole file system in a space-efficient way. The maximum number of snapshots is only limited by the available media space. Saved states can be later read or reverted to, allowing for robust backup/recovery schemes with a minimum amount of application-specific code.
High-speed random accesses. As more and more modern applications rely on small, random read/write accesses, TSFS has been designed with great care for random access performances. To give you a taste of TSFS capabilities, let’s consider a typical example. With 4 KiB random accesses uniformly distributed on a 4 GiB file, average read/write throughput is guaranteed to remain higher than 80% of the physical media throughput on all supported storage technologies (provided that performances are not CPU-bound). From the application designer’s standpoint, this means less time lost troubleshooting complex, access pattern-related performance issues, and more time focusing on application-specific design challenges.
As you can see, TSFS is packed with powerful features all aimed at a single goal: making the application designer’s work easier. Of course, there is a lot more to TSFS than the above-mentioned, and we will assuredly spend more time delving into subtle technical considerations in future articles. Still, we hope that this overview gave you a sense of TSFS uniqueness and that we were able to share with you at least a little bit of our excitement.
To learn more about TREEspan File System visit: www.jblopen.com/tsfs/