wal_ttl绝对不能改成0，clean_wal_interval_secs这个改成0我不知道会发生什么。那些wal只会在你大量导数据的过程中占据一定空间，可以稍微改小点。wal日志是存储层会使用的，任何时候都应该有wal。
好的，我把这两个改小点试试。
你现在这个集群我甚至不清楚改成正常值能否恢复了，不排除需要重新导数据。
嗯，我把数据都清了重启下试试，先把配置改成1s试试。
个人建议wal_ttl至少也在600以上，clean_wal_interval_secs这个倒问题不大，60应该可以。
600太大了，我们这对磁盘要求太苛刻了，现在是想尽办法缩减磁盘空间，我先改成1s试试吧，如果还data目录还是一直增长再改大了试试。
storage启动的时候最好检查一下重要的配置值
我把wal_ttl和clean_wal_interval_secs都改成了1，data/storage/nebula/xxx/data/LOG文件还是一直在刷下面的内容，但是刷的频率变慢了，变成了1s刷一次了，但是sst文件数量还是一直在增加，增加的也慢了，这些现象和上面的那两个配置有关吗？
还有个问题想问下，在submit job compact手动compact的过程中，会在新的sst文件都生成完成后再删除老的sst文件，这就意味着磁盘占用在手动compact这个过程中会加倍。
所以，这个有配置可以一边生成新的sst一边删除老的sst吗？
说了不能这么开车，一定要这么开没啥意义吧。
嗯，已经按照critical27说的改成600了，但是还是有个疑问，rocksdb每次flush都会新生成几个新的sst文件吗，虽然我没有入库新数据
我印象rocksdb_disable_wal这个是true才会flush
我看nebula-storage.conf配置文件中这项配置是true
–rocksdb_disable_wal=true
你要不想flush就改成false
好的，我改成false试试，改成false对nebula有什么额外影响吗？
不会写rocksdb的wal
你好，我把–rocksdb_disable_wal改成了false，确实没有flush行为了，但是wal目录的大小似乎不受wal_ttl和clean_wal_interval_secs这两个选项的控制了。
如果这两个选项失效的话，还有其他的选项可以在rocksdb_disable_wal为false时控制wal目录吗？