Exadata customers often need shared filesystem storage for application binaries, GoldenGate trail files, deployment artifacts, automation scripts, backup staging locations, and other files that must be accessible across a VM cluster. ACFS has long been a popular choice for these use cases, providing a cluster-aware filesystem that is managed as part of the overall Exadata environment.

With Exascale, ACFS filesystems can use Exascale volumes rather than traditional ASM disk groups. Using OEDACLI, a new ACFS filesystem can be added to an existing VM cluster with a single command while Exadata handles the storage provisioning and cluster integration steps.

What OEDACLI Automates

Behind the scenes, OEDACLI performs several tasks on your behalf:

  • Creates the ACFS volume in the specified vault
  • Creates a volume attachment for the target VM cluster
  • Presents the device to the cluster nodes
  • Registers the filesystem with Oracle Clusterware
  • Configures the ACFS mount point

The following example shows the ADD ACFSVOLUME syntax and an actual execution using an Exascale volume for ACFS storage.

ACFS Volume Creation

The ADD ACFSVOLUME command supports both ASM-backed and Exascale-backed ACFS deployments. Let’s have a quick look at the help for this command.

oedacli> help add acfsvolume
Usage:
ADD ACFSVOLUME
 VOLUMENAME = <volumename>
 VOLUMESIZE = <volumesize>
 MOUNTPATH = <mountpath>
 VAULT = <vault> <-- used with Exascale
WHERE
 DISKGROUPID = <diskgroupid> |
 CLUSTERNUMBER = <clusternumber> DISKGROUPNAME = <diskgroupname> |
 CLUSTERNAME = <clustername> DISKGROUPNAME < diskgroupname> |
 CLUSTERID = <clusterid> DISKGROUPNAME = <diskgroupname> |
 CLUSTERNUMBER = <clusternumber> | <-- used with Exascale
 CLUSTERNAME = <clustername> | <-- used with Exascale
 CLUSTERID = <clusterid> <-- used with Exascale

When using Exascale storage, the VAULT parameter identifies the vault that will contain the volume.

Now we have the syntax, let’s adda 100 GB ACFS filesystem mounted at /acfs4gg to VM Cluster I have on my Exadata Database Machine.

First, we’ll launch OEDACLI and import my configuration file (es.xml).

$ ./oedacli -c ExadataPMSystem-exdpm01-exdpm01-cluster1.xml
Version : 260530
SUCCESS - file loaded OK
Customer : Oracle- ExadataPMSystem

Next, I’m going to add the ACFS volume using the ADD ACFSVOLUME command. I’ll call the Exascale volume EXDPMACFS4GG (I’m going to use this GoldenGate). I need 100G of space and I want to mount it to /acfs4gg on all the VMs in my cluster. There is only one VM cluster in my configuration file, so you would need to adjust this if you have multiple to choose from, or use the cluster ID instead.

oedacli> ADD ACFSVOLUME VOLUMENAME=EXDPMACFS4GG VOLUMESIZE=100G MOUNTPATH='/acfs4gg' VAULT=exdpm01-cluster1vault where CLUSTERNUMBER=1

oedacli> save action
oedacli> merge actions

Merging Action : ADD ACFSVOLUME VOLUMENAME=EXDPMACFS4GG VOLUMESIZE=100G MOUNTPATH='/acfs4gg' VAULT=exdpm01-cluster1vault where CLUSTERNUMBER=1
Merging ADD ACFSVOLUME
Action Validated and Merged OK

Now I have everything ready, I’m going to deploy the changes.

oedacli> deploy actions

Deploying ADD ACFSVOLUME
Adding ACFS EntryEXDPMACFS4GG for Cluster exdpm01-cluster1 in XML configuration
Attaching ACFS Volume /acfs4gg to Cluster exdpm01-cluster1
Done...

oedacli> save file
File : ExadataPMSystem-exdpm01-exdpm01-cluster1.xml saved OK

Notice that while the requested volume name is EXDPMACFS4GG, OEDACLI automatically generates Exascale volume and device names that incorporate the cluster name and internal volume identifier. You will see those generated names in the verification steps below.

At this point, you’re ready to go with you ACFS filesystem! But let’s have a look under the covers and see what was created.

Viewing the Backing Exascale Volume

First we’ll look at the Exascale on one of the storage servers using escli.

$ escli --wallet $OSSCONF/security/admwallet/ lsvolume | grep -i EXDPMACFS4GG

vol0129_5fc191c5babc44d88894251848e1eaa0 EXDPMACFS4GG_exdpm01-cluster1_acfs DATA 2026-06-02T22:41:57-07:00 @exdpm01-cluster1vault/vol.12d5fd105f0e4f28a893394a50494ccb unlimited HC 1 high 100.0000G AVAILABLE admin @exdpm01-cluster1vault

Here we can see:

  • the volume name is EXDPMACFS4GG_exdpm01-cluster1_acfs
  • the volume size is 100G
  • the volume state is AVAILABLE
  • the volume resides in the @exdpm01-cluster1vault vault

Viewing the Volume Attachment

Next, let’s look at the Exascale volume attachment. This is the connection between the volume and the VM cluster consuming it.

$ escli --wallet $OSSCONF/security/admwallet/ lsvolumeattachment | grep -i EXDPMACFS4GG

att0138_ff8b8ef9e6104c6fad04dfd262457c41 vol0129_5fc191c5babc44d88894251848e1eaa0 EXDPMACFS4GG_exdpm01-cluster1_acfs_vol0129_5fc191c5babc44d88894251848e1eaa0 2026-06-02T22:41:59-07:00

