4 ms·

>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 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?

nbevans 9y ago
Hardware failures could imply "flipped bits" (depending on failure mode) whereas loss of power should just mean "truncated bits".
deleted 9y ago
[deleted]
jsiepkes 9y ago
And what about a kernel panic?
eximius 9y ago
Yea, I'd like a little more detail on this point too.
zitterbewegung 9y ago
Unexpected shutdown would just use the features of a Journaling file system to recover the data. A hardware failure would be a Raid controller failure or malfunction or a hard drive / SSD failure .
jstimpfle 9y ago
The section "2. Hardware Assumptions" in the Sqlite docs here has some interesting related stuff: https://www.sqlite.org/atomiccommit.html https://www.sqlite.org/atomiccommit.html
gpm 9y ago
I think the spec answers your question here 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.
notacoward 9y ago
A power-off is a simple fault, with fairly well-defined effects. It's actually one of the easiest cases for a data-storage system to deal with. "Hardware failure" includes all manner of crazy Byzantine faults, many of which are literally impossible to deal with. What this is saying is that TFS's model of the underlying hardware is that it will either execute all writes correctly or stop executing any. 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.

nbevans 9y ago

Hardware failures could imply "flipped bits" (depending on failure mode) whereas loss of power should just mean "truncated bits".

deleted 9y ago

[deleted]

jsiepkes 9y ago

And what about a kernel panic?

eximius 9y ago

Yea, I'd like a little more detail on this point too.

zitterbewegung 9y ago

Unexpected shutdown would just use the features of a Journaling file system to recover the data. A hardware failure would be a Raid controller failure or malfunction or a hard drive / SSD failure .

jstimpfle 9y ago

The section "2. Hardware Assumptions" in the Sqlite docs here has some interesting related stuff: https://www.sqlite.org/atomiccommit.html https://www.sqlite.org/atomiccommit.html

gpm 9y ago

I think the spec answers your question here 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.

notacoward 9y ago

A power-off is a simple fault, with fairly well-defined effects. It's actually one of the easiest cases for a data-storage system to deal with. "Hardware failure" includes all manner of crazy Byzantine faults, many of which are literally impossible to deal with. What this is saying is that TFS's model of the underlying hardware is that it will either execute all writes correctly or stop executing any. 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.