[Ocfs2-users] slow ocfs

[Sunil Mushran]

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 <Sunil.Mushran at oracle.com> 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
>>