Viewing the attachment in detail shows how the volume is presented to the VM cluster:

$ escli --wallet $OSSCONF/security/admwallet/ lsvolumeattachment att0138_ff8b8ef9e6104c6fad04dfd262457c41 --detail

id                                   att0138_ff8b8ef9e6104c6fad04dfd262457c41
attachTime                           2026-06-02T22:41:59-07:00
deviceName                           EXDPMACFS4GG_exdpm01-cluster1_acfs_vol0129_5fc191c5babc44d88894251848e1eaa0
devicePath                           /dev/exc/EXDPMACFS4GG_exdpm01-cluster1_acfs_vol0129_5fc191c5babc44d88894251848e1eaa0
enabledOnRestart                     true
giClusterId                          c5cc4353-06af-ef0b-ff70-d1a970f8f3f0
giClusterName                        exdpm01-cluster1
hostName
initiator
kernelDeviceName                     exc-dev1
logicalSectorSize                    512
volume                               vol0129_5fc191c5babc44d88894251848e1eaa0

Some interesting pieces of information can be found here, such as:

  • giClusterName identifies the target VM cluster using the Grid Infrastructure GUID
  • volume identifies the underlying Exascale volume
  • devicePath shows where the volume is exposed inside the guest operating system
  • enabledOnRestart=true indicates that the attachment persists across reboots

Viewing the Device on the VM Cluster

On one of the VM cluster nodes, the attached volume appears under /dev/exc:

$ cd /dev/exc/
$ ll

total 0
drwxr-xr-x. 3 dbmsvc dbmusers   5280 Jun  1 16:24 cports
brw-rw----. 2 root   disk     251, 1 Jun  2 22:42 EXDPMACFS4GG_exdpm01-cluster1_acfs_vol0129_5fc191c5babc44d88894251848e1eaa0

The device name matches the deviceName shown above in the volume attachment, confirming that the Exascale volume has been attached and presented to the VM cluster operating system.

For additional detail, the volume itself can be inspected using escli:

$ escli --wallet $OSSCONF/security/admwallet/ lsvolume vol0129_5fc191c5babc44d88894251848e1eaa0 --detail

id                                   vol0129_5fc191c5babc44d88894251848e1eaa0
name                                 EXDPMACFS4GG_exdpm01-cluster1_acfs
acfsFileSystem                       acfs0001_1851f7a6a67c43d2b5a3eae91e0c2f1f
contentType                          DATA
creationTime                         2026-06-02T22:41:57-07:00
filePath                             @exdpm01-cluster1vault/vol.12d5fd105f0e4f28a893394a50494ccb
iopsProvisioned                      unlimited
log                                  false
mediaType                            HC
numAttachments                       1
owners                               admin
redundancy                           high
size                                 100G
state                                AVAILABLE
vault                                @exdpm01-cluster1vault

Verifying the ACFS Filesystem in Oracle Clusterware

Once the volume was created and attached, OEDACLI registered the ACFS filesystem with Oracle Clusterware. This ensures that the filesystem is managed as a cluster resource and mounted consistently across the VM cluster.

The filesystem configuration can be viewed using srvctl:

$  srvctl config filesystem

Volume device: /dev/exc/EXDPMACFS4GG_exdpm01-cluster1_acfs_vol0129_5fc191c5babc44d88894251848e1eaa0
Canonical volume device: /dev/exc/EXDPMACFS4GG_exdpm01-cluster1_acfs_vol0129_5fc191c5babc44d88894251848e1eaa0
Accelerator volume devices:
Mountpoint path: /acfs4gg
Mount point owner: root
Mount point group: root
Mount permissions: owner:root:rwx,pgrp:root:r-x,other::r-x
Mount users: oracle
Type: ACFS
Mount options:
Description:
ACFS file system is enabled
ACFS file system is individually enabled on nodes:
ACFS file system is individually disabled on nodes:

Verifying the Mounted Filesystem

Last, we’ll check that the filesystem is mounted and available for use on the VM cluster.

Using mount, we can see that the Exascale volume is mounted as an ACFS filesystem at /acfs4gg:

mount | grep acfs4gg

/dev/exc/EXDPMACFS4GG_exdpm01-cluster1_acfs_vol0129_5fc191c5babc44d88894251848e1eaa0 on /acfs4gg type acfs (rw,relatime,seclabel,device,ordered)

Using df, we can verify the capacity and available space:

df -h /acfs4gg

Filesystem                                                                         Size  Used Avail Use% Mounted on
/dev/exc/EXDPMACFS4GG_exdpm01-cluster1_acfs_vol0129_5fc191c5babc44d88894251848e1eaa0  100G  816M  100G   1% /acfs4gg

At this point, the filesystem is fully provisioned, attached, registered with Oracle Clusterware, mounted on the VM cluster, and ready for use.

That’s all there is to it!

As you can see, it’s very easy to add an ACFS filesystem to an existing VM Cluster using an Exascale volume. A single OEDACLI command provisions the Exascale volume, creates the required volume attachment, presents the device to the VM cluster, registers the filesystem with Oracle Clusterware, and mounts the ACFS filesystem across the cluster.

The result is a fully managed shared filesystem that combines the simplicity of ACFS with the flexibility and scalability of Exascale storage. From the initial OEDACLI command through Exascale volume provisioning, device presentation, Clusterware registration, and filesystem mount, the entire lifecycle is orchestrated as part of the Exadata management framework.