This content has been marked as final. Show 8 replies
912919 wrote:ASMLib is not needed for running ASM.
I have instale OEL
uname -r --->>> 2.6.32-200.13.1el6uek
what is the ASMLIB version compatbible with this
And I would again question why ASMLib should be used when default multipath (which you have already installed with OEL) has the feature set needed for providing consistency in device naming and dealing with multiple I/O paths. ASM works very well directly on multipath devices.
I would also question why multipath, which origins stem from building the largest clusters on this planet, dealing with PB storage, and is still being used every day in such clusters, should not be used for Oracle ASM in favour of ASMLib....
After throwing ASMLib out some years ago (incompatibility with EMC Powerpath) and building all our clusters with Multipath (after throwing Powerpath out too), I thought we were the only ones that used a proper Open Source stack that does not taint the kernel.
Good to hear that we're not alone on this. :-)
We've used (still are using) Multipath for fibre channel devices, SRP devices, SCST devices... and even a mix of these. Clusters ranging from RHEL3 to RHEL5 over the years. No ASMLib. No proprietary vendor s/w.
No adding another s/w layer to the driver stack, without a single sound and sensible reason as justification for that. (and I've asked "why AsmLib" a number of times on OTN and never got a meaningful response as to what makes it better than not using AsmLib)
as to "why ASMLib":
As far as my knowledge goes, ASMLib provides only one real advantage over UDEV/Multipath and that has to do with open file handles.
If you don't use ASMLib then each and every process of a database doing I/O will have a file handle open for each ASM disk.
When using ASMLib only ASMLib has the file handles open.
So on big server with multiple ASM disks and multiple databases this resource constraint may become visible.
A device or file handle is AFAIK not "portable" across process boundaries. So one process cannot use and open a handle and pass that to another process - unless it does something like redirecting that handle as the stdin and stdout handles of the new process, allowing that new process to use stdin to read and stdout to write to that device...? (but then I last did this type of thing on SVR4 so likely my understanding of this is outdated)
Will be interested to know the technical details of just how ASMlib goes about sharing(?) direct I/O device handles to multiple processes.
Because it is Linux only, it becomes a non-starter for sites that have standardized system builds. I have not experienced any problems with running out of file descriptors even on systems with hundreds of disks and thousands of data files nor have I had of the problems described in the "ASM Under the hood" book associated with NOT using ASMlib.