RIP ASM Filter Drivers

We originally wrote about the retirement of ASM Filter Drivers, and the re-introduction of ASMLib, about a year ago.  Since that article, the ASMLib software has continued to evolve with some of the concerns and limitations we covered being resolved.  We have therefore undertaken to revise our opinion of the ASMLib package, as well as correct some mistakes made in the earlier published article.

Oracle has deprecated ASM Filter Drivers.  Where should DBAs go next for ASM device management and persistency?

In MOS note 2806979.1, Oracle has announced that ASM Filter Drivers are being deprecated due to changes in the I/O interface of Linux kernels.  Oracle Database 19c Release Update 24 (19.24) disables the ASM Filter Drivers.

At Pure Storage, we were big fans of ASM Filter Drivers since their introduction in Oracle 12c.  ASM Filter Drivers were simple, provided ASM device management, consistent names across RAC clusters, filtered IO from unauthorized processes and they provided TRIM support for space reclamation on thinly provisioned devices.

With Oracle now deprecating support for ASM Filter Drivers, Oracle suggests that DBAs migrate to ASMLIB V3 or to UDEV rules.  Both options work great on Pure Storage, but which is the best choice for your ASM based Oracle databases?

ASMLIB V3

ASMLIB V3 provides the same core functionality as ASM Filter Drivers did.  It will manage device permissions and it will maintain consistent names across a cluster and cross reboots.  Like ASM Filter Drivers, ASMLIB V3 includes support for reclaiming storage from thinly provisioned disks.

On some Linux kernels ASMLIB V3 can also filter IO to the ASM disks, potentially protecting the ASM disks from malicious or erroneous activity.  This was a key feature of ASM Filter Drivers.

