| |||||||||||||
Atomicity vs durabilityAtomicity vs durabilityPosted Mar 15, 2009 22:05 UTC (Sun) by dcoutts (guest, #5387)In reply to: Atomicity vs durability by bojan Parent article: Ts'o: Delayed allocation and the zero-length file problem
Remember, we do not care if the data is on disk or not, just that if it does make it to disk that it preserves the atomic property we were after. All that needs to happen is for the rename not to be reordered in front of the write. That hardly restricts performance.
As for a new API, yes, that'd be great. There are doubtless other situations where it would be useful to be able to constrain write re-ordering. For example for writes within a single file if we're implementing a persistent tree structure where the ordering is important to provide atomicity in the face of system failure.
Having a nice new API does not mean that the obvious cases that app writers have been using for ages are wrong. We should just insert the obvious write barriers in those cases.
(Log in to post comments)
Atomicity vs durability Posted Mar 16, 2009 4:52 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
remember that the drive has it's own buffer (that usually isn't battery backed), and it will tell the OS that the data is written when it's in the buffer, not when it is on the disk. it then can re-order the writes to the disk.
so everything that you are screaming that the OS should guarantee can be broken by the hardware after the OS has done it's best.
you can buy/configure your hardware to not behave this way, but it costs a bunch (either in money or in performance). similarly you can configure your filesystem to give you added protection, at a significant added cost in performance.
Atomicity vs durability Posted Mar 16, 2009 11:00 UTC (Mon) by forthy (guest, #1525) [Link] Any reasonable hard disk (SATA, SCSI) has write barriers which allow file system implementers to actually implement atomicy.
|
|||||||||||||