Ocfs users - Jun 2004 - RHE L3 -- OCFS 1.0.9-12 and 1.0.12

Running database in ASYNC mode in RHEL 3 has a potential risk of redo logs
failure due to some short io's.
A note from 
http://oss.oracle.com/projects/ocfs/dist/files/RedHat/RHEL3/i386/README.txt

says that the above mentioned problem is fixed in OCFS 1.0.9-12

"RELEASE 1.0.9-12

Fixes a potential corruption with large, aligned, direct I/Os, for
example Oracle redo logs or direct path SQL loader."

What it means that we can run database in ASYNC mode without any potential risk
of redo log corruption by installing OCFS "1.0.9-12" or later
"1.0.12".

Please advise.
Thanks
____________
Baqir Hussain
Database Administrator
zipRealty Inc.
(510)735-2696

> 
> >  Next, I saw a Metalink thread which suggests that async I/O is not
> > supported on OCFS with RHAS 2.1.  It doesn't say anything 
> about RHEL3.
> > We've been using async in our testing with no problems so 
> far, and plan to
> > use it in production unless Oracle feels the combination is not yet
> > trustworthy.
> 
> well - tough one, it works, but the big issue is that you rredologfile
> need to be contiguous on disk, otherwise you might have 
> failures, exact
> same goes for rhel3 as rhas21. you can see that by running debugocfs
> eg :
> /ocfs/log/foo1.dbf -> debugocfs -f /log/foo1.dbf /dev/sdXXX
> that will show how many offsets (should only have one) in the extents
> if its more than 1, dd it over with a very large blocksize and see if
> that ends up being 1 contig file.
> 
> if you do that, everything should work, however, there just 
> hasn't been
> enough real testing with aio, need to ggather more evidence.
> 
> the reason the logfiles are annoying is because he way aio is
> implemented and how we call it, it cannto handle short io's or non
> contig aio submits.
>> 
_______________________________________________
Ocfs-users mailing list
Ocfs-users@oss.oracle.com
http://oss.oracle.com/mailman/listinfo/ocfs-users

Well, you are the second person intrigued by this comment. That comment
related to largeios in the odirect path, not the asyncio path.

The basic asyncio issue probably will not be resolved till we move to
the 2.6 kernel.

On Thu, 2004-06-03 at 10:10, Baqir Hussain wrote:
> Running database in ASYNC mode in RHEL 3 has a potential risk of redo logs
failure due to some short io's.
> A note from 
> http://oss.oracle.com/projects/ocfs/dist/files/RedHat/RHEL3/i386/README.txt
> 
> says that the above mentioned problem is fixed in OCFS 1.0.9-12
> 
> "RELEASE 1.0.9-12
> 
> Fixes a potential corruption with large, aligned, direct I/Os, for
> example Oracle redo logs or direct path SQL loader."
> 
> What it means that we can run database in ASYNC mode without any potential
risk of redo log corruption by installing OCFS "1.0.9-12" or later
"1.0.12".
> 
> Please advise.
> Thanks
> ____________
> Baqir Hussain
> Database Administrator
> zipRealty Inc.
> (510)735-2696
> 
> 
> > 
> > >  Next, I saw a Metalink thread which suggests that async I/O is
not
> > > supported on OCFS with RHAS 2.1.  It doesn't say anything 
> > about RHEL3.
> > > We've been using async in our testing with no problems so 
> > far, and plan to
> > > use it in production unless Oracle feels the combination is not
yet
> > > trustworthy.
> > 
> > well - tough one, it works, but the big issue is that you rredologfile
> > need to be contiguous on disk, otherwise you might have 
> > failures, exact
> > same goes for rhel3 as rhas21. you can see that by running debugocfs
> > eg :
> > /ocfs/log/foo1.dbf -> debugocfs -f /log/foo1.dbf /dev/sdXXX
> > that will show how many offsets (should only have one) in the extents
> > if its more than 1, dd it over with a very large blocksize and see if
> > that ends up being 1 contig file.
> > 
> > if you do that, everything should work, however, there just 
> > hasn't been
> > enough real testing with aio, need to ggather more evidence.
> > 
> > the reason the logfiles are annoying is because he way aio is
> > implemented and how we call it, it cannto handle short io's or non
> > contig aio submits.
> >> 
> _______________________________________________
> Ocfs-users mailing list
> Ocfs-users@oss.oracle.com
> http://oss.oracle.com/mailman/listinfo/ocfs-users
> _______________________________________________
> Ocfs-users mailing list
> Ocfs-users@oss.oracle.com
> http://oss.oracle.com/mailman/listinfo/ocfs-users