EDA 存储目录行业标准设计（第二轮补充）¶

依据：对 /data（NFS Server）、/lustre/eda_fs（Lustre）、3 个计算节点的实测结果目的：把现有目录与 EDA 行业标准对齐，并补齐缺失的"本地 SSD scratch"层

一、EDA 行业标准的存储分层与目录体系¶

真实 EDA 企业（芯片设计公司）的标准布局如下，不同公司命名不同，但分层语义一致：

1.1 Tier1 —— 共享 NAS（NFS），只读为主 + 项目读写¶

/eda/apps/<vendor>/<tool>/<version>/     # 工具安装，只读，多版本并存
/eda/modulefiles/<tool>/<version>.lua    # Lmod 环境模块（与安装目录解耦）
/eda/pdk/<foundry>/<process>/            # 工艺库 PDK，只读
/eda/libs/<toolchain>/<version>/         # 编译器/MPI/基础依赖
/eda/license/                            # license 文件与启动脚本（服务在独立节点）
/home/<user>/                            # 用户家目录
/projects/<project>/{rtl,sim,syn,pnr,signoff,doc}   # 项目工作区

核心规则：vendor → tool → version 三级目录；工具/PDK 只读；多版本并存用 module 切换。

1.2 Tier0 —— 并行文件系统（Lustre），仅放临时数据¶

/scratch/
├── users/<user>/<jobid>/     # 用户作业临时
├── projects/<project>/       # 项目级共享临时
└── tmp/                      # 全局可写（1777 粘滞位）

核心规则：只放临时数据；不放工具、不放 license、不放源数据；按 mtime 定期清理。

1.3 本地节点层 —— 本地 SSD/NVMe scratch（性能层）¶

/local_scratch/
└── users/<user>/<jobid>/     # 作业运行目录 / $TMPDIR

核心规则：节点私有、易失、不备份；作业结束由 epilog 清理；是 EDA 性能最敏感的一层。

二、你的现有结构（实测）¶

2.1 NFS Server `/data`¶

/data/
├── slurm/                     ★ 集群主目录（体系较完整）
│   ├── eda_pak/               # 软件介质/包
│   │   ├── Cadence/  Keysight/  Synopsys/  PDK/
│   │   └── FlexLM/            # license 工具（lmgrd/lmutil）
│   ├── opt/                   ★ 实际安装目录
│   │   ├── Ads2025/  Cadence/  Mentor/        # 工具
│   │   ├── pdk/               # PDK 实际目录
│   │   ├── License/           # license 目录
│   │   └── libevent-2.1.12/  openmpi-4.1.5/  pmix-4.2.6/   # 基础依赖
│   ├── modules/               ★ Lmod modulefiles（.lua）
│   │   ├── Cadence/IC617.lua   spectre/151.lua
│   │   ├── Keysight/Ads/2025.lua
│   │   ├── gcc/{7.5.0,12.1.0}.lua   openmpi/4.1.5.lua
│   │   ├── global_env/slurm_env.lua   bio/   python/
│   ├── tools/                 # 运维脚本（slurm_ldap_sync.sh / slurm_license_sync.sh 等）
│   ├── users/                 # 用户工作区（rain01/rain03/cy01/cloud01/lws01）
│   ├── pak/                   # 源码包/构建包（gcc/mpi/slurm2108/vina/zip）
│   └── logs/                  # license_sync.log
├── k8s-config/  sc-nfs/  softdata/   # k8s 相关（独立体系）
├── lsf/  Script/  tools/(.pyenv)

已配置：MODULEPATH=/mnt/nfs/slurm/modules（= /data/slurm/modules），Lmod 8.7.60 已就位，计算节点可用 module load。

2.2 Lustre `/lustre/eda_fs`（基本为空）¶

/lustre/eda_fs/
├── license/     (空)      ← 不应在 Lustre
├── tools/       (空)      ← 不应在 Lustre
├── workspace/   (空)      ← 应规范为 scratch
├── lsf_log/     (在用)    # LSF 日志
├── slurm_demo/  (演示数据)
└── test_recovery_20260803_023940   (0 字节测试残留)

