Oracle RAC集群里的ACFS（Automatic Storage Management Cluster File System）是一种构建在ASM之上的集群文件系统，允许多个数据库节点同时读写同一份文件。它常被用来存放归档日志、告警文件或者应用共享数据。要在RAC环境中使用ACFS，挂载动作不能像普通Linux文件系统那样只在某一台机器上执行，而是需要借助Clusterware的资源管理，保证所有节点一致可用。
ACFS并不是直接格式化裸盘得到的，它的底层是ASM动态卷（ADVM）。管理员先在ASM磁盘组中用asmca或者命令行创建一个ADVM卷，再在这个卷上建立ACFS文件系统。只有当磁盘组被挂载、ADVM卷被启用之后，ACFS才具备被操作系统识别的前提。很多初次接触的人容易跳过卷状态检查，直接到操作系统层执行mount，这时往往会报设备不存在或者文件系统类型错误。
在RAC环境下，如果只在一个节点手工挂载，其他节点是看不到这个文件系统的，而且集群重启之后手工挂载会全部丢失。正确做法是把ACFS注册为Clusterware管理的资源，由CRS在节点启动或故障时自动处理挂载与卸载。理解这种资源托管机制，是后续所有挂载操作的基础。
挂载前的必要检查
在开始挂载ACFS之前，必须先确认ASM实例和磁盘组的状态。可以通过asmcmd或者sqlplus连接到ASM实例，执行查询看看目标磁盘组是否处于MOUNTED状态。如果磁盘组没有挂载，ADVM卷根本无法启动，上层ACFS也就无从谈起。这一步看似简单，但在多租户或者磁盘维护后的环境中经常被忽略。
接着要确认ADVM卷已经启用。使用asmcmd的volinfo命令能够看到卷的的状态字段，正常应该是ENABLED。若卷被禁用，需要用volenable启用。只有卷启用并且对应设备文件（例如/dev/asm/volume_name-xxx）出现在各节点上，才能继续文件系统层的操作。另外，建议在各节点检查oracle属主对设备文件的访问权限，避免后面mount因权限不足失败。
还需要确认ACFS相关的CRS资源是否已经存在。用crsctl stat res -t可以看到以ora.volume_name.acfs开头的资源，以及ora.datastore挂载点资源。如果这些资源没有注册，说明之前创建文件系统时没有走Clusterware托管流程，后面就只能手工挂载，无法获得高可用能力。
使用srvctl注册并挂载ACFS
Oracle推荐用srvctl来管理ACFS的挂载。假设我们已经有了ADVM卷myvol，并且希望把它挂载到/u01/acfsdata。首先用srvctl add filesystem命令把文件系统加入Clusterware，指定卷设备、挂载点和所属磁盘组。例如：srvctl add filesystem -device /dev/asm/myvol-123 -path /u01/acfsdata -disk_group_data MYDG。这条命令会在OCR里记录文件系统资源，使它能随集群启动。
注册完成后，用srvctl start filesystem -path /u01/acfsdata 即可触发所有节点的挂载动作。Clusterware会先在拥有卷的节点启用ADVM，然后调用操作系统的mount.acfs把文件系统挂到指定目录。因为资源是全局的，所以不需要登录每个节点分别执行。如果某个节点暂时不可用，等它重新加入集群后，CRS会自动补挂，保持一致性。
和手工mount相比，srvctl方式的最大优势是持久化。服务器重启后，Clusterware会根据依赖顺序先起ASM、再起ADVM、最后挂ACFS，不会出现人为漏挂导致数据库找不到目录的问题。对于生产环境，这几乎是唯一稳妥的办法。
手工挂载与自动挂载的对比
在某些排障场景，管理员可能会选择临时手工挂载。做法是先确保卷启用，然后执行mount -t acfs /dev/asm/myvol-123 /u01/acfsdata。这种方式立刻生效，但只影响当前节点，而且重启后消失。如果同时在多个节点手工挂载同一个卷而不经过Clusterware锁管理，还可能引发文件系统损坏。
| 方式 | 作用范围 | 重启后 | 风险点 |
|---|---|---|---|
| srvctl托管挂载 | 全部RAC节点 | 自动恢复 | 依赖资源注册正确 |
| 手工mount | 单一节点 | 丢失 | 多节点并发易损坏 |
从表中可以看出，只要环境是标准RAC，就应该优先采用托管挂载。手工挂载仅建议用于验证卷本身是否可读，验证完应及时卸载，避免和CRS资源冲突。
常见挂载故障与处理
第一类常见问题是挂载时报错说找不到ACFS驱动。这通常是因为系统没有加载oracleacfs内核模块，或者内核版本与Oracle GI不匹配。处理方法是确认GI_home下的acfsroot install已执行，并用lsmod看模块状态。若缺失，需在root下运行acfsload start。
第二类是CRS资源显示INTERMEDIATE或者OFFLINE。多数是磁盘组没起来或者卷被禁用。此时不要强行手工挂载，而是用crsctl检查依赖，先把底层ASM和ADVM理顺。有时还会遇到权限问题，比如oracle用户无法进挂载点目录，这需要确认挂载时是否带了正确的uid和gid参数，或者在文件系统里用chown修正。
第三类是部分节点挂上、部分节点失败。这种情况往往由于节点间设备名不一致，或者/etc/fstab里残留了冲突条目。应清理fstab中有关ACFS的手工记录，统一交给Clusterware管理，并检查各节点的udev规则是否生成了相同的asm设备路径。
日常维护建议
挂载完成之后，建议用df -h和crsctl stat res -t双重确认。前者看操作系统层空间，后者看集群层资源健康度。只有两者都正常，才能认为ACFS真正可用。日常打补丁或升级GI时，要先停止依赖ACFS的数据库，再停文件系统资源，顺序反过来容易导致卸载卡住。
另外，应定期查看ACFS的日志，路径一般在GI的log目录下acfs目录下。通过日志能提前发现卷离线、节点驱逐等隐患。把挂载动作完全交给Clusterware，并且保持各节点软件版本一致，基本可以避免绝大部分RAC中ACFS挂载引发的事故。
Oracle_RACACFS文件系统挂载修改时间：2026-08-12 00:09:42