21–30 of 126 posts
>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?
I wonder would it be possible to use it somehow with Linux (in kernel space, not with fuse, because fuse has work slower because of necessary context switches from kernel to user space). I mean it is interesting can a wrapper kernel module be written for interfacing with Rust code, or there are some obstacles that would prevent from doing it efficiently.
>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?
Is the choice of SPECK a serious decision or is it some kinda of a political/satire/parody thing?
"Team Foundation Server" (Microsoft's version control server) is what goes through my mind... poor choice of naming...
So you have to add “fs” or “filesystem“ to your search queries, or not even that if the rest of the query gives sufficient context. Everyone makes name conflicts in independent domains to be a much bigger problem than they are in reality. There’s Amazon rainforest, Amazon the ecommerce website, and Amazon the cloud company. How often do you have any problem differentiating between them?
Though, they've started to refer to the source control protocol implementation as TFVC, since TFS supports git as well now. It does seem to have some conflicts, and even notes another file system called TFS themselves.
In this case, I'm pretty sure another name might be a better idea. Hell, TFS the version control system and the other file system are more well known than Firebird the database when Mozilla renamed their shiny new browser.
>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?
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.>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?
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.