已用仅 5.25 MB / 293 个文件，完全是空白状态——正好可以从零按标准规划。

2.3 计算节点（3 台：k8s-node-01/02/03 = .5/.6/.7）¶

三台结构完全一致：单块 vda 100G → vda1(/boot 1G) + vda2(19G) + vda3(80G)，合并为一个 LVM 根 / 97G（已用 22~27G）。 结论：没有任何独立数据盘，本地 scratch 必须新增虚拟盘。

三、对照分析：你的现有 vs 行业标准¶

标准职责	行业标准	你现有	判断	建议
工具安装	`apps/<vendor>/<tool>/<ver>`	`opt/`	语义符合，命名可优化	可保留 `opt`，或用 `apps` 软链兼容
软件介质	（不要求）	`eda_pak/`	好习惯（介质与运行分离）	保留，建议更名 `packages`
modulefiles	`modulefiles/`	`modules/`	✓ 符合，MODULEPATH 已指向	保留
PDK	`pdk/`（单一源）	`opt/pdk` + `eda_pak/PDK`	⚠ 两处	收敛为单一只读源
License	`license/`（单一源）	`opt/License` + `eda_pak/FlexLM` + `Lustre/license`	⚠ 三处	收敛为一处，服务独立
基础依赖	`libs/`	混在 `opt/`	混杂	独立 `libs/` 或明确标注
用户家目录	`/home`	`/home` + `slurm/users`	⚠ 两套	明确分工
项目工作区	`/projects`	无	✘ 缺	新建
Tier0 Scratch	Lustre `/scratch`	Lustre `workspace`(空)	✘ 未规范	重整为 `scratch/`
本地 scratch	`/local_scratch`	无	✘ 缺	3 节点新增

总评：你的 Tier1（NFS 工具/module/用户）已完成约 70%，主要问题是 PDK/License 多处分散、缺项目区、Tier0 与本地层未建。

四、目标态设计¶

4.1 Tier1（NFS）—— 增量收敛，不推翻现有¶

/data/slurm/
├── opt/                # 保留（工具安装，只读导出）
├── modules/            # 保留（MODULEPATH 不动）
├── eda_pak/            # 保留（介质仓库）
├── users/              # 保留（用户/项目共享区）
├── tools/  pak/  logs/ # 保留
└── eda/                # ★ 新增：标准收敛区
    ├── pdk/            # PDK 单一只读源（从两处收敛）
    ├── license/        # license 单一源
    └── projects/       # ★ 项目工作区（替代缺失的 /projects）

原则：只做增量 + 软链，不搬迁现有数据，避免破坏正在使用的 modulefile 路径。

4.2 Tier0（Lustre）—— 重整为纯 scratch¶

/lustre/eda_fs/
├── scratch/
│   ├── users/          # 用户作业临时
│   ├── projects/       # 项目级临时
│   └── tmp/            # 1777
└── logs/{lsf,slurm}/   # 日志归档（lsf_log 归位）

动作：workspace/ → 并入 scratch/；tools/、license/ 空目录移除（职责归 NFS）；清理 0 字节测试残留。

4.3 本地层（3 个计算节点）—— 新增本地 SSD scratch¶

节点	新增盘	挂载点	文件系统/选项	建议容量
k8s-node-01	vdb	`/local_scratch`	xfs, noatime	50G
k8s-node-02	vdb	`/local_scratch`	xfs, noatime	50G
k8s-node-03	vdb	`/local_scratch`	xfs, noatime	50G

作业集成（/etc/profile.d/eda_scratch.sh）：

export LOCAL_SCRATCH=/local_scratch/users/$USER
export TMPDIR=$LOCAL_SCRATCH/${SLURM_JOBID:-$$}

五、30G 够不够？—— 容量评估¶

scratch 是易失的，容量按并发作业峰值估，不按累积。

