TargetXFS™ Embedded Unix-like File System
Overview
TargetXFS is a widely-used, robust, high-performance, powerfail-safe, UNIX-like, flash-friendly embedded file system with a configurable RAM footprint that performs well with all volume sizes, from kilobytes to terabytes.
Features
Standards compliant. Provides a full POSIX and Standard C compliant API including links, file access permissions, long file names, atime/ctime/mtime timestamps, and numerous extensions for embedded systems use.
High performance. Careful metadata caching ensures file operations are fast. This and optional support for bypassing the user data cache ensures data transfers are fast. Streaming read and write throughput is approximately the same as the underlying I/O speed of the backing media.
Supports concurrent use of multiple volumes. Volumes can be installed at start up, or added, mounted, unmounted, and deleted during operation.
Reentrant. Designed for multitasking environments. Per-volume access semaphores allow independent concurrent access to multiple volumes by multiple tasks.
Guaranteed file system integrity across unexpected shutdowns. Only data written after the most recent synchronization can be lost. Closed files, directory structures, files open for reading are never at risk.
Fast powerfail recovery. Automatically performed at mount. Only the working next-cluster list needs to be checked. FAT file systems must also verify every volume directory.
Flash friendly. Supports background reclamation of ‘dirty’ flash sectors when used with Blunk’s flash translation layers, by polling vclean() from a low priority task. Supports TRIM (which deletes unused FTL mappings) for efficient flash garbage collection.
Supports raw flash memory via Blunk’s flash translation layers for NAND and NOR flash. Uses page size of underlying flash for optimal performance. Tight coupling ensures powerfail safety despite caching in the FTL.
Supports managed flash memory via Blunk’s smart media managers for CompactFlash, eMMC devices, SD cards, and USB flash drives. Supports hard drives as well.
Single file atomic updates using rename(). Prepare new version using a temporary name then rename it to the name of the old file. This atomically deletes the old file and gives its name to the new file. If a file with the temporary name exists at startup, the update was interrupted. The application can delete the new file and repeat the update process.
Multiple file atomic updates between volume synchronizations. If an option is set, all writes (both user data and metadata) go to new sectors, leaving the saved volume image untouched. If powerloss occurs before the next synchonization, the volume reboots to its previous state exactly. If the synchronization succeeds, the volume is atomically updated to the latest changes.
Applications use fflush(), fsync(), sync(), or vsync() to perform a synchronization and vstat() to learn how much data can be written before the next required synchronization (in order to free dirty clusters).
Configurable footprint. The metadata caches and the user data cache have configurable sizes. File system features (asynchronous I/O, directory caching, UTF support) can be included or excluded to control RAM footprint and code size. The XFS_BASIC_MODE option enforces minimum API set and code size.
Configuration #1 #2 #3 FTBLS_TCACHE_ENTS 2 clusters 8 clusters 10 clusters NSPC_TCACHE_ENTS 2 clusters 8 clusters 10 clusters NCL_MAX_CACHED 1 page 8 pages 10 pages INC_DIRTY_CL_BM FALSE FALSE TRUE Cluster Size 2048 2048 2048 File Data Cache Size 2KB 4KB 4KB # Cached Directories 0 5 5 XFS_BASIC_MODE TRUE FALSE FALSE Code Footprint 50KB 78KB 79KB RAM Footprint 21KB 76KB 125KB Table shows code and RAM size for example configurations. Full details in manual.
Optional per-task Current Working Directories. The CWD is specified using two 32-bit values that are stored by the application. TargetXFS writes them in chdir() and reads them when resolving relative paths. If they are stored in a task-specific way, each task has its own CWD.
Optional directory cache for extremely fast path resolution. A configurable number of directories can be cached. A heuristic dynamically determines which directories are cached for optimum benefit.
Optional asynchronous I/O. Uses transparent RAM buffering for guaranteed constant minimum throughput despite variances in backing store throughput, such as due to intermittent FTL garbage collection.
Implements and enforces the POSIX “owner”, “group”, “others” access groups, allowing applications to restrict some accesses to privileged tasks. TargetXFS calls application function FsGetId() to get the running task’s user and group ID.
Supports Unicode file/directory names, for internationalization.
Optional volume-level encryption. If used, all data on backing media is encrypted.
Provides file IDs: persistent associations between 32-bit numbers and files/directories. Valid even for closed files. File IDs are assigned at file creation and can be used to obtain the file name and path, allowing fixed-size database entries to reference file names and paths of arbitrary length.
Binary image tool creates preformatted volume image files for pre-production programming of flash devices using automated programmers from Data I/O, BP Microsystems, etc.
PC shell tool for loading and mounting binary images of target volumes. The uploaded image can be examined using shell commands (‘ls’, ‘chdir’, etc.) and files can be extracted to the Windows file system.
Shares common API library and CWD implementation with TargetFAT (Windows compatible), TargetRFS (RAM), and TargetZFS (compressed read-only images), interworking seamlessly with these file systems.
Extensive scripted testing of error handling, multitasking reentrancy, memory allocation failure, powerfail recovery, and regression tests ensure reliability. Tested on big and little-endian CPUs. Automated continuous 24⁄7 powerfail recovery testing on physical hardware.
Used in consumer electronics and industrial products worldwide.
Includes sample applications that exercise the file system’s Standard C and POSIX APIs, and optional command line shell (“cd”, “ls”, “mkdir”, “pwd”, etc,) that may be extended with user commands.
For efficient DMA use, all buffers passed to the driver are aligned on CPU cache line boundaries.
Developed using TargetOS-Lite™, Blunk’s free RTOS. Easily ported to other RTOSes or used in polled mode, without a kernel.
Source code is 100% Standard C and has been tested using PC-lint and multiple Standard C compilers, including GCC.
Royalty-free license. Includes complete source code, sample applications, sample drivers, user’s manual, and one year of technical support. Electronic delivery via customer-specific web portal.
Bundled in liteFS-NOR™ and liteFS-NAND™.
