Messages in this thread |  | | | Date | Mon, 30 Mar 2009 09:13:14 +0200 | | From | "Andreas T.Auer" <> | | Subject | Re: Linux 2.6.29 |
| |
On 30.03.2009 02:39 Theodore Tso wrote: > All I can do is apologize to all other filesystem developers profusely > for ext3's data=ordered semantics; at this point, I very much regret > that we made data=ordered the default for ext3. But the application > writers vastly outnumber us, and realistically we're not going to be > able to easily roll back eight years of application writers being > trained that fsync() is not necessary, and actually is detrimental for > ext3. > > It seems you still didn't get the point. ext3 data=ordered is not the problem. The problem is that the average developer doesn't expect the fs to _re-order_ stuff. This is how most common fs did work long before ext3 has been introduced. They just know that there is a caching and they might lose recent data, but they expect the fs on disk to be a snapshot of the fs in memory at some time before the crash (except when crashing while writing). But the re-ordering brings it to the state that never has been in memory. data=ordered is just reflecting this thinking. With data=writeback as the default the users would have lost data and would have simply chosen a different fs instead of twisting the params. Or the distros would have made data=ordered the default to prevent beeing blamed for the data loss.
And still I don't know any reason, why it makes sense to write the metadata to non-existing data immediately instead of delaying that, too.
|  |