场景	单作业 scratch 峰值	30G 可支撑
Spectre/Virtuoso 小电路仿真	0.3 ~ 2 GB	十余个并发（远超需要）
Spectre 大电路 / 后仿	5 ~ 20 GB	1 ~ 5 个并发
VCS 带 fsdb 波形	2 ~ 20 GB	1 ~ 10 个并发
ADS EM 仿真	1 ~ 10 GB	3 ~ 15 个并发
真实生产节点	—	1 ~ 4 TB NVMe/节点

结论： - 30G 用于"学会机制、跑小电路"完全够用； - 但它只相当于真实环境（1~4TB）的 1% 量级，是"迷你版"； - 推荐 50G：给 VCS 波形/后仿留余量，且虚拟盘成本极低，可随时扩容； - 硬性要求：必须用独立虚拟盘，不要放根分区（根分区已用 22~27G/97G，且与 OS 争 IO，起不到隔离作用）。

虚拟盘创建（演示，在 KVM host `dell-r620` 执行）¶

qemu-img create -f qcow2 /var/lib/libvirt/images/k8s-node-01-scratch.qcow2 50G
virsh attach-disk k8s-node-01 /var/lib/libvirt/images/k8s-node-01-scratch.qcow2 vdb --persistent

节点内（幂等脚本处理）：

mkfs.xfs /dev/vdb
# fstab: /dev/vdb  /local_scratch  xfs  defaults,noatime  0 0

六、脚本扩展点（已实现，dry-run 通过）¶

在现有 deploy/ 工程上增量扩展，遵循 BaseDeployer 幂等框架：

新增分类	动作	幂等判定
`local_scratch_fs`	检测 `/dev/vdb` 是否已格式化并挂载	已挂载即跳过
`local_scratch_dir`	创建 `/local_scratch/users` + 权限	目录存在即跳过
`local_scratch_env`	下发 `/etc/profile.d/eda_scratch.sh`	文件 SHA256 比对
`tier0_scratch`	重整 Lustre scratch 目录树	目录存在即跳过
`tier1_dir`（扩展）	新增 `eda/{pdk,license,projects}`	目录存在即跳过
`tier1_link`	软链收敛 PDK/license	链接已存在且指向正确即跳过

七、决策结论（已确认并落地进脚本）¶

#	决策点	结论
1	本地 scratch 容量	50G/节点（3 台计算节点）
2	本地盘创建方式	KVM 附加独立虚拟盘（dell-r620，`/kvm/qcow2/`）
3	Tier1 目录策略	增量 + 软链收敛（不搬迁现有数据，零破坏）
4	Lustre 整理	重整为纯 scratch（含移除空目录与测试残留）

对应实现（第二轮 dry-run 实测：共 68 项）¶

分类	数量	说明
`local_scratch_fs`	0（待加盘）	`/dev/vdb` 未附加，脚本正确提示并跳过
`local_scratch_mount/dir/env`	0（待加盘）	加盘后自动出现
`tier1_eda_root` / `tier1_eda_dir`	2	`/data/slurm/eda` + `eda/projects(2775 eda_dev)`
`tier1_link`	2	`eda/pdk → opt/pdk`、`eda/license → opt/License`
`tier0_cleanup`	3	空 `tools/`、空 `license/`、0 字节测试残留

加盘后本地 scratch 会新增：每节点 local_scratch_fs(mkfs) + local_scratch_mount + local_scratch_dir + local_scratch_env = 4 项 × 3 节点 = 12 项。

执行顺序（关键）¶

先在 KVM host 为 3 台计算节点附加 50G 虚拟盘（见 SOP 附录）
再运行 python3 main.py --dry-run 复核
最后真实执行（脚本自动格式化 → 挂载 → 建目录 → 下发环境变量）

八、最终落地结果（第三轮：工具/PDK 物理迁移）¶

决策：物理迁移（彻底标准）+ modulefile 改标准路径 /tools、/pdk。

8.1 最终标准布局（客户端统一视图）¶

