Design Strategy

The SEF library is stateless. Nearly all requests result in one or more requests to the SEF driver. Those requests are submitted using the caller’s thread. The completion of SEF driver requests is handled by an internal, statically sized thread pool based on the number of CPUs. Therefore, completion routines should not block on resources that require another completion routine to execute as that would risk deadlock. An example of a bad design is an I/O completion blocking waiting for a different I/O request to complete first. The SEF library specifically will fail synchronous calls into the SEF library from a completion routine for this reason. Of course, waiting for a resource owned by another completion thread won’t cause deadlock, but it does reduce the number of threads available to process completions.

Writes to a SEF device complete before the final flash memory address has been assigned. A notification is sent if the final flash memory address is different than the preliminary address. However, no notification occurs when the preliminary flash memory address is the final flash memory address. It can be inferred by the super block closed notification. As a result, metadata that is tracking the allocated flash memory addresses is not final until the super block close notification is processed. In the case of a power failure, up-to-date metadata structures can be rebuilt from the user address data supplied when the data was written.