On 6/11/13 12:41 PM, Stefan Ring wrote:
>>> Every database software will do the flushing correctly.
>>
>>
>> Stefan, you are making my point because every database will do the right
>> thing, it won't rely on ext3's magic every 5 second fsync :)
>
> Ok, let us agree on this one then ;)
>
> There is still kind of a dichotomy regarding the entire issue. While
> in many cases, noone will complain about a few seconds of lost data,
> it is an entirely different beast if you lose an entire file that may
> have been added to and maintained over month/years, just because the
> system went down at an unfortunate moment. In my opinion, having a
> consistent, yet possibly somewhat outdated file, is much more
> important than having the most recent view in an inconsistent/broken
> state.
But the application needs to watch out for that too. Appending to, or
overwriting part of a file, should never result in whole-file loss on a crash,
although it may lead to data inconsistency. If you truncate the file and rewrite,
there is more risk.
If you want atomic updates so that you get either-old-or-new-version,
that can be accomplished.
>From the LWN article we keep linking to ;)
Similarly, if you encounter a system failure (such as power loss, ENOSPC or an I/O error) while overwriting a file, it can result in the loss of existing data. To avoid this problem, it is common practice (and advisable) to write the updated data to a temporary file, ensure that it is safe on stable storage, then rename the temporary file to the original file name (thus replacing the contents). This ensures an atomic update of the file, so that other readers get one copy of the data or another. The following steps are required to perform this type of update:
create a new temp file (on the same file system!)
write data to the temp file
fsync() the temp file
rename the temp file to the appropriate name
fsync() the containing directory
-Eric
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
