There is always "best" and "worst" for anything, everything. Rather than posting the link I think if you google by "RHEL AND FILESYSTEMIO_OPTIONS=SETALL", you will find top 5 links which you may be interested in this case.
But, I shall echo Sb's question What problem are you trying to solve? Is there really a problem or you are just exploring the things ?
Remember this is only relevant when you are using local file systems as storage for the database files.
So, the questions are simple:
Does your system support async IO? If so then yes using it is a good idea. Direct IO is recommended because oracle already handles the caching of frequently used data, making it redudant to use FS IO caching.
My file system is ext3. It is not raw device. Seraching google, it appears that ext3 will support async io. So I can set both asynch io and direct_io using setall. I was getting confused that I have to use raw devices (which are hard to maintain to use asynch io.
Thanks a lot for your help.
Your explanations are perfectly fine. It make sense only for local disks only .. I doubt.
Even for SAN envs it make sense and are used. Async_IO make the Oracle code , look at the way how to do async IO calls in conjugation with underlying OS. DirectIO as you said bypasses the overhead of caching layer of OS
Experts, please let me know your thoughts
Asynchronous I/O on raw devices (ASM file systems) are supported by default. This is controlled by the parameter DISK_ASYNCH_IO, which default is TRUE. DirectIO is also enabled by default in this case through the /dev/raw interface if you're on linux.
Reference: Administering Oracle Database on Linux
Thanks for reply and explanations.
disk_async_io , now I understand as to turn async IO on/off . When ON it is set for raw devices. It will be ON for Filesystems when filesystemio_options=async or setall.
As you said, it is only relevant when you are using local file systems as storage for the database files.
Buffered IO I still feel that is related to OS and not related to file systems as such