Filesystems and crash resistance [LWN.net]

Filesystems and crash resistance

Posted May 22, 2019 19:30 UTC (Wed) by ikm (guest, #493)
Parent article: Filesystems and crash resistance

I'm surprised that crash resistance is linked to persistence here. I would argue that in an event of a crash what is much more important is consistency - I don't mind if I lose the latest changes to the file I'm editing, but I would be very upset if a file is left filled with all zeroes afterwards. If I lose just the latest changes, I can just redo the last several seconds of the work, but if the file is left in an inconsistent state, or worse it, wiped clean, *all* the work is lost. I've seen this happen many times with xfs, and never with ext4, for example. To me, those two filesystems seem to provide entirely different guarantees in practice, even though in theory maybe none of those are supposed to be guaranteed in the first place, as no fsync() may be called at all.

to post comments

Filesystems and crash resistance

Posted May 23, 2019 6:05 UTC (Thu) by amir73il (subscriber, #66165) [Link]

You have several correct observations:
1. People keep mixing persistence/durability with crash consistency
2. In the absence of fsync(), ext4/xfs exhibit entirely different *behavior* in practice
3. In the absence of fsync(), ext4/xfs provide no guaranties about consistency of file data
ext4 has some heuristics in place to reduce the number of support calls from people that did not issue fsync() as documented,
but those are NOT to be confused with guaranties.

Filesystems and crash resistance

Posted May 23, 2019 8:23 UTC (Thu) by nilsmeyer (guest, #122604) [Link] (2 responses)

> If I lose just the latest changes, I can just redo the last several seconds of the work,

And how would you store those latest changes? You would need some durable storage for that.

> To me, those two filesystems seem to provide entirely different guarantees in practice, even though in theory maybe none of those are supposed to be guaranteed in the first place, as no fsync() may be called at all.

That's likely the root of the problem. Also with ext4 it depends on mount/mkfs options, data=ordered will behave differently from data=writeback or data=journal. That makes it very difficult for application developers to handle, especially if they also target platforms other than Linux.

Filesystems and crash resistance

Posted May 23, 2019 11:28 UTC (Thu) by rweikusat2 (subscriber, #117920) [Link] (1 responses)

The usually sensible strategy for "handling" this is "don't". People who are (for more or less good reasons) paranoid about data loss in case of a sudden, unplanned shutdown can mount their filesystems synchronously, albeit this still doesn't guarantee anything because writes take a finite amount of time and if power drops at the wrong time, something is going to break (I've had damaged file systems mounted with this option).

Or "listen to Microsoft" (voices of reason alone are usually disregarded) and use a suitable storage engine aka DBMS.

Filesystems and crash resistance

Posted May 31, 2019 0:58 UTC (Fri) by Wol (subscriber, #4433) [Link]

Use a dbms? And watch the dbms get corrupted when the power failure corrupts its writes.

There's nothing magic about a dbms, it's just another application. And it's just as prone to being corrupted as any other. One only has to look at the hoops Postgres has to jump through to TRY and ensure integrity.

I've always thought write barriers make sense. If I can guarantee that all writes before the barrier land before any ones after the barrier get written, I can reason about that and - more importantly - make sure that either (a) my logs are consistent, or (b) my data is consistent. More importantly, I can then recover my data successfully to pre- or post- write condition. I may not have a choice which, but at least the data is consistent.

Cheers,
Wol