Login
Need an account? Sign up.Forgot your password?
This section deals with technical enhancements made to the Reliance Nitro file system product
Q: What are some of the top features and enhancements in Reliance Nitro?
A: Reliance Nitro makes five significant architectural improvements over Reliance
1. Move to a tree-based architecture for allocation schemes and directory structure from a linear allocation scheme in Reliance
2. Extent-based file system compared to a block based file system
3. Introduction of Delta transaction points which speed up the process of conduction transaction points
4. Support for UTF-8 character format over a Microsoft UNICODE implementation on Reliance
5. Extensible metadata design allowing for OEM defined attributes, up to 3 billion attributes per file
Q: How easy it is to upgrade to Reliance Nitro from Reliance?
A: Please refer to Reliance Nitro Upgrade Advisory for detailed information
Q: How does Reliance Nitro’s tree-based architecture improve performance so dramatically?
A: The most common metadata architecture is linear allocation. In this method, the file system uses a linear array to store metadata information. This makes the file system simple and works fairly well for a system with a small number of files. The limitations of linear allocation start to show significant impact as the number of files in a system grows. Accessing large number of files through linear traversal of a folder takes a long time, leading to a serious degradation in performance.
Tree-based allocations are a faster way to organize and find files, based on grouping information into addressable chunks, and assigning keys that direct the system where to find them
Tree Depth 512 1024 2048
Level 1 15 31 63
Level 2 615 2,604 10,647
Level 3 25,215 218,736 1,799,343
Level 4 1,033,815 18,373,824 304,088,967
For 512 bytes block size:
* On a linear file system (like TFAT), nodes traversed to access file #25,215 = 25,215/8 = 3,151
* On a tree-based file system like Reliance Nitro, nodes traversed to access file #25,215 = 3
* For cases where there are more than 17 files on the device, a tree-based file system will perform better than a linear one (assumes a 512 byte sector).
Q: What are extent-based file systems? How do they come to block-based ones?
A: Block-based file systems allocate space in blocks which correspond directly to the block architecture provided by the underlying block device driver
Extent-based file systems allocate a set of blocks (called as extent) when writing to a particular file. An extent consists of a data pair: a starting location and the extent length.
Extent based file systems have 2 primary advantages
1. Sequential I/O is improved because files are allocated contiguously
2. Fragmentation is slower
Q: What are Delta Transactions?
A: To mitigate the performance penalty of a transaction point, Reliance Nitro introduces a special data structure known as the Delta-Block.
A: Delta-Block transaction (also referred to as Delta transaction) allows a transaction to occur by only writing a single metadata block that encompasses all the metadata changes since the last transaction. The Delta-Block contains all the updates to the already transacted state of the media. So in essence, the Delta-Block records the difference between committed state and the working state.
Q: How large of a volume can I support with Reliance Nitro? What is the max file size?
A: The following chart shows the maximum volume size for Reliance Nitro for various block sizes
Nitro Block Size Max Volume Size
512 bytes 2 TB
1k 4 TB
2k 8TB
4k 16 TB
8k 32TB
Maximum file size is equal to the total amount of free space in the volume.
Q: Does Reliance Nitro also support Dynamic Transaction Point technology?
A: Yes
Q: What is a transactional file system? What is a transaction point?
A: A transactional file system is one that is architected on the concepts of a database. Databases conduct events known as transactions. At determined intervals, all changes prior to the previous intervals are committed to disk. These intervals are called as transaction points.
A Transaction Point may be atomic or not. Reliance Transaction Points are atomic, but Win/CE TFAT transaction points are NOT atomic.
Q: What is Dynamic Transaction Point technology?
A: DTP is the ability of Reliance to control when and under what circumstances transaction points occur. It is dynamic in that it responds to system conditions and is not fixed to only a time or event. Datalight coined term to describe the way that Reliance allows developers to write their applications such that they are assured that critical data is committed to the disk (flushed from all caches and non-volatile storage media) at a precise moment.
The most important aspect of DTP is that it allows transaction modes to be changed while the device is running, without requiring recompiling or reformatting.
Q: Why is a transactional file system better than journaling?
A: Journaling file systems attempt to provide reliability by keeping track of changes in log or journal. If the system is interrupted a review of the journal is required upon restart to attempt to align requested changes with the data actually written on the media. This time consuming process slows mount times. A transactional file system records changes to the media in an atomic fashion: changes are either all completed or never happen at all. This provides an always consistent disk state and allows virtually instantaneous mount times.
Reliance also has the advantage of protecting both file metadata and user data from data corruption due to power loss, making it a more reliable option than journaling file systems
Q: What is the footprint of Reliance?
A: The memory footprint varies depending on the way Reliance is built and which components of Reliance are enabled. The code size will also vary depending on the target CPU. The best way for you to know the memory footprint is to contact Datalight sales and evaluate Reliance.
Q: Do Reliance & FlashFX Pro require a 32-bit processor/RTOS or can 16-bit work?
A: We do say in our Datasheets that our software can be ported to "any 32-bit RTOS", however it actually can be ported to work with 16-bit processors as well. Reliance and FlashFX do require that the toolset you use for building our code support 32-Bit types, and 32-bit math. This requirement applies even if you are porting to work with 16-bit processors.
Q: What do you mean by file system mount?
A: Mounting a file system consists of several tasks: accessing a raw storage device, reading the superblock and other file system metadata, and then preparing the file system for access to a volume. A part of this preparation is verifying that the file system is valid. An alternate term for a valid file system is a "clean" or "consistent" file system meaning that the metadata and the user data are consistent with each other. Full verification of a file system can take a long time, especially if the superblock indicates that the volume is "dirty" usually the result of an unexpected power loss.
Un-mounting of a file system involves flushing out to disk all in-memory state associated with the volume. Once all the in-memory data (data in RAM or other non-volatile memory) is written to the volume, the volume is said to be "clean." The last operation of un-mounting is to mark the superblock to indicate that a normal shutdown occurred.
Reliance Value Proposition
Q: How does Reliance enable fast boot times
A: Reliance has a unique transactional architecture where it maintains two file system metaroots (unlike most other file systems which just have one). One metaroot points a known good state of the disk while the other points to working state. When mounting a Reliance partition, the OS just has to verify which metaroot is pointing to the known good state and load that state. Because of this patented architecture, mounting a Reliance partition is much faster than other file systems.
Mount times significantly affect boot times, more so if the boot image is stored on the file system. Due to fast mount times, Reliance-based devices boot faster than similar devices with other file systems.
Q: How does Reliance guarantee 100% reliability against data corruption?
A: Reliance has a unique transactional architecture where it maintains two file system metaroots (unlike most other file systems which just have one). One metaroot points a known good state of the disk while the other points to working state. Reliance never overwrites live data; it always uses free space for disk operations between transaction points. As a result, one state of the disk (known good state) is always reliable, no matter when power failure occurs. Because of this patented design, Reliance guarantees 100% reliability against data corruption due software issues on power loss.
Note that Reliance does not protect against hardware failures.
Q: How many power cycle tests have you run on Reliance?
A: 10,000+. Our power cycle tests have been running for months without causing any data corruption.
Q: Can you run multiple transaction point methods simultaneously? What’s the value in doing that?
A: Yes. Customers can run a device in all 3 DTP modes simultaneously. This is helpful where device has multiple applications, each having different needs. For e.g. a handheld scanner has a scanning app and a logging app. The scanning app needs automatic transactions while the logging one needs timed.
Q: Does Reliance work on other media than resident flash?
A: Yes. Reliance is designed to be "media agnostic". It works with any device that can present a block device interface and not make assumptions about what file system is in use.
Q: Does Reliance work on SD/MMC, Disk-on-Chip, Hard Drives, Solid State Drives?
A: Yes
Q: Can a device use Reliance along with other file systems (like FAT)?
A: Yes. The embedded OS does need to provide support for FAT. Reliance itself does not provide FAT support
Q: Can I exchange data between a Reliance-formatted device and a PC?
A: Reliance comes with Reliance Windows Driver (RWD) that allows full exchangeability with Microsoft Windows 2000 and Windows XP operating system. Windows Vista support is expected in Q3 2008.
Exchangeability can also be enabled via the device OS, where the data between the device and the PC is transferred over a file-system agnostic protocol (MTP, for e.g.). This allows Reliance to be exchangeable with any desktop OS (Mac, Linux, etc)
Reliance Performance
Q: What is a "discard interface" and how does it enable faster writes?
A: Reliance tells FlashFX when it no longer needs data from areas of the FlashFX "disk" (for example, when a file is deleted). We call this "discarding" data. This makes FlashFX Pro more efficient in that data that is not in use does not need to be copied around.
The big performance difference this enables is that sustained write performance with Reliance will be much better than other file systems which do not have a discard interface. For e.g. the ext3 file system has no concept of discarding data, so after the entire disk has been written once, FlashFX thinks everything is precious. This makes it much less efficient when it is time to write.
Discard interface only matter when using resident flash and FFXP. It is of not much use on hard drives, DoC, SD, etc.
Q: What is the overhead of your "metaroots"?
A: Metaroots are one logical block in size. A new one is written for each transaction. The metaroots is what allows a new transaction state to be recognized and could be considered an extra write beyond what a conventional file system would perform.
Q: How many sectors are written during a transaction point?
A: This varies depending on how many blocks are marked as being modified in the internal buffers. This number depends on what has changed since the last transaction point. The minimum would probably be around 3 blocks. A reasonable average is around 5-7 blocks.
Q: How much performance overhead does a transaction point add?
A: That depends on the media, processor speed and amount of data being written.
Q: In the event of a power failure, do blocks that were written to the media between transaction points appear as used blocks to the file system, or will Reliance attempt to use them in future operations, and treat them as free blocks?
A: If the data is written to the file system between transaction points, and the power is lost (and there is no transaction point to commit the data that was written), these areas of the disk will be considered "free" by Reliance as well, and we will eventually write to that area of the disk.
Q: If there is an area in which data is not fully finished writing is the area reused when creating a new file or is the area not reused until after it's been reformatted?
A: It is reused, because it is not part of the committed state on the disk - and isn't considered valid data to the file system.
Q: How do I boot using Reliance?
A: Reliance provides a utility called as Datalight Loader which has Reliance Reader. Datalight loader can be used with your bootloader to load boot images stored on Reliance partitions.
Q: What does the product cost? Is it available without royalties?
A: Datalight offers a variety of pricing models to fit within our customers’ preferred purchasing methods. Royalty-free, per unit, and annual lease options are available. Please contact your Datalight representative for a specific price quote for your project.
Q: Can I use Reliance as root file system on Linux?
No. In our first release, Reliance has to be used with a native Linux file system. This does not introduce any additional overhead and is very easy to implement and maintain.
See our whitepaper on this topic: Bootstrapping Linux from NAND Flash
Q: Is Datalight ISO 9001:2000 certified?
A: Datalight products undergo rigorous engineering unit testing and independent quality assurance in accordance to our documented software development life cycle process and procedures. While we are confident that our methodology and results reflect best practices of our industry, Datalight has decided to invest in further enhancement of our products rather than the infrastructure required to obtain and maintain ISO certification. If ISO 9001:2000 certification became a requirement for a critical mass of customers in the future, Datalight is confident that certification would be achieved.
Q: What is the maximum path length supported by Reliance and Nitro?
A: 1024
Q: How does Reliance overwrite method work?
Reliance does not overwrite existing data blocks allowing the previous state of the file system to remain intact on the storage media during the current write operation.
For example, when we overwrite only 3 bytes in 1 block, does Reliance assign new 1 block?, Or does Reliance assign (new) 3 byte only?
A: Reliance will reallocate the whole block.
Q: Reliance metadata structure:
Is a placement of the following metadata a logical placement? Or is a placement of the following metadata a physical placement? If it is a physical placement, it always exists at a fixed location from a head.
=======================
| Master Block
=======================
| Meta Root1
=======================
| Meta Root2
=======================
| IMap1
=======================
| IMAP2
=======================
| Root Dir1
=======================
| Root Dir 2
=======================
| Free block
=======================
| &grt;snip<
=======================
| Free block
=======================
A: The Master block holds the locations of the Meta Roots. This is done so that the metaroots don't have to be located in a static location and can be moved around the disk as needed.
Q: Is it better to transact on all writes to the media, or on file close?
A: If there is a need for an entire file to be check summed and written to disk to be considered valid data, you would want to your Reliance transactions set to transact on file close. If your system does not care about the contents of the entire file, but want each write request as sent to Reliance to be committed, then you could consider transacting on writes.
A word of caution:
Reliance transactions occur on a volume wide basis, and not on a file by file basis. What this means is that if you have five files open in the file system, and close one of them, if your transaction flags are set to include file close, then ALL of the data written to all five files (to the point where the close for the first file was called) will be committed to disk during that transaction point.
This fact needs to be taken into consideration as it is important to know that if there are files open, a close of one of them will affect all others if you are set to transaction on file close.
To better take advantage of manual transaction points, then an application could do something like:
1. Disable transactions
2. Open all of the files needed for writing
3. Write information to the files needing updating
4. Close all of the files, then do a manual transaction point to commit the changes to the disk
This would ensure that either all of the files got updated, or none of the files got updated - and you would have a know state for the data in your file system.
In a situation where a customer does not have the ability to take direct control of the transaction points in a system, because they cannot modify their application, we would suggest using the automatic transaction points instead, and set them up to best suit their needs.
Q: If a transaction point is set up for Write, does a transaction occur after every file write?
A: A transaction on Write causes a transaction point after a specific write request to Reliance is complete. If your application sent a request to Reliance telling the file system to write 2KB, a transaction would occur after 2KB. If your application told the file system to write 1 MB, a transaction would occur after the 1 MB had been written to the media.
Q: How do transaction points work on a Write? If the application requests that Reliance write 2KB, and the next time 64KB, when does the transaction point occur?
A: This activity is handled almost exclusively inside the port code. The only exception to this is the transaction on Disk Full - this is the only automatic transaction performed by the Reliance core.
How the ports typically handle the other modes (other than Disk Full) is to make all the core calls necessary to complete the operation and then if the mode flags match the operation it will perform a transaction.
If the application requests that Reliance write 2KB - we transact after 2KB. If the application passes down a 64KB chunk to write - we transact after 64KB. However, it does get a bit more complicated than that depending on what layer exists between the application code and Reliance. For example, if stream operations are being used (fopen, fwrite), then there will not always be a 1:1 relationship between an application write and a write to the file system. In any case, we perform a transaction point on write only after writing all the data for that write call.
The Challenge In the world of programmable logic controllers (PLC) and remote I/O systems, speed and responsiveness are the ultimate measures of performance.
Bothell, WA – October 9, 2009 – Datalight announced today that Power Measurement Ltd.
Bothell, WA, – November 17, 2009 – Datalight announced today that it has added De2 to the company’s worldwide reseller network.