Ocfs2 users - Apr 2008 - slow ocfs

Hello,
I have one cluster with drbd primary/primary and OCFS2.
If I do:
from server 1:
-cd /mnt/ocfs2 (this is a directory shared with ocfs2)
-cp file1 test (file1 it's 50Gb)

from server2:
-cd /mnt/ocfs2
-ls -l
At this point it take 30-50second and display ls result (cp don't are
already terminated)

It's normal this "delay"? thank you
ps:I have two NIC Gigabit dedicated for this service

-- 
A presto, Aimar Marco
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://oss.oracle.com/pipermail/ocfs2-users/attachments/20080421/fac057f9/attachment.html

Hello,
> I have one cluster with drbd primary/primary and OCFS2.
> If I do:
> from server 1:
> -cd /mnt/ocfs2 (this is a directory shared with ocfs2)
> -cp file1 test (file1 it's 50Gb)
> 
> from server2:
> -cd /mnt/ocfs2
> -ls -l
> At this point it take 30-50second and display ls result (cp don't are
> already terminated)
> 
> It's normal this "delay"? thank you
> ps:I have two NIC Gigabit dedicated for this service
  Those two files are the only ones in /mnt/ocfs2? I guess what takes
time is to take the read lock for directory /mnt/ocfs2 or the file
/mnt/ocfs2/test. This can take quite some while. Does the delay vanish
if you do 'sync' on server 1, wait for it to finish and then do 'ls
-l'
on server 2?

								Honza

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
>>