引言

弹出报错：ERROR: directory "/data/kes_tbls/business_data" does not exist。那次我在某政务云项目驻场。凌晨两点，被手机告警弄醒了，新数据写不进去。我一查日志：白天运维小哥做存储扩容，把挂载点从/data/kes_tbls改成了/data/kes_tbls_new，虽然后面改回来了，但里面那个business_data子目录没重建。就因为这破事儿，整个系统凉凉。

这种坑我踩的不少。以前用Oracle、MySQL的时候就这样，创建表空间之前，你得先ssh到服务器上，mkdir -p建目录，chown改属主，chmod设权限，一步都不能少。少一步就报错。那时候物理机环境还好，目录建一次就完事儿。我们的系统跑在统信UOS上，存储是分布式ceph，容器化部署，Pod今天在这个节点，明天可能就跑到另一个节点去了。别搞手工建目录了，最优解来了兄弟。

后来项目整体迁移到了金仓的KingbaseES，我发现终于把这个设计给改了，表空间目录能自动创建了。这功能听起来不起眼，但用过的人都知道，这是真省心。今天就想聊聊这个，顺便说说我在统信、麒麟、龙蜥这些国产系统上遇到的一些事儿。

一、问题描述

给友友们说一下，那次故障的细节，当时的环境是这样的：数据库跑在统信UOS 1060版本上，内核是龙蜥的ANCK，存储用的是某国产分布式存储，通过CSI插件挂到K8s里。我们给业务库规划了单独的表空间，路径是/data/kes_tbls/business_data。

白天运维做扩容，思路很简单：把旧目录umount，挂新盘，再mount回来。不理解问题出在了哪？K8s的Pod重启后，如果用的是emptyDir或者某些动态供给的PV，子目录不会自动保留。运维以为mount回来就完事了，结果里面的business_data子目录没了。晚上的时候，业务高峰一来，要创建新表，KingbaseES去找表空间目录，发现路径不存在。我当时看着那个报错，整无语了，为啥当时没写个初始化脚本？

其实这种事儿在项目上特别常见。国产操作系统这几年虽然用得多了，但生态还在完善，很多自动化工具链跟不上。我们习惯了在CentOS上写个Ansible playbook一键搞定，到了统信或者麒麟上，有时候还得手动改。

二、自动创建目录

拿到测试环境的时候，我第一件事就是试这个功能。

以前创建表空间得这么干：

-- 先ssh到服务器
mkdir -p /data/kes_tbls/new_tbs
chown kes:kes /data/kes_tbls/new_tbs
chmod 700 /data/kes_tbls/new_tbs

-- 再进数据库
CREATE TABLESPACE new_tbs LOCATION '/data/kes_tbls/new_tbs';

少一步就报错，权限不对也报错，路径里有空格还是报错（这个最坑了，有些Windows迁移过来的路径带空格，Linux下直接就会懵了）。

现在呢？直接执行：

CREATE TABLESPACE new_tbs LOCATION '/data/kes_tbls/new_tbs';

KingbaseES自己就把目录建好了，权限也设对了。我当时试的时候，特意把父目录/data/kes_tbls的权限设得很奇怪，想看看它能不能处理好。结果不光建了子目录，还自动继承了合理的权限设置。

这种设计才是现在环境需要的。我们的运维团队现在水平参差不齐，有些是刚从Oracle转过来的老DBA，有些是新招的应届生，有了这个，少报了好多错。

三、在国产系统上踩过的坑

接下来博主带着友友们来聊一下国产操作系统。2026年了，统信UOS和麒麟OS在我们这儿已经是标配，但说实话，跟它们打交道比跟CentOS累多了，不是系统不好，是生态还在磨合。

3.1 龙蜥ANCK和欧拉iSula的那些事儿

有次我们在龙蜥操作系统上部署KingbaseES，存储用的是XFS文件系统。按照之前的习惯创建表空间，发现自动创建的目录权限有点问题。查了半天，发现是龙蜥的默认SELinux策略比CentOS严格，数据库进程虽然建了目录，但上下文标签不对，导致后面备份的时候rsync报权限错误。

当时折腾了整整两天，最后发现得在创建表空间之前，先确保父目录的SELinux上下文是对的，或者干脆关掉SELinux（生产环境不建议，但我们测试环境就这么干了）。这事儿让我意识到，自动创建目录虽然省事，但在国产系统上，文件系统的安全策略比国外那些系统复杂得多。

