Atomicity vs durability
Posted Mar 14, 2009 13:42 UTC (Sat) by man_ls
In reply to: Server farms are not the target
Parent article: Ts'o: Delayed allocation and the zero-length file problem
"Atomic without a crash" is not good enough; "atomic" means that a transaction is committed or not, no matter at what point we are -- even after a crash. I think that durability is not needed here:
In database systems, durability is the ACID property which guarantees that transactions that have committed will survive permanently.
In ext3 it does not matter (too much) if the transaction stays committed, but it cannot be left in the middle of an operation (crashes notwithstanding).
Let's see an example. Say we have the following sequence:
atomic change -> commit -> 5 secs -> flushed to disk
The change might be a rename operation. If the system crashes during those 5 secs, the transaction might not survive the crash -- the filesystem would appear as before the atomic change, and thus ext3 is not durable. But the transaction can only appear as not started or as finished, and not in any state in between; thus ext3 is atomic. I guess that is what fsync() is about: durability of the requested change.
But the problem Ts'o is talking about is different: the transaction has been committed but only part of it may appear on disk -- a zero-length version of the transaction to be precise. So the system is not atomic. It can be made durable with fsync() but that is not really the point.
I may very well have confused everything up, and would be grateful for any clarification. My coffee intake is not what it used to be these days.
to post comments)