On Thu, Jun 2, 2011 at 5:48 PM, Jeff Mahoney
data=writeback means that the journal will not stall on large writes when the journal must be flushed to the general file system or an fsync() is called. This will perform the best for most write loads but can introduce corruption at the end of files if the system crashes if the file is extended (metadata) before the file data itself is written out (data).
I don't recall it being an issue with ext3, but XFS in the 2003 timeframe had a major issue if a system crashed while a config file update was pending. Userspace (KDE in particular back then) would do something like open() truncate_config_file() write_new_data() // fail to call fsync() close() Then xfs would journal the truncate command, and the new post write file size, but the data itself would sit in cache (apparently for an extended time). Then when the system crash occurred, you would get the infamous file full of nulls. They resolved that years ago, but ever since then, I've been wary of data=writeback functionality. I want the data on disk prior to all the metadata starts flying around. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org