ASMLIB provides an interface provisioning disks for use with the Oracle Database and its Automatic Storage Management component.
The original release of ASMLIB relied on a custom kernel driver, oracleasm. The driver was needed due to limitations in the various interfaces provided by the Linux kernel at the time. However, Linux has come a long way in the last 20 years. With the introduction of the io_uring programming interface, there is no longer a need for a custom kernel driver to achieve high performance.
The ASMLIB library
ASMLIB version 3 adds support for the io_uring API implemented in the Linux kernel. On Unbreakable Enterprise Kernel (UEK) Release 7 or later, ASMLIB will use the io_uring interface when submitting I/O requests to the kernel.
ASMLIB version 3 also retains support for the previous interface which depends on the ‘oracleasm’ kernel driver. On Unbreakable Enterprise Kernel Release 6, ASMLIB will use the ‘oracleasm’ driver when submitting I/O requests to the kernel.
Having support for both interfaces in the same library binary ensures that customers can freely upgrade and downgrade their systems between kernel versions without having to modify their ASMLIB configuration or update the oracleasmlib package. The library will pick the appropriate interface at runtime based on the running kernel.
io_uring
io_uring is a new kernel interface (introduced in Linux version 5.1) to efficiently allow send and receive data. io_uring uses a pair of submission and completion queues which are shared between application and Kernel.
Linux applications typically use POSIX read()/write() calls when reading and writing files. However, the associated system call overhead can have a substantial impact on performance.
io_uring, through its queues shared between userland and kernel, allow many operations to be submitted and reaped in a single system call. A similar approach to what was provided by the ‘oracleasm’ driver.
With io_uring the application inserts new I/O requests in the submission queue and the kernel consumes the requests when io_uring_enter() is called. Upon completion, the kernel indicates completion status in the completion queue. When io_uring_enter() returns, the application consumes the completion queue responses.
Because multiple requests can be submitted and reaped in a single call, the io_uring interface is very efficient compared to regular POSIX I/O.
Benefits of io_uring
-
Lower system calls: The number of system calls required reduces significantly freeing CPU cycles.
-
Batch processing: The submission queue enables a set of IO requests to be sent with one system call. The completion queue enables the kernel to asynchronously notify applications about IO completion.
-
Improved application responsiveness that handle large volumes of data, enables scaling an improved performance.
End-to-End Data Integrity Protection
The io_uring interface also provides access to advanced storage features such as end-to-end data integrity protection. This feature requires the ASM disks to be provisioned on storage devices which implement T10 Protection Information (T10 PI).
End-to-end data protection works by attaching additional metadata to each I/O. This metadata includes a CRC guarding the data in each block. Storage controllers and drives which support T10 PI are able to validate that the CRC matches the data, thus providing an enhanced protection against silent data corruption.
In addition, to reduce CPU overhead, ASMLIB version 3 will use hardware offload functionality to generate and verify CRCs.
Thin Provisioning
ASMLIB version 3.1 adds support for reclaiming unused space on devices that support thin provisioning. Reclaim operations initiated by the ASM tooling will be submitted to the underlying storage using the appropriate command given the type of storage (Trim, Unmap, Write Zeroes w/ Deallocate).
IO filtering
ASMLIB version 3 provides a security mechanism to ensure ASM disks are not accidentally overwritten by other applications. A filter inspects all write operations submitted to ASM disks and rejects any I/Os that do not originate from Oracle Database processes. This prevents accidental overwrite of ASM disks.
Disk Group Membership
In addition to the I/O filter described above, ASMLIB version 3.1 also prevents deleting or relabeling disks which are currently part of an ASM Disk Group. This prevents accidental removal of ASM disks which are currently in use by other nodes in a cluster.
Per-I/O Block Size Selection
Previous versions of ASMLIB required the user to select at driver load time whether the logical or the physical block size of the underlying storage device should be used. This made it difficult to migrate ASM disks from other systems where a different setting had been used when creating the disk.
ASMLIB version 3.1 adds support for per-I/O block size selection. This facilitates migrating ASM disks and disk groups created on other systems with a different storage configuration. ASM will now use the block size the disk was originally provisioned with.
oraclesasm utility
The ‘oracleasm’ utility provided in the oracleasm-support package has been updated to use the new interfaces to configure, initialize, discover, create, delete, and query ASM disks.
# oracleasm
Usage: oracleasm [--exec-path=<exec_path>] <command> [ <args> ]
oracleasm --exec-path
oracleasm -h
oracleasm -V
The basic oracleasm commands are:
configure Configure the oracleasm service
init Load and initialize the oracleasm service
exit Stop the oracleasm service
scandisks Scan the system for Oracle ASM disks
status Display the status of the oracleasm service
listdisks List known Oracle ASM disks
querydisk Determine if a disk belongs to the oracleasm service
createdisk Label a device for Oracle ASM use
deletedisk Clear Oracle ASM disk label
renamedisk Change the label of an Oracle ASM disk
discover List disks matching a given discovery string
The configure option allows to set the UID and GUID and other options. It also has an option to specify the maximum number of disks and allow IO filter, by default it set to ‘enabled’.
# oracleasm configure ORACLEASM_UID=oracle ORACLEASM_GID=oinstall ORACLEASM_SCANBOOT=true ORACLEASM_SCANORDER="" ORACLEASM_SCANEXCLUDE="" ORACLEASM_SCAN_DIRECTORIES="" ORACLEASM_USE_LOGICAL_BLOCK_SIZE="false" ORACLEASM_CONFIG_MAX_DISKS="2048" ORACLEASM_ENABLE_IOFILTER="true"
ASMLIB version 3 enhances the output of the ‘oracleasm status’ command to display additional information about how oracleasm has been configured and whether the service is operating correctly:
# oracleasm status 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 ASMLIB can be loaded: yes Checking if io_uring is enabled: yes Checking if io_uring is accessible to the configured DB user: yes Checking if io_uring supports integrity passthrough: no Checking if ASM disks have the correct ownership and permissions: yes Checking if ASM I/O filter is set up: yes
Other ‘oracleasm’ operations work as before:
# oracleasm init Mounting ASMlib driver filesystem: Not applicable with kernel 5.15.0 Setting up iofilter map for ASM disks: done # oracleasm scandisks Reloading disk partitions: done Cleaning any stale ASM disks... Setting up iofilter map for ASM disks: done Scanning system for ASM disks... # oracleasm createdisk ASM3 /dev/nvme0n1p1 Writing disk header: done Instantiating disk: done # oracleasm querydisk -p -d ASM3 Disk "ASM3" is a valid ASM disk /dev/nvme0n1p1: LABEL="ASM3" TYPE="oracleasm" PARTUUID="9e32e770-01" # oracleasm deletedisk ASM3 Clearing disk header: done Dropping disk: done # oracleasm exit Unloading module "oracleasm": Not applicable with kernel 5.15.0 Unmounting ASMlib driver filesystem: Not applicable with kernel 5.15.0 Removing iofilter map /sys/fs/bpf/iofilter_asm: done
Note: The pseudo devices under /dev/oracleasm/disks are deprecated when io_uring is in use. ASMLIB accesses the device nodes directly.
The ‘oracleasm discover’ command displays information about attached ASM disks:
# oracleasm discover Using ASMLIB from /opt/oracle/extapi/64/asm/orcl/1/libasm.so [ASM Library - Linux, version 3.1.0 (KABI_V3), Jan 27 2025 00:00] Discovered disk: ORCL:VOL2 [209713152 blocks (107373133824 bytes), blksz 512/512, maxio 1310720 bytes, integrity T10-DIF-TYPE1-CRC] Discovered disk: ORCL:VOL1 [209713152 blocks (107373133824 bytes), blksz 512/512, maxio 1310720 bytes, integrity T10-DIF-TYPE1-CRC]
The ‘oracleasm discover’ command also has a long-form option which displays additional information about each ASM disk:
# oracleasm discover -l
Using ASMLIB from /opt/oracle/extapi/64/asm/orcl/1/libasm.so
[ASM Library - Linux, version 3.1.0 (KABI_V3), Jan 27 2025 00:00]
ORCL:VOL1
Device: /dev/dm-6 (252:6)
Device UUID: naa.3600144f08008c2ec000067d3495c0002-part1
Disk Group: <unknown>
Capabilities: IO | UDID | NOGLOBAL
Size: 209713152 blocks (107373133824 bytes)
Logical Block Size: 512 bytes
Physical Block Size: 512 bytes
Max I/O Size: 2560 blocks (1310720 bytes)
Data Integrity: T10-DIF-TYPE1-CRC
Thin Provisioning: unsupported
Max TP I/O Size: 0 blocks (0 bytes)
ORCL:VOL2
Device: /dev/dm-11 (252:11)
Device UUID: naa.3600144f08008c2ec000067d3496e0003-part1
Disk Group: <unknown>
Capabilities: IO | UDID | NOGLOBAL
Size: 209713152 blocks (107373133824 bytes)
Logical Block Size: 512 bytes
Physical Block Size: 512 bytes
Max I/O Size: 2560 blocks (1310720 bytes)
Data Integrity: T10-DIF-TYPE1-CRC
Thin Provisioning: unsupported
Max TP I/O Size: 0 blocks (0 bytes)
Conclusion
ASMLIB verson 3 provides the latest interface to scale IO with io_uring, end-to-end data protection with T10 PI DIF/DIX, thin provision, io-filtering and disk group membership so that the asm disk data is not accidently overwritten or deleted.