Kirill Kuvaldin wrote:
>  Asynchronous journaling filesystem can be several times faster than a
>  traditional synchronous FFS.
>...
> * When a journaled filesystem reboots, if there are any journal entries
>  that were not marked as completed, the system must *replay* the entries
>  to bring the metadata structures up-to-date. Replaying the journal
>  prevents partial updates because each journal entry is a complete,

It seems to me that a useful high-level picture to provide would be the
relationship of ffs+journal not to ffs+sync (which is a comparison that
hardly needs to be drawn) but to ffs+softdep, in terms of the sets of
adverse events that can be recovered from, and the differences in time
required in normal operation and for recovery (here I mean the theoretical
differences, as the practical ones can be obtained later through
benchmarking).  That might be review for readers who live and breathe
filesystems, but it might be helpful for others in setting the stage.

> * API Documentation:
>   - it may be helpful for the developers to understand what the
>     journaling code does and how to use it.
> * Benchmarks:
>   - to compare the filesystem performance with different mount options:
>     with journal, with soft updates, without them.

Given world enough and time, I wouldn't want those optional. :)

-Chap