/data/eda/                                   ← Tier1 唯一标准根（NFS 导出）
├── tools/                                    只读 → 客户端 /tools
│   ├── cadence/{IC617, MMSIM151}              ← 原 opt/Cadence
│   ├── keysight/ADS2025                       ← 原 opt/Ads2025
│   └── mentor                                 ← 原 opt/Mentor
├── pdk/                                      只读 → 客户端 /pdk
│   └── {FreePDK45, smic18, smic65, TSMC_013, tsmc18, TSMC_18rf, ncsu-cdk-*…}
└── projects/                                 读写 → 客户端 /projects

8.2 迁移明细（同一文件系统 mv，秒级）¶

原位置	新位置
`/data/slurm/opt/Cadence`	`/data/eda/tools/cadence`
`/data/slurm/opt/Ads2025`	`/data/eda/tools/keysight/ADS2025`
`/data/slurm/opt/Mentor`	`/data/eda/tools/mentor`
`/data/slurm/opt/pdk/*`（11 项）	`/data/eda/pdk/*`
`/data/slurm/eda`	删除（冗余收敛区）
`/data/slurm/opt/pdk`	删除（迁移后空目录）

8.3 modulefile 改写为标准路径¶

文件	变更
`modules/Cadence/IC617.lua`	`/mnt/nfs/slurm/opt/Cadence` → `/tools/cadence`；`pdkhome` → `/`
`modules/spectre/151.lua`	→ `/tools/cadence`
`modules/Keysight/Ads/2025.lua`	→ `/tools/keysight/ADS2025`

8.4 验证结果（实测）¶

module load Cadence/IC617 → CADHOME=/tools/cadence, CDS=/tools/cadence/IC617
  virtuoso 可执行 OK；CDK_DIR=/pdk/ncsu-cdk-1.6.0 存在 OK；CDS_LIC_FILE=27001@192.168.0.3
module load spectre/151 → MMSIMHOME=/tools/cadence/MMSIM151 存在 OK
module load Keysight/Ads/2025 → HPEESOF_DIR=/tools/keysight/ADS2025 存在 OK
客户端: ls /tools → cadence keysight mentor ;  ls /pdk → 各工艺库
幂等复验: 待变更 0 项（零变更、全跳过）

8.5 License 结论（行业标准已满足）¶

license 采用 FlexLM 服务模式（27001@192.168.0.3、27009@192.168.0.2），客户端仅配环境变量、 不挂载 license 目录 —— 这本身就是行业标准做法，无需变更。

九、第四轮：License Server 本地化 + 权限标准化 + 三级版本化¶

9.1 License Server 本地化（彻底标准）¶

k8s-master-02 (192.168.0.3)             专职 FlexLM License Server
/opt/flexlm/                             本地目录（700，不依赖 NFS）
├── bin/{lmgrd, lmutil}
├── licenses/mixed.dat                   vendor daemon 路径已修正为标准路径
└── logs/flexlm.log
systemd: flexlm.service（Type=forking，开机自启，ExecStopPost 自动清理残留 daemon）

vendor daemon：cdslmd(27001) / mgcld(1717) / agileesofd(27009)，全部 UP 验证通过。 修正的真实错误：ADS modulefile 的 ADS_LICENSE_FILE 原指向 192.168.0.2（那里无服务）→ 已修正为 .3。

9.2 权限标准化（只读 + 最小权限）¶

路径	权限	属主
`/data/eda/tools`、`/data/eda/pdk`	目录 755 / 文件 `u=rwX,go=rX`	root:root
`/data/slurm/modules`	目录 755 / 文件 644	root:root
`/data/eda/projects`	2775（setgid）	eda_dev:eda_dev
> 修复前 `/data/slurm/modules` 为 777（任何用户可改 modulefile 注入代码），风险最高。

9.3 工具/PDK 三级版本化¶

/tools/cadence/virtuoso/IC617
/tools/cadence/spectre/MMSIM151
/tools/keysight/ads/2025
/tools/mentor/calibre/2015.2

/pdk/ncsu/cdk/{1.5.1, 1.6.0→1.6.0.beta}   /pdk/ncsu/freepdk45
/pdk/smic/{180nm, 65nm, 130nm_mmrf}
/pdk/tsmc/{130nm, 180nm, 180nm_rf}