However not all Linux kernels have this support.  A helpful support matrix was added to the ASMLIB V3 documentation (https://docs.oracle.com/en/operating-systems/oracle-linux/asmlib/asmlib-AboutASMLib.html#asmlib_feature_support_matrix) which shows which kernels support this feature.

An interesting feature of ASMLIB V3 is Automatic Block Size Selection, which enables ASMLIB V3 to automatically select whether to use the logical or the physical block size on a per-I/O basis.  This should allow ASM to migrate or access disks that were originally configured using different sector sizes. 

Partitioning ASM Disks

One great feature of ASM Filter Drivers was that they did not require a partition header on volumes, which meant that future capacity expansion could be handled as easily as resizing the volumes larger in Purity, re-scanning the SCSI bus on the database host, reloading the multipath map and then issuing the ASM command:

SQL> alter diskgroup MYASMDG resize all;

ASMLIB 3.1.1 can now discover ASM disk labels on unpartitioned block devices, which is a welcome improvement.  If the DBA had built ASM diskgroups on unpartitioned disks managed by ASM FD, these disks can now more easily be migrated to ASMLIB V3.

In testing, when labelling new ASM disks, ASMLIB V3 still expects a partition header for devices referenced in the hardware device table (i.e. /dev/sdc ) but not logical block devices such as those presented through /dev/mapper.

The requirement for a partition header can over-ridden using the force flag:

[root@gct-oradb-asmlib02]# oracleasm createdisk DATA01 /dev/sdc
Device ‘/dev/sdc’ requires a partition

[root@gct-oradb-asmlib02]# oracleasm createdisk -f DATA01 /dev/sdc

Device ‘/dev/sdc’ requires a partition

Device ‘/dev/sdc’ is a suitable ASM disk candidate

Forced – continuing anyway

Writing disk header: done

Instantiating disk: done

It should be noted that if the DBA does choose to use partition headers, resizing the volumes is still possible, but will typically involve dismounting the ASM diskgroup, deleting the partition header and then recreating it.

Resizing existing partitions larger is possible in Linux, but when using ASMLib 3 resulted in IO errors, which we suspect are connected to ASMLib filtering IO to the ASM disks.

[root@gct-oradb-26ai-dev02]# parted -s -a opt /dev/sdk “resizepart 1 100%”

Warning: Error fsyncing/closing /dev/sdk1: Input/output error

Warning: Error fsyncing/closing /dev/sdk1: Input/output error

Warning: Not all of the space available to /dev/sdk appears to be used, you can fix the GPT to use all of the space (an extra 41943040 blocks) or continue with the current setting?

Error: Unable to satisfy all constraints on the partition.

It should be noted that DBAs may still choose to expand capacity by adding additional disks to a diskgroup.  This latter approach is supported, irrespective of ASMLIB or UDEV, irrespective of partition headers or not.  

The add-disk approach however will result in an ASM rebalance and compaction, which yields zero benefit on an all-flash storage solution like Pure Flash Array.

Discovering ASMLib disks on another node

Another behavior noted in the lab that is worth exploring, is when presenting already-stamped ASM disks to ASMLib.  This might happen when presenting RAC clustered disks to the non-primary nodes, or when presenting an Everpure storage snapshot of ASM disks to mount hosts.

In lab testing, issuing an oracleasm scandisks does not discover the already stamped disks, but oracleasm querydisk will report that the disk is stamped for ASM.  

Whereas ASM Filter Drivers was able to handle this scenario, ASMLib will not recognize the newly presented volumes as valid ASM disks until the ownership has been changed from the Linux default root:root to the userid and group of the Oracle ASM install. (e.g. grid:asmadmin ), and the multipath map reloaded.

Selecting ASMLIB or UDEV rules

If you already using UDEV rules and are happy with how they work, there may be no compelling reason to change.  If you are using ASM Filter Drivers, then at some point you are going to need to migrate to UDEV rules or to ASMLIB V3.

A consideration should be; what OS are you on, and what is your future upgrade path?  

When we tested this in our lab at Everpure, we found that ASMLIB 3.1 would install on RHEL9.2, but that ASM could not see any ORCL:* disks.  The discover command failed as follows:

[root@gct-oradb-asmlib02 ~]# oracleasm discover
Using ASMLIB from /opt/oracle/extapi/64/asm/orcl/1/libasm.so
asm_version() failed with error: Generic initialization error: Function not implemented

We found that we had to upgrade to at least RHEL9.3 and reboot the database server before ASMLIB 3.1.1 would function as expected.

If you are using ASM Filter Drivers, then the next question should be; are you using partition headers on your ASM disks?  To determine if you are or not, you can check using the following:

[root@gct-oradb-oel8-10-1]# asmcmd afd_lsdsk

————————————————————————–

Label                     Filtering   Path

==========================================================================

GRID01                     DISABLED   /dev/sdb

SWINGDATA01                DISABLED   /dev/sdc

SWINGDATA02                DISABLED   /dev/sdd

SWINGDATA03                DISABLED   /dev/sde

SWINGDATA04                DISABLED   /dev/sdf

NOTE: Make a note of the output of this command before you try to remove ASM Filter Drivers.  We will need this information later.

In the above example, AFD disk GRID01 has a physical path of /dev/sdb.  The lack of a trailing “1” here tells us that ASM is using the full volume with no partition header.  If the physical path had been shown as /dev/sdb1, then we would determine that partition headers were in use.

Removing ASM Filter Drivers

To migrate, we will need to first make sure that we have a copy of our +ASM SPFILE if it currently resides on an ASM managed disk.  

SQL> show parameter spfile

NAME       TYPE        VALUE

———- ———– ————————————————–

spfile     string      +GRID/ASM/ASMPARAMETERFILE/registry.253.1206053153

To create a copy of the SPFILE we can use the spcopy command in ASM:

[oracle@gct-oradb-asmlib02]$ asmcmd spcopy +GRID/spfile /u01/app/grid/19c/dbs/spfile+ASM.ora

In the following example we also create a PFILE copy in case we need to edit settings manually.

SQL> create pfile=’/u01/app/grid/19c/dbs/init+ASM.ora’ from spfile;

File created.

Next, we will need to shutdown Oracle.  This includes all databases and the Grid Infrastructure or Oracle Restart components:

[oracle@gct-oradb-asmlib02]$ crsctl stop has

Once Oracle is completely shut down, log in as root.  At this point if we try to deconfigure ASM Filter Drivers we may get an error about acfsload being active.  To avoid this, we can use:

[root@ gct-oradb-asmlib02 ~]# acfsload stop

And now we should be able to deconfigure ASM Filter Drivers on this node:

[root@gct-oradb-asmlib02 ~]# asmcmd afd_deconfigure

AFD-632: Existing AFD installation detected.

AFD-634: Removing previous AFD installation.

AFD-635: Previous AFD components successfully removed.

Modifying resource dependencies – this may take some time.

Option 1 – Configure ASMLIB V3

With ASM Filter Drivers deconfigured, we can install the ASMLIB binaries.  In the following example, the database server was upgraded to RHEL 9.7 after ASM Filter Drivers were removed. 

[root@gct-oradb-asmlib01]# rpm -ivh oracleasm-support-3.1.0-10.el9.x86_64.rpm
warning: oracleasm-support-3.1.0-10.el9.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 8d8b756f: NOKEY
Verifying…                          ################################# [100%]
Preparing…                          ################################# [100%]
Updating / installing…
   1:oracleasm-support-3.1.0-10.el9   ################################# [100%]
Created symlink /etc/systemd/system/multi-user.target.wants/oracleasm.service → /usr/lib/systemd/system/oracleasm.service.

[root@gct-oradb-asmlib01]# rpm -ivh oracleasmlib-3.1.1-1.el9.x86_64.rpm
warning: oracleasmlib-3.1.1-1.el9.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 8d8b756f: NOKEY
Verifying…                          ################################# [100%]
Preparing…                          ################################# [100%]
Updating / installing…
   1:oracleasmlib-3.1.1-1.el9         ################################# [100%]

With ASMLIB installed, we can now configure it.  In this example we are specifying that the ASM disks will be owned by the Oracle account “oracle” and the group as “oinstall”:

[root@gct-oradb-asmlib01]# oracleasm configure -i
Configuring the Oracle ASM system service.

This will configure the on-boot properties of the Oracle ASM system
service.  The following questions will determine whether the service
is started on boot and what permissions it will have.  The current
values will be shown in brackets (‘[]’).  Hitting <ENTER> without
typing an answer will keep that current value.  Ctrl-C will abort.

Default user to own the ASM disk devices []: oracle
Default group to own the ASM disk devices []: oinstall
Start Oracle ASM system service on boot (y/n) [y]: y
Scan for Oracle ASM disks when starting the oracleasm service (y/n) [y]: y
Maximum number of ASM disks that can be used on system [2048]:
Enable iofilter if kernel supports it (y/n) [y]: y
Writing Oracle ASM system service configuration: done

Configuration changes only come into effect after the Oracle ASM
system service is restarted.  Please run ‘systemctl restart oracleasm’
after making changes.

WARNING: All of your Oracle and ASM instances must be stopped prior
to restarting the oracleasm service.

We can now start the ASMLIB service on our database host

[root@gct-oradb-asmlib01]# systemctl restart oracleasm

[root@gct-oradb-oel8-10-1]# oracleasm init

Mounting oracleasm driver filesystem: Not applicable with kernel 5.15.0

Reloading disk partitions: done

Cleaning any stale ASM disks…

Setting up iofilter map for ASM disks: done

Scanning system for ASM disks…

Disk scan successful

At this point, ASMLIB V3.1.1  is able to discover the ASM FD disks:

[root@gct-oradb-asmlib01]# oracleasm discover
Using ASMLIB from /opt/oracle/extapi/64/asm/orcl/1/libasm.so
[ASM Library – Linux, version 3.1.1 (KABI_V3), 2025-07-24 22:50]
Discovered disk: ORCL:GRID [67108864 blocks (34359738368 bytes), blksz 512/512, maxio 1310720 bytes, integrity unsupported]

[root@gct-oradb-asmlib01]# oracleasm listdisks
GRID

And now we can verify that ASMLIB is running:

root@gct-oradb-asmlib01]# oracleasm status
Checking if the oracleasm kernel module is loaded: no (Not required with kernel 5.14.0)
Checking if /dev/oracleasm is mounted: no (Not required with kernel 5.14.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

Option 2 – creating UDEV rules

With ASM Filter Drivers deconfigured, we now need to generate UDEV rules to manage the devices that were previously managed by the ASM Filter Drivers.  

In the following example I am using a simple ksh script to help.  The script is downloadable from the Everpure Github repository at https://github.com/PureStorage-OpenConnect/oracle-scripts.

One of our first steps was to use the asmcmd afd_lsdsk command list the ASM disks.  We can now use that information to help generate the UDEV rules for the ASM disk that is /dev/sdb.

[root@gct-oradb-asmlib02 ~]# ./cr_udev.ksh -d GRID -l sdb

KERNEL==”sd*”, SUBSYSTEM==”block”, ENV{ID_SERIAL}==”36000c29a1a61e59a56e83549e83ec6a3″, SYMLINK+=”oracleasm/GRID00″, OPTIONS:=”nowatch”, OWNER=”oracle”, GROUP=”dba”, MODE=”0660″

In the above example we are creating a UDEV rule for device /dev/sdb, and we are going to assign this device a label of GRID00 under UDEV management.  If we have more ASM disks to move to UDEV management , we will need to do this as well.  Next, we will create rules for the four SWINGDATA disks, which are devices /dev/sdc, /dev/sdd, /dev/sde and /dev/sdf.

[root@gct-oradb-asmlib02 ~]# ./cr_udev.ksh -d SWINGDATA -l sdc,sdd,sde,sdf

KERNEL==”sd*”, SUBSYSTEM==”block”, ENV{ID_SERIAL}==”36000c299d46b0ae09991b7aedf50dd5f”, SYMLINK+=”oracleasm/SWINGDATA00″, OPTIONS:=”nowatch”, OWNER=”oracle”, GROUP=”dba”, MODE=”0660″

KERNEL==”sd*”, SUBSYSTEM==”block”, ENV{ID_SERIAL}==”36000c297fa980ea88fa8dce16818c65c”, SYMLINK+=”oracleasm/SWINGDATA01″, OPTIONS:=”nowatch”, OWNER=”oracle”, GROUP=”dba”, MODE=”0660″

KERNEL==”sd*”, SUBSYSTEM==”block”, ENV{ID_SERIAL}==”36000c29bf0a2a282fa9bc3fab183444f”, SYMLINK+=”oracleasm/SWINGDATA02″, OPTIONS:=”nowatch”, OWNER=”oracle”, GROUP=”dba”, MODE=”0660″

KERNEL==”sd*”, SUBSYSTEM==”block”, ENV{ID_SERIAL}==”36000c298432ffc4e6d8272a9cebbce31″, SYMLINK+=”oracleasm/SWINGDATA03″, OPTIONS:=”nowatch”, OWNER=”oracle”, GROUP=”dba”, MODE=”0660″

The output of these scripts needs to be added to a UDEV rules file.  You might decide to have one file per set of ASM disks, or a single file for all.  In this example we will put all of our rules into /etc/udev/rules.d/99-oracle-asmdevices.rules

Now we tell UDEV to re-read the rules:

[root@gct-oradb-asmlib02 ~]# /sbin/udevadm control –reload-rules

[root@gct-oradb-asmlib02 ~]# /sbin/udevadm trigger

At this point we should now see our ASM disks under /dev/oracleasm:

[root@gct-oradb-asmlib02 ~]# ls /dev/oracleasm

GRID00

SWINGDATA00

SWINGDATA01

SWINGDATA02

SWINGDATA03

Reconfigure ASM

With ASM Filter Drivers removed, and either ASMLIB or UDEV rules configured, the ASM instance can now be reconfigured.

Restart Oracle Restart or Grid Infrastructure.

[oracle@gct-oradb-asmlib01]$ crsctl start has

CRS-4123: Oracle High Availability Services has been started.

Now we need to check to see where the +ASM instance is looking for the ASM disks.  At this point it is probably still pointing to AFD:*

[oracle@gct-oradb-asmlib02]$ srvctl config asm

ASM home: <CRS home>

Password file:

Backup of Password file:

ASM listener: LISTENER

Spfile: /u01/app/grid/19c/dbs/spfile+ASM.ora

ASM diskgroup discovery string: AFD:*

To change this, we can modify the setting as follows for ASMLIB:

[oracle@gct-oradb-asmlib01]$ srvctl modify asm -d ‘ORCL:*’

Or for UDEV rules: 

[oracle@gct-oradb-asmlib02]$ srvctl modify asm -d ‘/dev/oracleasm*’

We also need to change the following disk-discovery string:

[oracle@gct-oradb-asmlib01]$ asmcmd dsset ‘ORCL:*’

Or for UDEV rules:

[oracle@gct-oradb-asmlib02]$ asmcmd dsset ‘/dev/oracleasm*’

Verify the change:

[oracle@gct-oradb-asmlib02]$ asmcmd dsget

parameter: ORCL:*

profile: ORCL:*

And next we can log into +ASM and verify the disk discovery string setting:

SQL> show parameter disk

NAME                         TYPE        VALUE

—————————- ———– ——————————

asm_diskgroups               string      GRID

asm_diskstring               string      ORCL:*

We should now be able to mount the diskgroups:

SQL> alter diskgroup GRID mount;

Diskgroup altered.

Lastly, to change the SPFILE back to its original location inside the ASM diskgroup:

[oracle@gct-oradb-asmlib02]$ srvctl modify asm -p +GRID/spfile

At Everpure, we would also recommend you take a snapshot of your ASM volumes before you make changes.  This will allow you to rapidly back out any changes that do not yield the expected result.  The snapshot might also allow you to test the changes on a non-production environment first to determine which approach is best, and how long these changes will take to implement.