feat：增加思考题

降低思考题权重

Author: tangjiewei0336

docs/lab/lab5.md

@@ -446,8 +446,8 @@ $ make clean
 本次实验的评分标准如下：
 
 - **核心实现**：70%
-- **前序 Lab2、Lab3 功能正确**：10%
-- **思考题**：40%
+- **前序 Lab2、Lab3 功能正确**：20%
+- **思考题**：30%
 
 
 | Test              | Score |

docs/lab/lab6.md

@@ -2,9 +2,6 @@
 
 负责助教：[唐傑伟](mailto:[email protected])
 
-> [!important]
-> 本lab还在编辑中，内容仅供参考并随时可能发生变化。
-
 本次实验将实现基于 Inode 的文件系统的基础底层操作。**本实验工作量较大，请大家尽早开始。**
 
 ## 1. 服务器操作
@@ -294,7 +291,21 @@ int lookup(Inode *dir_inode, const char *name);
 > static void inode_remove(OpContext* ctx, Inode* inode, usize index)
 > ```
 
-## 4. 评测
+## 4. 思考题
+
+请在实验报告中回答以下问题（30% 分值）：
+
+**问题1：** 在我们的 Inode 实现中，使用了 `get/lock/sync/unlock/put` 的分离式接口设计。请分析这种设计的优势和潜在问题。如果采用传统的 `acquire/sync/release` 组合接口，你认为在什么场景下会出现性能瓶颈？
+
+**问题2：** 在 `inode_put` 函数中，我们需要检查 `rc` 和 `num_links` 两个计数器来决定是否删除 inode。请解释为什么需要这两个计数器，它们分别代表什么含义？如果只使用其中一个计数器会产生什么问题？
+
+**问题3：** 目录作为特殊文件的实现方式带来了哪些优势？如果采用专门的目录块结构（不作为普通文件），你认为优缺点分别是什么？
+
+**问题4：** 在实现 `inode_insert` 和 `inode_remove` 时，需要考虑目录文件大小的变化。请分析当目录项频繁增删时，可能出现哪些性能问题？如何优化？
+
+**问题5：** `inode_lookup`的时间复杂度是多少？如果目录中的文件数量很大，这种线性查找方式是否高效？有哪些可能的优化策略？
+
+## 5. 评测
 
 本次实验我们继续使用基于 Mock 的评测方法，离开virtio环境来测试你的文件系统。相关 C/C++ 代码在 `src/fs/test` 目录下。
 
@@ -320,14 +331,14 @@ $ make clean
 
 通过标准：没有显示任何 `(error)` 和 `(fatal)` 输出，则通过评测。
 
-## 5. 评分标准
+## 6. 评分标准
 
 本次实验的评分标准如下：
 
-- **核心实现**：80%
-- **思考题**：40%
+- **核心实现**：90%
+- **思考题**：30%（AI率超过80%的答案将不得分）
 
-## 6. 提交
+## 7. 提交
 
 **提交：将实验报告提交到 eLearning 上，格式为 `学号-lab6.pdf`。**
 
@@ -363,7 +374,7 @@ git commit -m "your final commit message"
 git checkout -b lab6-submission
 ```
 
-## 7. 参考资料
+## 8. 参考资料
 
 \[1] 聊聊 xv6 中的文件系统：https://www.cnblogs.com/KatyuMarisaBlog/p/14366115.html