9.4 验证结果（实测）¶

幂等复验: 待变更 0 项（零变更、全跳过）
License : flexlm active；cdslmd UP / mgcld UP / agileesofd UP
module load Cadence/IC617 → CADHOME=/tools/cadence, virtuoso OK, CDK_DIR=/pdk/ncsu/cdk/1.6.0 OK, CDS_LIC_FILE=27001@192.168.0.3
module load spectre/151 → MMSIMHOME=/tools/cadence/spectre/MMSIM151 OK
module load Keysight/Ads/2025 → HPEESOF_DIR=/tools/keysight/ads/2025 OK, ADS_LICENSE_FILE=27009@192.168.0.3

十、第五轮：家目录统一 + 项目区与 LDAP 对齐¶

10.1 你的 LDAP 身份体系（实测）¶

dc=rainchen,dc=com
├── ou=dev  → cn=teama (gid 2000)  cn=teama1 (gid 3000)
├── ou=ops  → cn=teamb (gid 4000)  cn=teamb1 (gid 5000)
└── ou=IT   → cn=teamc (gid 6000)  cn=teamc1 (gid 6100)

LDAP 部署：k8s pod openldap-0（namespace server）+ phpldapadmin
同步脚本：/data/slurm/tools/slurm_ldap_sync.sh（ou→Slurm 父账户、cn→子账户、uid→用户关联）

10.2 家目录统一到 /home/¶

项	变更前	变更后
LDAP `homeDirectory`	`/mnt/nfs/slurm/users/<user>`	`/home/<user>`
物理数据	NFS Server `/data/slurm/users/<user>`	NFS Server `/home/<user>`
是否仍在 NFS	✅	✅（`/home` 本身就是 NFS 导出，客户端无需改挂载）

迁移 5 个实际存在的家目录（cloud01/cy01/lws01/rain01/rain03）→ /home；LDAP 8 个用户属性全部批量更新。

10.3 /projects 按 LDAP 小组组织（与身份体系完全对齐）¶

/projects/teama/   2775  root:teama    (gid 2000)
/projects/teama1/  2775  root:teama1   (gid 3000)
/projects/teamb/   2775  root:teamb    (gid 4000)
/projects/teamb1/  2775  root:teamb1   (gid 5000)
/projects/teamc/   2775  root:teamc    (gid 6000)
/projects/teamc1/  2775  root:teamc1   (gid 6100)

10.4 最终效果（实测，客户端视角）¶

$ su - lws01
$ pwd                 → /home/lws01            （家目录，NFS）
$ ls /tools           → cadence keysight mentor （全局只读）
$ touch /projects/teamc/x  → 写入成功            （teamc 组可写，跨组只读）

10.5 技术要点¶

LDAP 修改：pod 内 ldap://localhost + $LDAP_ADMIN_PASSWORD 环境变量（密码不落盘、不硬编码）
客户端缓存：改完 LDAP 需对每台客户端执行 sss_cache -u <user>
NFS Server 未接 LDAP 客户端，故 chown 用数字 GID（客户端会自动显示为组名）

十一、EDA 存储行业标准问答精要（多轮咨询汇总）¶

11.1 分层判据：按"是否需共享"分，不是按节点数¶

层	承载	判据
本地 SSD	节点私有临时（`$TMPDIR`、编译中间产物）	无需共享、极快、可丢
Lustre	跨节点共享的临时工作层（workdir、大波形、共享数据集）	需要跨节点共享
NFS	持久数据（设计源、最终结果、签核数据）	需要持久、团队共享

多节点作业必须用 Lustre（要共享）
单节点作业也常用 Lustre workdir（调度随机、可异地 debug、stage-out 方便）
本地 SSD 的核心理由：卸载元数据压力（不只是提速）

11.2 三层职责与数据流¶

NFS(Tier1)        只读：/tools /pdk    读写：/projects /home
   │ 读输入
   ▼
