File system classes

Since it is common to run many file systems under the BlackBerry 10 OS, they have been designed as a family of drivers and shared libraries to maximize code reuse. This means the cost of adding an additional file system is typically smaller than might otherwise be expected. When an initial file system is running, the incremental memory cost for additional file systems is minimal, since only the code to implement the new file system protocol would be added to the system.

The various file systems are layered as follows:

As shown in this diagram, the file systems and io-blk are implemented as shared libraries (essentially passive blocks of code resident in memory), while the devb-* driver is the executing process that calls into the libraries. In operation, the driver process starts first and invokes the block-level shared library ( io-blk.so ). The file system shared libraries may be dynamically loaded later to provide file system interfaces and services.

A file system shared library implements a file system protocol or personality on a set of blocks on a physical disk device. The file systems aren't built into the OS kernel; rather, they're dynamic entities that can be loaded or unloaded on demand.

For example, a removable storage device (PCCard flash card, floppy disk, removable cartridge disk, and so on.) may be inserted at any time, with any of a number of file systems stored on it. While the hardware the driver interfaces to is unlikely to change dynamically, the on-disk data structure could vary widely. The dynamic nature of the file system copes with this very naturally.

Most of the file system shared libraries ride on top of the Block I/O module. The io-blk.so module also acts as a resource manager and exports a block-special file for each physical device. For a system with two hard disks the default files would be:

/dev/hd0

First hard disk.

/dev/hd1

Second hard disk.

These files represent each raw disk and may be accessed using all the normal POSIX file primitives ( open() , close() , read() , write() , lseek() , and so on.). Although the io-blk module can support a 64-bit offset on seek, the driver interface is 32-bit, allowing access to 2-terabyte disks.

The io-blk module supports an internal RAM-disk device that can be created via a command-line option (blk ramdisk=size). Since this RAM disk is internal to the io-blk module, performance is significantly better than that of a dedicated RAM-disk driver.

By incorporating the RAM-disk device directly at the io-blk layer, the device's data memory parallels the main cache, so I/O operations to this device can bypass the buffer cache, eliminating a memory copy yet still retaining coherency. Contrast this with a driver-level implementation where transparently presenting the RAM as a block device involves additional memory copies and duplicates data in the buffer cache. Inter-DLL callouts are also eliminated. In addition, there are benefits in terms of installation footprint for systems that have a hard disk and also want a RAM disk: only the single driver is needed.

The BlackBerry 10 OS complies with the de facto industry standard for partitioning a disk. This allows a number of file systems to share the same physical disk. Each partition is also represented as a block-special file, with the partition type appended to the filename of the disk it's located on. In the above two-disk example, if the first disk had a QNX 4 partition and a DOS partition, while the second disk had only a QNX 4 partition, then the default files would be:

/dev/hd0

First hard disk

/dev/hd0t6

DOS partition on first hard disk

/dev/hd0t79

QNX 4 partition on first hard disk

/dev/hd1

Second hard disk

/dev/hd1t79

QNX 4 partition on second hard disk

The following list shows some typical assigned partition types:

The BlackBerry 10 OS complies with the de facto industry standard for partitioning a disk. Read operations are synchronous; write operations are usually asynchronous. When an application writes to a file, the data enters the cache, and the file system manager immediately replies to the client process to indicate that the data has been written. The data is then written to the disk.

Critical file system blocks such as bitmap blocks, directory blocks, extent blocks, and inode blocks are written immediately and synchronously to disk.

Applications can modify write behavior on a file-by-file basis. For example, a database application can cause all writes for a given file to be performed synchronously. This would ensure a high level of file integrity in the face of potential hardware or power problems that might otherwise leave a database in an inconsistent state.

POSIX defines the set of services a file system must provide. However, not all file systems are capable of delivering all those services.

^a The internal representation for file names is UTF-8, which uses a variable number of bytes per character. Many on-disk formats instead use UCS2, which is a fixed number (2 bytes). Thus a length limit in characters may be 1, 2, or 3 times that number in bytes, as we convert from on-disk to OS representation. The lengths for the Power-Safe file system are in bytes.