User: Password:
|
|
Subscribe / Log in / New account

POSIX v. reality: A position on O_PONIES

POSIX v. reality: A position on O_PONIES

Posted Sep 9, 2009 20:21 UTC (Wed) by kjp (subscriber, #39639)
Parent article: POSIX v. reality: A position on O_PONIES

The article was great other than the extremely fast and loose comment about 3.6.30 and writeback. From the linked article:

"Ted Ts'o has mitigated that problem somewhat, though, by adding in the same safeguards he put into ext4. In some situations (such as when a new file is renamed on top of an existing file), data will be forced out ahead of metadata."

Please clarify or contradict that before you give us poor app developers any more heart trouble... thanks.


(Log in to post comments)

POSIX v. reality: A position on O_PONIES

Posted Sep 9, 2009 21:08 UTC (Wed) by vaurora (guest, #38407) [Link]

My understanding is that the patches you are talking about only decrease the likelihood of the rename() data loss problem outside of ext3 with data=ordered mode. E.g.:

commit e7c8f5079ed9ec9e6eb1abe3defc5fb4ebfdf1cb
Author: Theodore Ts'o <tytso@mit.edu>
Date: Fri Apr 3 01:34:49 2009 -0400

ext3: Add replace-on-rename hueristics for data=writeback mode

In data=writeback mode, start an asynchronous flush when renaming a
file on top of an already-existing file. This lowers the probability
of data loss in the case of applications that attempt to replace a
file via using rename().

---

If you aren't sure, I recommend using ext3 with the explicit data=ordered option until you've had the opportunity to sit down and understand the data=writeback and/or ext4 semantics.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds