GBase 8a使用操作系统的文件系统，以目录和文件的形式组织数据。如果操作系统空间满，或者没有写入权限，会报 no space left on device. 但本文记录了排查过程，最终是用户未停服务，直接mv走数据库所有文件造成的。重启服务后，恢复。
目录导航
现象
客户反馈，新安装才2天的集群，还没正式投入使用，出现建表失败，报错为No Space left on device.
排查过程
查看磁盘空间
因为是新安装的，df -h查看没问题， df -i一般也没问题。 如果是用了很久的，已经存在很多表，则也要看下inode是否满了。
检查安装目录权限
看是否gbase目录没有写入权限造成的。
用dbauser，一般是gbase用户，cd 进入数据库安装目录,查看目录属主和权限，是否为gbase:gbase
然后touch一个文件，能否写入。
发现目录权限没问题。
查看目录是否可以写入
可以在目录下mkdir 一个目录，以及touch一个文件。
现场遇到过mkdir报错的场景。create table tmpdb.XXX 报错。
在gncli里执行create table报错
手工在gctmpdb的metadata下创建目录报错。
cannot create directory : Too many links
怀疑是文件系统内部逻辑问题。
查看数据目录权限
查看gnode或者gcluster的userdata目录，看属主和权限是否正常。
未发现异常。
查看umask
遇到过umask为0222的现场，默认都没有写入权限。现场为0002，没有问题。
换个其它DDL试试
尝试创建database成功，在新库下建表，依然失败
查看数据库日志
看有没有更详细的报错信息。
发现，竟然没有任何新的日志。最后的日志输出，是5月29日的，而今天是5月31日。那日志写哪里去了？
再次检查安装目录
发现，用户是通过link的方式，将安装目录/opt/gbase 转到了/data12/gbase下。
但这个Link的时间戳发现了问题，是5月29日18：42分。
对比前面数据库日志的时间，最后启动时间是5月29日18：33分。
也就是说，数据库，有可能是在【没有停服务的情况下，被mv走了所有的数据文件】
询问现场，确实是直接mv，然后做了link,没有停服务。
解决方案
重启数据库服务。恢复正常。
结论
针对建库，GBase 8a里只是创建了一个目录，没有库内进程的缓存，所以可以成功。而建表，需要缓冲一些元数据。
直接将数据目录全部mv走，会导致内存进程正在使用的文件句柄file handler（FD)出现故障，比如日志文件，redolog日志不可用，无法写入而报错。
所以现场如果做数据迁移，要先停数据库服务。