Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: curvefs space design #959

Merged
merged 1 commit into from
Dec 7, 2022

Conversation

wu-hanqing
Copy link
Contributor

introduce curvefs space design

@wu-hanqing wu-hanqing self-assigned this Jan 10, 2022

## 后续版本需要解决的问题

- [ ] 空间分配信息如何重建
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

这个是指故障恢复场景下的重建吗?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

是的,包括升级重启也需要


之前剩余的 30MiB ~ 2MiB 的 extent 完全分配出去,所以从 level2 中的 list 中删除。

文件 inode 中的 extent 可以将两次的申请结果进行合并,得到(0,28MiB,4MiB)。
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

合并extent逻辑是在更新space信息的时候同步做的还是后台异步做的?


为了避免整个问题,可以将整个空间,由多个分配器来进行管理,每个分配器管理不同的地址空间。比如,将整个空间划分为 10 组,每组空间都有一个空间分配器进行管理。

在申请空间时,如果没有附带期望地址空间的 offset,则随机选取一个分配器进行空间分配。如果附带了期望的 offset,则由对应的分配器进行处理。
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

如果对应offset的分配器进程异常怎么处理?降级到没有指定offset的逻辑?什么时候恢复正常的逻辑?等进程启动?另外如果要扩容bs卷,或者继续细分地址空间怎么处理?


在线扩容时,直接在新扩容的空间上,创建新的空间分配器进行空间管理。

文件系统重新加载时,再将所有的空间,按照上述的策略,进行分组管理。
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

文件系统重新加载是指?

- [ ] 空间分配信息如何重建
- [ ] 高可用
- [ ] 幂等请求处理
- [ ] PB 级别情况下的性能
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

其实我一直有个疑问,我们bs卷要支持单卷PB级容量,是否需要做一些改动?或者说优化?
目前云盘场景下,单卷都是TB级别。如何验证单卷支持PB级别甚至几十PB都是没问题的?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

或者说,我们是否要支持单个fs对应多个bs卷?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

另外是否可以考虑下,当前的设计方案最有可能成为性能瓶颈的点在哪?也列一些,为方案实现做参考,预埋一些metric或者写代码的时候可以多留点冗余?

@aspirer aspirer added the nocitest Modifications such as documents do not require CI testing label Jan 10, 2022
@opencurveadmin opencurveadmin merged commit 0025942 into opencurve:fs Dec 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
nocitest Modifications such as documents do not require CI testing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants