Benefits of Upgrading Oracle ASMLib v3

Benefits of Upgrading Oracle ASMLib v3

  04/05/2025
Alireza Kamrani 

Oracle ASMLib (Automatic Storage Management Library) v3 introduces several improvements, particularly in performance, compatibility, and stability for ASM-managed storage:

• io_uring Integration: ASMLib v3 takes advantage of io_uring (if supported by the kernel) to enhance I/O performance, reducing system call overhead and improving disk access speeds.

• Better Kernel Compatibility: ASMLib v3 is designed to work with modern Linux kernels, particularly Oracle Linux 9 with UEK R7 or RHCK, ensuring long-term support and stability.

• Optimized I/O Handling: With io_uring, ASMLib can achieve lower latency and higher throughput for ASM disk operations, improving database performance.

• Multipath & Storage Improvements: Enhanced support for multipath devices ensures stable disk access, reducing the risk of ASM disk errors.

• Independent Updates: Unlike earlier versions that required kernel module recompilation, ASMLib v3 can be updated separately, simplifying maintenance.

How io_uring Benefits Oracle Databases

io_uring is a modern Linux I/O framework that optimizes database storage operations in the following ways:

• Asynchronous I/O with Lower Overhead: Reduces system call overhead, improving CPU efficiency.

• Batch Submission & Completion Queues: Supports bulk I/O processing, reducing latency for database workloads.

• Improved Log Writes & Checkpoints: Enhances performance for frequent redo log writes and data checkpointing.

• Optimized Multi-Threading: Supports non-blocking I/O, reducing contention in high-concurrency environments.

• Direct I/O Support: Works well with Direct I/O, minimizing memory copying and increasing efficiency for databases.

Considerations & Limitations

• Kernel Dependency: io_uring benefits are only available if running a supported kernel (e.g., UEK R7, OL9 RHCK).

• Data Integrity Passthrough Limitation: Certain integrity checks are not supported with io_uring due to kernel constraints, potentially affecting reliability in some cases.

Comparison of io_uring vs. libaio for Oracle Databases

Both io_uring and libaio provide asynchronous I/O (AIO) capabilities, but io_uring is a modern alternative with performance improvements. Here’s a detailed comparison:

1. Architecture & Mechanism

• System Calls

libaio: Requires multiple system calls for submission and completion.

io_uring: Uses shared ring buffers, reducing the number of system calls.

• Batching

libaio: Supports batching, but each batch still requires an extra system call.

io_uring: Supports native batching with submission and completion queues, improving efficiency.

• Polling

libaio: No direct polling support; relies on wake-ups.

io_uring: Supports polling, reducing latency and CPU overhead.

• Zero-Copy Support

libaio: No native zero-copy support.

io_uring: Can avoid unnecessary data copies, improving performance.

• Kernel Dependency

libaio: Works on older Linux kernels (2.6+).

io_uring: Requires Linux 5.1+ (or Oracle UEK R7 / OL9 RHCK).

2. Performance Considerations

• Latency

libaio: Higher due to additional system calls.

io_uring: Lower latency because it minimizes syscall overhead.

• Throughput

libaio: Good performance but suffers under high concurrency.

io_uring: Higher throughput due to reduced context switching.

• CPU Utilization

libaio: Higher CPU usage due to frequent context switches.

io_uring: Lower CPU overhead thanks to optimized batching and async handling.

• I/O Concurrency

libaio: Scales well but has syscall-related bottlenecks.

io_uring: Scales better, allowing higher parallelism in workloads.

3. Oracle Database Use Cases

• Redo Log Writes

libaio: Supported, but suffers from syscall overhead.

io_uring: More efficient due to polling and batching capabilities.

• Checkpoints & Background Writes

libaio: Works well but can experience delays due to context switching.

io_uring: Improves handling by reducing latency and CPU load.

• Datafile I/O (Direct I/O)

libaio: Compatible with ASM and filesystem I/O.

io_uring: More efficient for ASM-managed storage.

• Backup & Restore Operations

libaio: Uses traditional AIO methods, which can be slower.

io_uring: Faster due to reduced system call overhead.

Which One to Use?

• If using Oracle ASM with ASMLib v3 and a supported kernel (UEK R7, OL9 RHCK) → io_uring is the better choice for improved performance.

• If running on an older kernel or using direct database I/O without ASM → libaio is more stable and officially supported.

Configuring ASM I/O Filtering

oracleasm-support includes an ASM I/O filtering feature that depends on BPF infrastructure support in the kernel. This feature is available in UEK R7 or Oracle Linux 9 with RHCK. When enabled, the I/O filter feature rejects any write operations that aren't started by ASM and prevents writes to ASM disks by admin commands such as dd after disks have been added to the ASM system.

• Run the configuration utility to enable or disable I/O filtering.

By default, the I/O filter feature is enabled. Use the oracleasm configure command to disable or enable the I/O filter feature.

• Disable the I/O filter.

sudo oracleasm configure --iofilter n

• Enable the I/O filter.

sudo oracleasm configure --iofilter y

• Run the configuration utility to set the maximum number of disk devices that ASMLIB can use with I/O filtering.

I/O filtering requires a mapping of the maximum number of disk devices that ASMLIB can use. The default value is 2048, but this value can be changed to any value, such as 4096, by running:

sudo oracleasm configure --maxdevs 4096

Checking ASMLIB Configuration Status

Use the oracleasm status command to show the status of ASMLIB configuration. This command can help identify issues and can show which features are enabled.

• Run oracleasm status to view the current configuration status.

sudo oracleasm status

The following example output is taken from a system running UEK R7:Checking if the oracleasm kernel module is loaded: no (Not required with kernel 5.15.0) Checking if /dev/oracleasm is mounted: no (Not required with kernel 5.15.0) Checking which I/O Interface is in use: io_uring (KABI_V3) Checking if io_uring is enabled: yes Checking if ASM disks have the correct ownership and permissions: yes Checking if ASM I/O filter is set up: yesThe following checks are performed:

• Check if the oracleasm kernel module is loaded: The kernel module is required for earlier kernels that don't include io_uring.

• Check if the /dev/oracleasm is mounted: When the oracleasm kernel module is used, a device node is configured and mounted. This action isn't required with kernels that include io_uring.

• Check which I/O interface is being used: in the case of a kernel that's using KABI_V3 the io_uring interface is used, while a kernel using KABI_V2 uses the oracleasm driver interface.

Note that the following checks are only performed when KABI_V3 is detected:

• Check if io_uring is enabled: On a kernel that includes io_uring, the io_uring feature must be enabled to use ASMLIB.

• Check if ASM disks have correct ownership and permissions: Checks that any disk devices that are labeled for ASM use are owned by the user and group configured for ASM, and set when you initialized the configuration. 

• Check if ASM I/O filter is enabled and configured: On kernels that include the required BPF functionality, I/O filtering can be enabled and configured to protect ASM disks from accidental overwrites.