| |||||||||||||
Where the the correctness go?Where the the correctness go?Posted Mar 15, 2009 21:24 UTC (Sun) by bojan (subscriber, #14302)In reply to: Where the the correctness go? by endecotp Parent article: Ts'o: Delayed allocation and the zero-length file problem
> fsync() does NOT guarantee durability - it can be a no-op.
Hence, you need to have various #ifs and ifs() to figure out what works on your platform. See Mac OS X. fsync is just an example here. The point is that you must use _something_ to commit. Without that, POSIX does not guarantee anything beyond currently running processes seeing the same picture.
(Log in to post comments)
Where the the correctness go? Posted Mar 16, 2009 4:49 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
ven doing s fsync doesn't mean that you won't have this corruption. the two writes could go to the disk drive's buffer and it could write the metadata out before it writes the data blocks. if it looses power in between these two steps you have the same problem
Where the the correctness go? Posted Mar 16, 2009 13:28 UTC (Mon) by jamesh (guest, #1159) [Link]
Of course, if the drive supports barriers in its command queueing implementation it should be possible to prevent it reordering those writes.
That is likely to restrict reorderings that won't break correctness guarantees though.
|
|||||||||||||