doc: add space manage of curvefs with volume backend

Signed-off-by: ilixiaocui <[email protected]>

docs/cn/Curve文件系统Volume后端空间管理.md

@@ -0,0 +1,65 @@
+
+# Curve文件系统Volume后端空间管理
+
+## 背景
+
+Curve文件系统使用Curve块存储作为后端，空间管理相关的文档有：[curvefs_volume_space_design](https://github.com/opencurve/curve/blob/master/docs/cn/curvefs_volume_space_design.md) 和 [curvefs_volume_space_deallocate](https://github.com/opencurve/curve/blob/master/docs/cn/curvefs_volume_space_deallocate.md)。
+
+当前空间回收功能还有缺失，本文主要梳理下空间回收部分涉及到的开发任务。首先总体介绍一下当前对接Curve块存储（Volume）作为后端的管理策略。
+
+![](../images/volume-space.png)
+
+1. 文件系统上的一个文件和```Volume```空间上的映射关系。
+
+    - 一个文件```File```占用的地址空间可以用多个不等长的```VolumeExtent``` 表示
+    - ```VolumeExtent``` 包含了 ```{fsOffset, volumeOffset, length, isused}``` 信息
+    - 根据这些信息可以知道文件数据片段在 ```Volume``` 上的位置信息
+
+2. ```Volume```的空间管理。
+
+    - ```Volume```的空间有多个等长的 ```BlockGoup```组成
+    - 每个 ```BlockGroup``` 的头部空间使用bitmap记录当前 ```BlockGroup``` 指定粒度的分配情况
+    - ```BlockGroup``` 包含的信息 ```{offset, size, used, available, blocksize, bitmap, owner}```
+    - 根据这些信息，可以知道 ```Volume``` 的空间当前被使用的情况。
+    - **空间分配：** 文件写入数据的时候需要分配空间
+    - **空间回收：**
+
+        - 触发条件1文件删除。在Curve文件系统中，```inode``` 的 ```nlink``` 为0，可以被后台异步清理
+        - 触发条件2文件系统删除。在Curve文件系统中，文件系统和 ```volume```的关系是一对一的，文件系统删除需要删除对应的 ```Volume```
+        - 触发条件3Truncate。需要清理新的 ```length``` 以外的空间。
+
+## 空间回收
+
+Curve文件系统中:
+- **文件的写入需要分配空间**，因此 ```Client``` 需要对 ```BlockGroup``` 进行操作以分配空间。
+- **文件的删除需要清理空间**，元数据是在 ```Metaserver``` 管理的，因此 ```Metaserver``` 需要对 ```BlockGroup``` 进行操作以回收空间。
+
+当前空间回收流程如下：
+
+1. ```Client``` 收到用户删除文件的请求 （空间回收的触发条件1）并处理
+
+    - 如果配置了回收站，则把文件放到回收站中（相当于rename的操作)
+    - 如果没有配置回收站，则直接调用删除Inode的请求
+
+2. ```Metaserver``` 处理用户删除文件的请求
+
+    - 如果是配置了回收站，文件进入回收站（延迟删除），等待超时时间后递交给空间回收模块
+    - 如果没有配置回收站，直接递交给空间回收模块
+
+3. ```Metaserver``` 进行空间回收。遍历 inode 中的 ```VolumeExtent```
+
+    - 获取 ```VolumeExtent``` 对应的 ```Volume``` 空间的 ```BlockGroup```
+    - 清理对应 ```BlockGroup``` 上的 bitmap信息
+    - 更新 Inode
+
+以下为空间回收的流程图，其中红色表示已经开发完成；绿色表示逻辑完成单元测试未完成；蓝色表示单元测试和逻辑都未完成。
+
+![](../images/deallocate-space-process.png)
+
+当前的遗留问题：
+
+1. trucate操作未处理
+
+2. 先清理 bitmap，再更新 Inode，清理中断（比如 Metaserver 重启）后这部分空间如何处理？当前是清理之前标记 Inode 为 ```deleting``` 状态，重启后 ```deleting``` 状态的 Inode 空间不再被清理，因为这部分空间有可能又被重新分配了。**遗留问题：** 会有部分 Inode 的空间回收状态不清楚，可能需要通过 fscheck 等方式清理。
+
+3. 关于清理粒度。```VolumeExtent``` 是有可能跨 ```BlockGroup``` 的。如果```BlockGroup``` 当前正在 ```Client``` 端使用，```Metaserver``` 什么时候能获取到进行清理？