Lustre(Tier0)     workdir、编译产物、大波形（stripe -c 3）
   │ stage-out（只回必要数据）
   ▼
NFS(Tier1)        最终结果持久化
本地 SSD           $TMPDIR、节点私有临时（随作业清理）

11.3 缓存层（C 层）为何不做¶

业界"缓存"指对 NFS 的读缓存（NetApp FlexCache / IBM AFM / VAST / Weka）。本项目未实施，原因： 1. Linux 原生 cachefilesd 只缓存内容不缓存元数据，而 EDA 瓶颈正在元数据 2. 真能缓解的是 FlexCache/AFM 等商业方案，学习环境无法复现 3. 已用 A（本地 SSD）+ B（Lustre） 覆盖核心诉求 4. 判定"是否标准"不看有没有缓存（见 11.8）

11.4 元数据风暴：EDA 的第一瓶颈¶

定义：短时间海量文件属性操作（create/stat/open/close/unlink）打满存储的 IOPS
数据 vs 元数据：数据=文件内容（瓶颈是带宽 GB/s）；元数据=文件属性（瓶颈是 IOPS）
EDA 重灾区：编译产生数万小文件、工具启动 stat 海量库文件、并发回归叠加
量化（演示）：一次 VCS 编译 ~5 万文件 × 5~10 次操作 = 25~50 万次元数据操作； 100 并发回归 = 2500~5000 万次；而数据总量可能仅 1 GB
为何比带宽致命：元数据小、随机、有依赖（串行链）、需同步、分布式 FS 有 RPC 往返
缓解手段：① 多 MDT（DNE）② 客户端缓存+批量 RPC ③ 把元数据密集负载赶到本地 SSD（最有效） ④ 减少文件数（工具配置）⑤ 共享编译产物

单 MDT 的 Lustre 元数据能力并不比单台 NFS 强一个量级；靠的是"多 MDT + 缓存 + 分层"。

11.5 为何回写 NFS 而不上云¶

不回写 NFS	不上云
NFS 单点，Lustre 分布式可扩展	IP 保密（一票否决）
元数据风暴（NFS 更易被打爆）	出口管制（数据出境可能违法）
成本错配（贵介质存贱数据）	出云流量费极高（反复读写尤甚）
隔离铁律（临时数据不得影响源数据）	对象存储无 POSIX 语义（EDA 工具不认 S3）
临时数据量 ≫ 持久数据量（常 10:1~50:1）	数据量+网络现实（TB 级/天，上传下载不现实）

归档层 = 私有对象存储（Ceph/MinIO）+ 磁带（LTO），不是公有云。

11.6 三种作业模式（真实环境并存）¶

模式	workdir	临时	特点
A（主流）	Lustre	本地 SSD	可跨节点 debug、调度随机友好
B（性能极致）	本地 SSD	本地 SSD	单节点最快，结束 stage-out；与节点绑定
C（简单）	Lustre	Lustre	小规模；元数据压力全给共享 FS

11.7 临时文件与清理（最容易踩的坑）¶

① $TMPDIR 是通用约定，但 EDA 工具支持不一

工具	中间产物默认位置	可控选项
VCS	`./csrc`、`./simv`（cwd）	`-Mdir=<目录>`、`-o <名>`
Spectre	当前/输出目录	`-raw <目录>` 等
gcc/make	`./*.o`（cwd）	`-o`

关键认知：编译产物默认在"当前工作目录"，不在 $TMPDIR。所以 "Lustre workdir + $TMPDIR=本地SSD" 并没有卸载编译产物的元数据压力（大头仍在 Lustre）。要真卸载：workdir 放本地 SSD，或用 -Mdir 等显式指到本地。

② scratch 生命周期

作业开始 → 创建 scratch/<user>/<jobid>
作业运行 → 中间数据写此处
作业结束 → stage-out 必要文件到 /projects（NFS）
         → 清理该目录（分级：成功可即清，失败保留以便 debug）

③ 临时文件会自己删吗？——不会，必须外部清理（三层）：