还有欧拉的iSula FS，这是它们容器场景下推的文件系统。我们在欧拉22.03上跑KES容器，用iSula FS做存储后端，发现表空间目录自动创建后，如果容器重启，有时候目录会丢失。后来查文档才知道，iSula FS在某些版本上有路径缓存的问题，得升级内核到特定版本才解决。

3.2 路径大小写和分隔符的坑

还有个特别恶心的问题：路径大小写。

我们有个项目是从Windows Server迁移到统信UOS的。原系统在Windows上，表空间路径是D:\KingbaseES\Data\TableSpace，到了Linux下，按理说应该变成/data/kes_tbls/tablespace。但你知道Windows程序员怎么写的吗？他们用了大写的TABLESPACE，而且在代码里硬编码了反斜杠\。

迁移的时候，我先用工具把数据导出来了，但建表空间的时候，我按Linux习惯用了小写。结果应用连上来就报错，说找不到表空间。我查了半天，发现是应用代码里写死了大写的路径名。Linux是大小写有区别的，Windows不是（。

后来KingbaseES的自动创建目录功能救了我一命——我直接在SQL里写了大写的路径：

CREATE TABLESPACE business LOCATION '/DATA/KES/TABLESPACE';

虽然看着别扭（Linux下全大写路径太反人类了），但它确实能建，而且能正常工作。这让我意识到，在异构迁移场景下，数据库对路径大小写的容忍度很重要。KingbaseES在这方面做得还行，至少不会像某些数据库那样强制转换或者报错。

至于反斜杠\，KingbaseES在Windows和Linux上都做了兼容处理。在Linux下，如果你不小心用了Windows风格的路径，它会自动转换或者报错提示，不会傻乎乎地真的去建一个带反斜杠的目录（虽然Linux下反斜杠是合法字符，但太别扭了）。

四、国产加密文件系统

最后聊聊文件加密，这个可能是很多政务项目关心的。

现在国产操作系统都在推文件级加密，比如统信UOS有自带的保险箱功能，麒麟也有类似的国密加密文件系统。我们有个涉密项目，要求数据文件必须加密存储，防物理窃取。

传统的做法是买第三方加密软件，或者用LUKS整盘加密。但整盘加密性能损耗大，而且密钥管理麻烦。后来我们发现，如果用国产OS自带的文件级加密，配合KingbaseES的表空间管理，可以实现更细粒度的控制。

具体来说，我们在统信UOS上启用了文件加密，然后创建表空间的时候，利用自动创建目录功能，确保目录属主是数据库用户（通常是kes或者kingbase）。这里有一个点要大家注意：目录的属主必须对加密文件系统有访问权限。

当时我们踩过一个坑：用root用户提前建了加密目录，然后改成kes属主，但加密文件系统的密钥链是跟着用户走的，root建的目录，kes用户虽然能访问文件内容，但在某些操作（比如表空间删除）时会报权限不足。后来我们干脆不提前建了，让KingbaseES用kes用户自动创建，这样目录从诞生起就带着正确的属主和加密上下文。

另外，关于文档里提到的"目录属主"问题，在国产加密环境下尤其敏感。因为加密文件系统通常要求目录的属主必须是实际访问者，不能是简单的root改权限。KingbaseES自动创建目录时，用的是数据库进程的euid（通常是安装时指定的用户），正好也符合了国产加密文件系统的要求。

五、结语

说实话，写这篇博客的时候，我还在想：就一个"自动建目录"的小功能，值得写这么多吗？

但转念一想，信创替代走到今天，大家关注的都是大架构、大生态，什么分布式、云原生、一云多芯。但真到了干活的时候，卡住我们的往往是这种小事儿上。一个目录没建，能让整个系统凌晨两点宕机；一个路径大小写不对，能让迁移项目延期一周。KingbaseES这个功能，看似只是省了几行shell脚本，但实际上它代表了国产数据库在"易用性"和"信创适配"上的进步。这个自动建目录让我们不用再担心哪个新手DBA忘了建目录，也不用担心国产文件系统的权限陷阱。感兴趣的友友们可以了解使用一下这个小功能哈。