>The system will never enter an inconsistent state (unless there is hardware failure), meaning that unexpected power-off won't ever damage the system.
What is the difference here between a hardware failure and a unexpected power failure?
What is the difference here between a hardware failure and a unexpected power failure?
Sadly, a lot of hardware has much more complicated behavior than that. A lot of RAID cards in particular will lie about what was actually written, so in a power-off scenario later writes might have made it while earlier ones didn't, writes can be incomplete, etc. I don't mean this as a knock against TFS. It's more of a suggestion that the fault model be expanded to include at least a few more possibilities.
TFS provides following guarantees:
- Unless data corruption happens, the disk should never be
an inconsistent state \footnote{TFS achieves this without using
journaling or a transactional model.}. Poweroff and the alike
should not affect the system such that it enters an invalid or
inconsistent state.
Provided that following premises hold:
- Any sector (assumed to be a power of two of at least
\minimumsectorsize bytes) can be read and written atomically,
i.e. it is never partially written, and interrupting the write
will never render the disk in a state in which it not already
is written or retaining the old data.
Data corruption can break these guarantees or premises, and TFS
encompasses certain measures against such corruption, but they are
strictly speaking heuristic, like any error detection and correction
method, as the damage could be across all the disks.