DeepSeek/3FS
1
0
Fork 0
mirror of https://github.com/deepseek-ai/3FS synced 2025-06-03 19:36:20 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

fix(typo) (#16)

Browse Source 
Co-authored-by: zhaohaiyuan <zhaohaiyuan@meituan.com>
This commit is contained in:
zhaohaidao 2025-02-28 22:49:00 +08:00 committed by GitHub
parent d19d90f9f9
commit c4de026123
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
docs/design_notes.md
View File

@ -52,7 +52,7 @@ Within the native client, multiple threads are spawned to fetch I/O requests fro
### Location of file chunks
3FS divides file data into equally sized chunks and stripes them across multiple replication chains (replication chains and chain tables are defined in Section [Data placement](#data-placement). Users can specify the chain table, chunk size, and stripe size for files on a per-directory basis. Each chunk is independently stored on multiple storage services, with its chunk ID generated by concatenating the file’s inode id and chunk index.
3FS divides file data into equally sized chunks and stripes them across multiple replication chains (replication chains and chain tables are defined in Section [Data placement](#data-placement)). Users can specify the chain table, chunk size, and stripe size for files on a per-directory basis. Each chunk is independently stored on multiple storage services, with its chunk ID generated by concatenating the file’s inode id and chunk index.
When creating a new file, the metadata service employs a round-robin strategy to select consecutive replication chains from the designated chain table, based on the stripe size. Next, a random seed is generated to shuffle the selected chains. This allocation strategy ensures balanced data distribution across chains and SSDs.
@ -74,7 +74,7 @@ The file system metadata primarily consists of two core structures: inodes and d
Directory entry keys are composed of a "DENT" prefix, the parent inode ID, and the entry name. Directory entry values store the target inode id and inode type. All entries within a directory naturally form a contiguous key range, allowing efficient directory listing via range queries.
The meta operations leverages FoundationDB’s transactions:
The meta operations leverage FoundationDB’s transactions:
- Read-only transactions used for metadata queries: fstat, lookup, listdir etc.
@ -206,7 +206,7 @@ A storage target can change from one public state to another in response to the
- If a storage service finds public state of any local storage target is lastsrv or offline, it exits immediately. The service may be isolated from the cluster manager by network partition error.
- Once the date recovery of a storage target in syncing state is completed, the storage service set the target’s local state to up-to-date in subsequent heartbeat messages sent to cluster manager.
- Once the data recovery of a storage target in syncing state is completed, the storage service set the target’s local state to up-to-date in subsequent heartbeat messages sent to cluster manager.
| Local State | Current Public State | Predecessor’s Public State | Next Public State |
| :---------- | :------------------- | :------------------------- | :---------------- |
@ -253,7 +253,7 @@ When a storage service finds a previously offline successor is online:
- The chunk lock is first acquired for each chunk.
- The chain version, commited version number and chunk content are read and transferred to successor by sending a full-chunk-replace request.
- The chain version, committed version number and chunk content are read and transferred to successor by sending a full-chunk-replace request.
- The chunk lock is released.