Ocfs2 users - Mar 2006 - Oracle control file on OCFS2 without datavolume, nointr

We had someone from Oracle support move one of the database control files on 
an OCFS2 volume that's not mounted with datavolume,nointr (he moved it 
to /opt/oracle).  At that time I didn't realize the problem.

We'll move the control file to a volume that's mounted with
datavolume,nointr
options.

The question is: how bad is it?

We are experiencing some serious problems, precisely, the OCFS2 volumes
aren't
accessible all of a sudden (after 3-4 days of functioning perfectly).  
"ls /opt/oracle" would not do anything, just sit.

A lot of ragcmain processes are accumulating and the load is increasing.

If we shutdown node2, it all goes back to normal on node1.

OCFS2 1.1.8 from SLES9 kernel 2.6.5-7.252  (I have just written to SUSE 
support for a kernel with OCFS2 1.2).

We're not sure if the control file and these non-access problems are
related.

This is a silly question, but /opt/oracle sounds like local disk.   
How could you move a control file from shared disk to local disk and  
still have both nodes able to access it?  If you copied it to /opt/ 
oracle on both nodes, then you will likely have the two control files  
out of sync.  I'm not sure about the datavolume,nointr mount options  
specifically, but I think all that the "datavolume" mount option does
is provide data_direct access for i/o operations.  Before that was  
around, you used to have to use an O_DIRECT=y flag when using system  
commands like rm,cp,tar,etc.  The datavolume mount option just sort  
of incorporates that if I'm understanding it correctly.  I don't  
think putting the file on a volume that doesn't have the datavolume  
option would have anything to do with not being able to access OCFS2  
volumes, but I would think it might hit you performance wise.

Adam



On Mar 24, 2006, at 8:05 AM, Silviu Marin-Caea wrote:
> We had someone from Oracle support move one of the database control  
> files on
> an OCFS2 volume that's not mounted with datavolume,nointr (he moved it
> to /opt/oracle).  At that time I didn't realize the problem.
>
> We'll move the control file to a volume that's mounted with  
> datavolume,nointr
> options.
>
> The question is: how bad is it?
>
> We are experiencing some serious problems, precisely, the OCFS2  
> volumes aren't
> accessible all of a sudden (after 3-4 days of functioning perfectly).
> "ls /opt/oracle" would not do anything, just sit.
>
> A lot of ragcmain processes are accumulating and the load is  
> increasing.
>
> If we shutdown node2, it all goes back to normal on node1.
>
> OCFS2 1.1.8 from SLES9 kernel 2.6.5-7.252  (I have just written to  
> SUSE
> support for a kernel with OCFS2 1.2).
>
> We're not sure if the control file and these non-access problems  
> are related.
>
>
> _______________________________________________
> Ocfs2-users mailing list
> Ocfs2-users at oss.oracle.com
> http://oss.oracle.com/mailman/listinfo/ocfs2-users