fix(typo) (#16)

Co-authored-by: zhaohaiyuan <[email protected]>

docs/design_notes.md

@@ -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.