Comment 103 for bug 317781

@Theo

   Question:

Something I don't understand from your earlier explanation is why does 1.b hit the disk, but 1.c does not? Or even more: why does 2.e hit before 2.c? At least with example 1 it's in order, but with example 2 it's not. I can understand data loss if the system crashes exactly in between 1.b and 1.c, but if it's after 1.c, why would someone loose anything? (I'm guessing the journal is written, but not the data?)

Someone talked about hidden transactions. Shouldn't there be an assumption that for any one particular file, any operations on it must hit the disk exactly in the order they were made?

   Suggestion:

It seems to me that the correct fix to the problem is sort of the reverse to the patch you mentioned: don't allow a file to hit the _journal_ (for example truncating it in 1.b) until any outstanding requests for that file have hit the disk, (no matter when they were made, before or after the one for the journal). If necessary withhold placing the truncate or delete in the journal, until the blocks have hit the disk (rather than forcing the blocks to the disk whenever the journal is written which is what your patch is doing).

I think, and if I'm wrong please tell me, that doing this will prevent data loss (at worst you'll have the old version), and also keep performance good (since your never force a write), without having to resort to heuristics like your patch.