Rationale

Designing a genuinely failsafe storage system requires a complete understanding of the interactions of the system’s components. For example, under Microsoft’s TFAT the driver level must provide atomic operations to ensure that the TFAT system is reliable. In order to ensure that the driver level implementation is atomic, the driver itself must be able to handle operations atomically, and the physical device must also have the ability to update files atomically. The driver and the physical device work together, but they are separate components, each of which must have the ability to deal with file modifications atomically.

Hard disk drives have their own issues. For example, on an HDD there is an internal cache (perhaps 8MB or more) for which it is not generally possible to control the sequence of write operations. On some of the faster solid state devices, such as SD cards and Compact Flash cards, sectors are now written in parallel. This means that the second sector to be written could be committed before the first. Both these cases imply that the operations of any driver cannot be considered atomic.

Any file system claiming failsafety must define what it requires of the driver and physical device below it. The main questions are: 1) does it require atomic operation? 2) how much data can be written out of sequence while still maintaining the integrity of the file system? As an example, can 8MB of HDD cache be written in any order and interrupted at any time, while preserving the file system’s consistency?

HCC’s reliable SafeFAT system (with drivers for HDD, SD cards, etc.), together with its reliable SafeFTL, addresses these design issues and provides, from a single source, all that is required to create a reliable storage system, from the system API all the way down to control of the physical media.