# ① 作业脚本自清（最即时）
trap 'rm -rf "$TMPDIR"' EXIT
# ② Slurm Epilog（作业结束自动）
rm -rf /local_scratch/users/$SLURM_JOB_USER/$SLURM_JOB_ID
# ③ cron 老化兜底
find /local_scratch/users -mindepth 2 -maxdepth 2 -type d -mtime +7 -exec rm -rf {} +
find /lustre/eda_fs/scratch -mindepth 3 -maxdepth 3 -type d -mtime +30 -exec rm -rf {} +

tmpfs 是"零清理"替代方案（重启即清），适合小临时文件。

11.8 "是否标准"的最终判定标准（5 条）¶

Tier1 / Tier0 / 本地三层物理分离，IO 特征互不干扰
工具/PDK 只读 + 版本化
License 服务化（不挂载）
客户端有全局统一视图（/tools /pdk /projects /scratch）
临时数据有明确的生命周期与清理机制

本项目前 4 条已达标；第 5 条见下一章（Epilog 缺口）。

十二、Slurm Prolog/Epilog 现状与缺口（2026-09-12 实测）¶

12.1 现有体系（`/usr/local/slurm/etc/slurm.conf`）¶

配置	脚本	作用
`Prolog`	`prolog_eda.sh`	清理 `/tmp` 残片、磁盘/内存检查
`Epilog`	`epilog_eda.sh`	清理 `/tmp`、`/dev/shm`、cgroup
`TaskProlog`	`task_prolog_eda.sh`	注入 `EDA_JOB_ID`/`EDA_JOB_NODELIST`/`EDA_WORKDIR`
`PrologSlurmctld`	`prolog_slurmctld_eda.sh`	集群级预检查（License 检查为注释状态）
`EpilogSlurmctld`	`epilog_slurmctld_eda.sh`	集群级清理（空壳）
`PrologEpilogTimeout`	120	超时保护

12.2 关键缺口（实测 `grep` 确认）¶

（未覆盖 scratch 目录）   ← 现有 Epilog 不清理 /local_scratch 与 /lustre/eda_fs/scratch

❌ 本地 SSD scratch（本项目新增的 A 层）无任何清理→ 50G 会被写满
❌ Lustre scratch（B 层）无老化清理
❌ TaskProlog 未注入 TMPDIR/LOCAL_SCRATCH（现有 EDA_WORKDIR=SLURM_SUBMIT_DIR）

12.3 不同 EDA 场景是否需要不同的 Epilog 逻辑？¶

原则：Epilog 做"通用清理"（基础设施层），场景差异放在"作业脚本"。

层次	职责
Epilog	删作业 scratch 目录（通用、与工具无关）+ 按退出码决定保留/删除
作业脚本	业务级 stage-out 决策（哪些波形/日志回 NFS、哪些丢弃）

可做的"场景感知"（推荐增强）：

# 演示：按作业成败决定保留策略
SCRATCH="/local_scratch/users/${SLURM_JOB_USER}/${SLURM_JOB_ID}"
if [ "${SLURM_JOB_EXIT_CODE:-0}" -eq 0 ]; then
    rm -rf "$SCRATCH"                                   # 成功 → 立即清
else
    mv "$SCRATCH" "${SCRATCH}.failed.$(date +%s)" 2>/dev/null || true   # 失败 → 保留现场，交 cron 老化
fi

其余（工具类型、波形大小）不建议在 Epilog 里做——那属于作业脚本的职责。

12.4 待补强（建议，未实施）¶

epilog_eda.sh 增加 /local_scratch 与 /lustre/eda_fs/scratch 清理（含按退出码分级）
task_prolog_eda.sh 注入 TMPDIR/LOCAL_SCRATCH/WORKDIR（替代用户手工 export）
cron 老化脚本兜底（防异常终止残留）

来源：/home/rain/Documents/slurm/slurm_ins/存储目录行业标准设计.md ｜最后更新：2026-09-12 02:25（由 build/sync.py 同步，请勿在站点侧修改）