The link I posted explains the risk. In short, in ordered mode, the metadata changes are committed after the data is flushed to disk. In writeback, metadata changes can (not will) be committed without the data being flushed to disk.
Say you have a file of size 100 bytes. And you write extend it by 50 bytes. And say your server crashes right after the metadata change is committed to disk. Here metadata refers to the new file size (and the new mtime). At some point the volume will be recovered. If in cluster mode, it will be recovered by another node. If not, then it will be recovered on the next mount. Either case, the recovery process will set the new filesize and mtime to what was committed to the journal. The only question remaining is the validity of the data from the 101st byte to the 150th byte. If the data was flushed to disk before the metadata was committed, then the data will be good. If not, it will be bad. Ordered ensures the data will be good as it flushes it before committing the transaction. With writeback, there are no such guarantees. Sunil mike wrote: > Yes, but you said in another email data=writeback can disable this > blocking behavior, I am wondering what the side effects are of > data=writeback? > > I am new to OCFS2, so I have not been using data=ordered long, I need > low latency/fast response, and it sounds like writeback can help, but > does it risk corruption or something then? > > > On 4/21/08, Sunil Mushran <[EMAIL PROTECTED]> wrote: > >> data=ordered has been the default for quite sometime. >> >> You can read more about it here: >> http://oss.oracle.com/projects/ocfs2/dist/documentation/ocfs2-new-features.html >> _______________________________________________ Ocfs2-users mailing list [email protected] http://oss.oracle.com/mailman/listinfo/ocfs2-users
