This content has been marked as final. Show 5 replies
What is the actual device used? Is it a (SATA/SAS) disk? Is it a partition on such a disk? Is it a LUN from a storage array?
Raw device means that ASM needs direct access to the device (it opens the device with a direct I/O flag enabled). There can thus be no other s/w driver layer involves that prevents direct I/O and provides some kind of write-thru and buffering feature.
If you are using a local disk as raw device, e.g. +/dev/sdc+, then use this device as is as an ASM device. Permissions and ownership however needs to be changed to allow ASM's o/s user to own that device.
No LVM. ASMlib is optional.
The use of raw disk devices since RHEL 5 and derivatives has been depreciated. Raw disk access under the Linux kernel to bypass kernel caching and I/O scheduling is to done by the software that is opening the device with the O_DIRECT kernel flag.
Like the previous reply outlines, you will need to set proper device privileges to be able to use devices for ASM. The /dev device tree in Linux resets at every system restart, thus ASM will not be able to access any devices until you set correct device privileges and ownership.
You can define device privileges for ASM disks by defining UDEV rules or setup DM multipath. You can install Oracle ASMLib for Linux, which simplifies device management and provides an alternative optimized I/O driver. The necessary ASMLib kernel module as of Oracle Linux 6 is however only included with the Oracle Linux UEK kernel. ASMLib does not provide device path fail-over, for which you will need multipath, but you can certainly take advantage of both.
Dude wrote:There are raw devices and raw devices. The one means defining a character device as a raw device for a block device (deprecated).
The use of raw disk devices since RHEL 5 and derivatives has been depreciated.
The original term (dating back to the 80's in my experience) and still used today, simply means directly accessing the device without caching performed by the kernel. Typically a raw device versus cooked file system concept. And this still very much applies and have very little in common with the transient and deprecated "raw character device for block device" feature of the Linux kernel.
Yes, of course. I was only referring to Linux, not commercial Unix systems. As far as I know, Linux was initially designed for low-end and cheap computer hardware. A lot has changed since, but the initial design concept of Linux that the kernel should cache and schedule/group all I/O to optimize performance remains. Raw device access makes sense for applications and hardware that deal with I/O on it's own, usually more expensive devices, at least in the past.
We already discussed a similar topic at support rawdevices by linux oracle. Please see my last reply.
Dude wrote:It was a very basic 386/486 kernel written with AT harddrive support, and without any illusions of it being more than a simple Open Source o/s for mucking around... (see Linus's first posting on what was to become the Linux kernel).
As far as I know, Linux was initially designed for low-end and cheap computer hardware.
Truly amazing what it had become. I used to compile the Linux kernel from 2 x 1.44MB stiffies downloaded from the Net, and installed on a 20MB harddrive in a 386 AT clone PC. With IP support for an Exos105T NIC that had a MS-DOS driver that could not be loaded into high memory - had to use conventional 640KB RAM... :-)
A lot has changed since, but the initial design concept of Linux that the kernel should cache and schedule/group all I/O to optimize performance remains. Raw device access makes sense for applications and hardware that deal with I/O on it's own, usually more expensive devices, at least in the past.Not really expensive devices - SATA and SAS devices are quite cheap compared to higher-end disk storage (like SSDs). And these can be RAID'ed just fine using ASM as raw devices.