Ts'o: Delayed allocation and the zero-length file problem
Posted Mar 20, 2009 14:52 UTC (Fri) by anton
In reply to: Ts'o: Delayed allocation and the zero-length file problem
Parent article: Ts'o: Delayed allocation and the zero-length file problem
To provide a completely unsurprising behavior,
i.e. provide expected inter-process POSIX semantics between pre-crash
and post-crash processes, you would need to infer a write barrier
between every IO operation by a process.
You have the right idea about the proper behaviour, but there is more
freedom in implementing it: You can commit a batch of operations at
the same time (e.g., after the 60s flush interval), and you need only
a few barriers for each batch: essentially one barrier between writing
everything but the commit block and writing the commit block, and
another barrier between writing the commit block and writing the
free-blocks information for the blocks that were freed by the commit
(and if you delay the freeing long enough, you can combine the latter
barrier with the former barrier of the next cycle).
This can be done relatively easily on a copy-on-write file system.
For an update-in-place file system, you probably need more barriers or
write more stuff in the journal (including data that's written to
to post comments)