删掉一张大表后，磁盘空间为什么没有立刻释放？是什么原理？

【 使用环境 】测试环境
【 OB 】
【 使用版本 】
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

根据您的描述，可能是删除大表后的磁盘空间没有立即释放，这在数据库中是一个常见的现象，因为数据库系统通常不会立即将释放的空间返还给操作系统，而是将其标记为空闲空间供后续操作使用。推荐使用 obdiag 工具进行日志采集，以便确认具体的原因。

日志采集场景: 内存问题
日志采集命令: obdiag gather scene run --scene=observer.memory

另外，为了更准确地定位问题，请您提供以下信息：

1. 删除表的操作时间及表名
2. 当前系统的磁盘使用情况，可以使用 df -h 命令查看
3. 是否进行了任何手动的空间回收操作，例如使用 TRUNCATE TABLE 或 OPTIMIZE TABLE 等命令
4. 当前 OceanBase 版本及配置参数，特别是与存储相关的配置
5. 操作系统类型及版本

请您先执行上述日志采集命令，然后将生成的日志文件提供给我们，我们会根据这些信息进一步分析问题的原因。感谢您的配合！

附上敏捷诊断工具 obdiag 使用帮助链接

不会释放空间，ob的空间是预占用的

删大表只是逻辑删除做标记，OB 靠后台自动清理垃圾数据，为了稳集群、防误删、控 IO，磁盘空间没办法立马空出来的

删除表后，由于是LSM-tree结构，只是标记为删除状态，数据还在吧

OceanBase 数据库后台存在一个 GC 线程，每隔 10s 会对本机所有分区进行一次遍历，判断哪些需要被回收，并对这些资源执行删除操作。判断 partition 是否可以删除的依据，主要通过检查 member_list、schema 以及副本状态等方式来实现。
DROP TABLE 语句：当 GC 线程检查前置条件，如果当前分区的 schema 已经被删除，就会执行如下流程。

• 对于 leader 副本：
  1. 写 offline 日志（liboblog 依赖 offline 日志来确认日志已经同步），并同步给备机。
  2. 等待 schema 删除超过 30 分钟。
  3. 等待 offline 日志在多数派上写成功（检查多数派的 ilog）。
  4. 从 __all_tenant_gc_partition_info 表中删除该行。
  5. 删除分区。