An interesting link

Posted Mar 13, 2009 10:41 UTC (Fri) by bojan (subscriber, #14302)
In reply to: An interesting link by qg6te2
Parent article: ext4 and data loss

> A simple "write data to disk" operation would have unnecessary complexity, as the slides show (a collection #ifdefs and run-time ifs). This is insane. The operating system (and hence by extension, the underlying filesystem) is supposed to abstract things away, not make things harder.

Unfortunately, that's the status of POSIX right now. And the complexity can be put into a library for everyone to share.

> A sane filesystem should have the previous version of a file available intact, no matter when the crash occurred. To put it another way, why replicate the "safe save" functionality in each app when it can be done once in the filesystem ?

Because the reality is that right now POSIX doesn't demand it, so your app is bound to bump into a file system here and there that requires exactly that. An app written safely will work with both types of file system semantics. The opposite is not true.

An interesting link

Posted Mar 15, 2009 13:53 UTC (Sun) by kleptog (subscriber, #1183) [Link] (1 responses)

ISTM that the choice for the application writer is straightforward:

1. I care that my application works correctly in the face of crashes on Linux on the default filesystem, in which case the above fixes will do it.

2. I care that my application works correctly in the face of crashes on any POSIX compliant OS, in which case you need to fix the app.

Unfortunately I come across a lot of code where the writer didn't even consider the problem, leaving bogus state even if you just kill the application at the wrong moment. I sincerely hope this brouhaha will at least cause more people to pay attention to the issue.

An interesting link

Posted Mar 15, 2009 18:08 UTC (Sun) by skybrian (guest, #365) [Link]

Agreed that carefully written, standards-compliant apps that go the extra mile to avoid data loss regardless of operating system will have a portability advantage over most. But unless there are lots of users out there running on filesystems with weaker semantics than ext3, the advantage isn't that big.

Also, what the most carefully written apps do isn't particularly relevant to what the filesystem should do. The choice for filesystem writers is:

a) implement just the bare standards, and most people won't use your filesystem because their apps lose data, even if it's faster.

b) implement nicer semantics so that people will actually prefer your filesystem over others. Decreased data loss after a system crash, even for poorly written apps, is such a feature.

It's the same tradeoff that exists for people who write web browsers. When the standards are too weak to achieve compatibility with most apps, you have to go beyond them. You need both good performance and good compatibility.

Without this patch, ext4 would not be competitive with ext3.