Windows 磁盘与文件系统 — 盘符帝国的秩序 / Windows Disks and Filesystems
📅 创建时间：2026-06-17 🏷️ 标签：#Windows #NTFS #磁盘管理 #盘符 #ReFS 📚 前置知识：[[05-filesystem-formats]], [[10-linux-disk-practice]]
📋 本章目标
- 理解 Windows 磁盘管理的两种界面：MMC 图形界面 + diskpart 命令行
- 掌握盘符（Drive Letter）的本质——DOS 遗留的单根替代品
- 理解 NTFS 挂载到目录——Windows 也支持 Linux 式挂载
- 深入 NTFS 内部：MFT 结构、ADS、USN Journal
- 了解 ReFS——微软的 COW 文件系统
- 掌握 Linux 如何读写 NTFS（ntfs-3g vs ntfs3 内核驱动）
第1部分：Windows 磁盘管理工具
1.1 diskpart — Windows 的 fdisk
┌─────────────────────────────────────────────────────────────┐
│ diskpart vs fdisk 对比 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Linux fdisk │ Windows diskpart │
│ ──────────────────────────── │ ────────────────────────── │
│ $ sudo fdisk /dev/sda │ > diskpart │
│ Command: p (打印) │ DISKPART> list disk │
│ Command: n (新建) │ DISKPART> select disk 0 │
│ Command: d (删除) │ DISKPART> list partition │
│ Command: w (写入) │ DISKPART> create partition │
│ │ primary size=512│
│ │
│ 基础命令: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ DISKPART> list disk 列出磁盘 │ │
│ │ DISKPART> select disk 0 选择磁盘 0 │ │
│ │ DISKPART> list partition 列出该磁盘的分区 │ │
│ │ DISKPART> select part 1 选择分区 1 │ │
│ │ DISKPART> clean 清除整个磁盘的分区表 │ │
│ │ DISKPART> convert gpt 转换为 GPT │ │
│ │ DISKPART> create partition 创建主分区 │ │
│ │ primary size=102400 (MB) │ │
│ │ DISKPART> format fs=ntfs 格式化为 NTFS │ │
│ │ quick label="Data" │ │
│ │ DISKPART> assign letter=D 分配盘符 D: │ │
│ │ DISKPART> remove 移除盘符 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 磁盘管理 MMC (diskmgmt.msc): │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 图形界面, 对应 Linux 的 gparted │ │
│ │ 可以: 创建/删除分区、格式化、改盘符、扩展/压缩卷 │ │
│ │ Windows 能做的都在这里, 比 diskpart 直观但功能少 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
第2部分：盘符 (Drive Letter) — DOS 的幽灵
2.1 盘符到底是什么
┌─────────────────────────────────────────────────────────────┐
│ 盘符 vs Linux 挂载点 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 盘符是 DOS 时代的遗产。那时没有"目录树"的概念。 │
│ │
│ DOS 的设计: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ A: ← 第一个软驱 │ │
│ │ B: ← 第二个软驱 (有些电脑有两个) │ │
│ │ C: ← 第一个硬盘 │ │
│ │ D: ← 光驱 或 第二个硬盘 │ │
│ │ │ │
│ │ 每个盘符是一个独立的"命名空间" │ │
│ │ 没有统一的根目录 │ │
│ │ cd D: → 切换到 D 盘 → 和 C: 完全独立 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 今天 Windows 仍然保留盘符: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ C: → 系统盘 (NTFS) │ │
│ │ D: → 数据盘 │ │
│ │ E: → 光驱 │ │
│ │ A: B: → 保留给历史兼容 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 盘符 vs Linux 挂载点 — 本质区别: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 盘符 = 独立根 挂载点 = 树节点 │ │
│ │ │ │
│ │ D:\Data\file.txt /mnt/data/file.txt│ │
│ │ D: 是独立根, 下面有自己的树 / 是唯一的根 │ │
│ │ 不能 mv C:\a.txt D:\ mv /a /mnt/b 可以│ │
│ │ (跨盘符拷贝, 不是移动) (同 FS 是 rename,│ │
│ │ 跨 FS 是拷贝+删)│ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Windows 也支持挂载到目录! (从 Windows 2000 开始) │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 你可以把一块新磁盘挂载到 C:\Data: │ │
│ │ 这样就不用新增盘符 — 和 Linux 的 mount 一样 │ │
│ │ │ │
│ │ diskpart 操作: │ │
│ │ > select volume 3 │ │
│ │ > remove letter=D ← 先移除盘符 │ │
│ │ > assign mount=C:\Data ← 挂载到目录 │ │
│ │ │ │
│ │ 或 磁盘管理 MMC → 右键分区 → 更改驱动器号和路径 │ │
│ │ │ │
│ │ 这个功能让 Windows 也有了"单根树"的能力 │ │
│ │ 但 Windows 生态中 99% 的用法还是盘符 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
第3部分：NTFS 深入 — 从内部结构理解性能
3.1 MFT 碎片化问题
┌─────────────────────────────────────────────────────────────┐
│ MFT 碎片化 — NTFS 性能的天敌 │
├─────────────────────────────────────────────────────────────┤
│ │
│ MFT 是 NTFS 最核心的数据结构 (见 [[05-filesystem-formats]]) │
│ │
│ MFT 碎片化: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 正常: MFT 是一块连续的磁盘空间 │ │
│ │ 文件记录 0 → 1 → 2 → ... → N │ │
│ │ 顺序读 = 一次磁盘寻道 │ │
│ │ │ │
│ │ 碎片化后: │ │
│ │ MFT extension → 散落在磁盘各处 │ │
│ │ 读一个文件的 MFT 记录 → │ │
│ │ 先找到 MFT 扩展 → 再跳到那个位置 → 磁盘寻道 │ │
│ │ → 每个文件的元数据访问都可能需要寻道 │ │
│ │ │ │
│ │ 原因: 用户在系统盘创建大量小文件 │ │
│ │ MFT 初始分配的空间(通常 12.5%) 不够用 │ │
│ │ NTFS 不得不在数据区开扩展 │ │
│ │ │ │
│ │ 预防: 格式化时用 /L 参数预分配 MFT 大小 │ │
│ │ format C: /FS:NTFS /L:1048576 │ │
│ │ (预留大 MFT 区域) │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
3.2 ADS (Alternate Data Streams) — 隐形的数据流
┌─────────────────────────────────────────────────────────────┐
│ ADS — 一个文件可以藏另一个文件 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 每个 NTFS 文件可以有多个 $DATA 属性 (流): │
│ │
│ echo "hello" > file.txt ← 主数据流 (默认) │
│ echo "hidden" > file.txt:secret ← 备用数据流 (ADS) │
│ │
│ dir file.txt → 看不到 :secret │
│ dir /r file.txt → 显示所有流 │
│ notepad file.txt:secret → 可以读取 │
│ │
│ Windows 的实际用途: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 1. Zone.Identifier (标记文件来源) │ │
│ │ 下载的 .exe → 被标记为 "来自互联网" │ │
│ │ = file.exe:Zone.Identifier │ │
│ │ 内容: [ZoneTransfer]\nZoneId=3 │ │
│ │ 打开时 Windows 弹窗: "是否运行此文件?" │ │
│ │ │ │
│ │ 2. 就是隐藏恶意代码 │ │
│ │ ADS 不计数到文件大小, 普通 dir 看不到 │ │
│ │ 历史上被大量用于隐藏 rootkit │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 跨平台问题: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 把 NTFS 上带 ADS 的文件复制到 ext4/FAT32 → ADS 丢失 │ │
│ │ 从网上下载的文件 → Zone.Identifier → 复制到 U 盘 │ │
│ │ → FAT32 不支持 ADS → 丢失标记 → 不再弹警告 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
3.3 USN Journal — 高效的变更追踪
┌─────────────────────────────────────────────────────────────┐
│ USN Journal — NTFS 的变更日志 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 每个文件变更 (创建/修改/重命名/删除/权限改) → USN 记录 │
│ │
│ USN Journal 的应用: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 1. Windows Search Indexer │ │
│ │ 不需要扫描整个磁盘来找变化 → 读 USN Journal 即可 │ │
│ │ │ │
│ │ 2. 备份软件 │ │
│ │ 增量备份 → 问 USN 哪些文件自上次备份后变了 │ │
│ │ 比遍历目录树快数百倍 │ │
│ │ │ │
│ │ 3. 杀毒软件 │ │
│ │ 新创建的文件 → 从 USN 获取 → 扫描 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 对比: Linux 的 inotify 实时监 控文件变更 │
│ 但 inotify 只能监 控当前, 不提供历史变更记录 │
│ 要查历史需要用 fanotify 或轮询 + mtime │
│ │
└─────────────────────────────────────────────────────────────┘1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
第4部分：ReFS — 微软的 COW 文件系统
┌─────────────────────────────────────────────────────────────┐
│ ReFS — 微软对 btrfs/ZFS 的回应 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ReFS (Resilient File System): │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 核心特性: │ │
│ │ • COW (部分) — 元数据用 COW, 数据可选 │ │
│ │ • checksum — 检测静默数据损坏 │ │
│ │ • Storage Spaces 集成 — 自动修复损坏数据 │ │
│ │ • 不替代 NTFS — 仅用于特定场景 │ │
│ │ │ │
│ │ ReFS 少了什么 (相对于 NTFS): │ │
│ │ ❌ 不支持作为系统盘 │ │
│ │ ❌ 不支持压缩 (想用压缩用 NTFS) │ │
│ │ ❌ 不支持 EFS 加密 │ │
│ │ ❌ 不支持磁盘配额 │ │
│ │ │ │
│ │ 适用场景: │ │
│ │ • Hyper-V 虚拟机存储 │ │
│ │ • 文件服务器 / NAS │ │
│ │ • 存储大文件且有数据完整性需求 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 对比表: │
│ ┌──────────────────────────────────────────────────┐ │
│ │ NTFS ReFS btrfs ZFS │ │
│ │ COW ❌ ✅(部分) ✅ ✅ │ │
│ │ checksum ❌ ✅ ✅ ✅ │ │
│ │ 压缩 ✅ ❌ ✅ ✅ │ │
│ │ 快照 VSS ✅ ✅ ✅ │ │
│ │ 系统盘 ✅ ❌ ✅ ✅ │ │
│ │ 成熟度 极成熟 一般 较成熟 极成熟 │ │
│ └──────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
第5部分：Linux 读写 NTFS — 双系统数据共享
┌─────────────────────────────────────────────────────────────┐
│ 从 Linux 访问 Windows 数据 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 两种 NTFS 驱动: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ntfs-3g (用户态, FUSE): │ │
│ │ • 成熟, 稳定, 功能完整 │ │
│ │ • 通过 FUSE 在用户态运行 → 性能较差 │ │
│ │ • 支持: 读写、压缩、加密(有限) │ │
│ │ │ │
│ │ 内核 ntfs3 (内核态): │ │
│ │ • Linux 5.15+ 内置 (Paragon Software 贡献) │ │
│ │ • 性能远好于 ntfs-3g │ │
│ │ • 支持: 读写、压缩 │ │
│ │ • 不支持: 加密 │ │
│ │ • 挂载: mount -t ntfs3 /dev/sdb1 /mnt/win │ │
│ │ │ │
│ │ 推荐: 内核 5.15+ → 用 ntfs3 │ │
│ │ 老内核 → ntfs-3g │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 快速启动问题 (再次强调): │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Windows 快速启动关机 → NTFS 处于"脏"状态 │ │
│ │ → Linux 挂载失败 或 只读挂载 │ │
│ │ │ │
│ │ 解决方案: │ │
│ │ 1. Windows 中: powercfg /h off (永久关闭) │ │
│ │ 2. Linux 中强制: │ │
│ │ ntfs-3g -o remove_hiberfile /dev/sdb1 /mnt/win │ │
│ │ 这会删除休眠文件并强制挂载 (可能丢数据!) │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ fstab 里写双系统共享分区: │
│ UUID=xxx /mnt/windows ntfs3 defaults,nofail,uid=1000 0 0 │
│ # uid=1000 → 指定文件所有者为你自己, 不然全是 root │
│ │
└─────────────────────────────────────────────────────────────┘1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
核心总结
总结1：盘符的真相
盘符 (C: D: E:) = DOS 时代的"独立根", 每一个是一个命名空间
挂载点 (Linux) = 单根树, 所有文件系统嫁接在同一棵树上
Windows 也支持挂载到目录 — 但盘符是默认, 挂载是例外1
2
3
2
3
总结2：NTFS 的灵魂是 MFT
MFT = 一张巨表, 每一个文件和目录是一条 1KB 记录
关键: 小文件内嵌在 MFT 里 → 不需要额外数据块
风险: MFT 碎片化 → 每个文件访问多一次寻道 → 系统变慢1
2
3
2
3
总结3：Linux 访问 NTFS 的首选
内核 ntfs3 (5.15+) > ntfs-3g (FUSE)
关掉 Windows 快速启动 → 否则 NTFS 脏状态下 Linux 挂载冲突1
2
2
章节测试
测试1：盘符
Windows 的盘符（Drive Letter）是什么时代的概念？为什么 A: 和 B: 通常没有被分配？
测试2：挂载到目录
Windows 支持把分区挂载到目录（如 C:\Data）而不是分配盘符。这和 Linux 的 mount 有什么区别？
测试3：ADS
一个文件 report.txt 有 ADS。你在 Windows 上把它复制到 FAT32 格式的 U 盘，然后从 U 盘复制回来。ADS 还在吗？
测试4：ntfs3
Linux 内核 6.1 + 双系统。你要读写 Windows 的 NTFS 数据分区，应该用 mount -t ntfs3 还是 ntfs-3g？为什么？
参考答案
测试1答案
盘符来自 DOS 时代（1980 年代）。A: 和 B: 是给软盘驱动器保留的——第一台 PC 通常有两个软驱（5.25 寸和 3.5 寸）。今天虽然没有人用软驱了，但 Windows 保留了 A: 和 B: 的兼容性（可以手动分配，但默认跳过）。
测试2答案
本质相同——都是把块设备上的文件系统"嫁接"到目录树的某个位置。区别在于使用习惯：Linux 依赖 mount，盘符是可选的例外；Windows 依赖盘符，目录挂载是少数人的选择。挂载到目录后的行为在两种 OS 上完全一致：访问该目录 → 访问的是被挂载分区的内容。
测试3答案
不在。FAT32 不支持 ADS（Alternate Data Streams）。复制到 FAT32 时，只有主数据流（默认 $DATA）被复制。ADS 静默丢失。再复制回 NTFS 也不会恢复。所以跨文件系统的文件复制可能丢失元数据。
测试4答案
应该用 mount -t ntfs3。内核 6.1 已经包含 Paragon 的 ntfs3 内核驱动，性能远好于用户态的 ntfs-3g。ntfs3 是内核态实现，不需要通过 FUSE，延迟更低，吞吐量更高。当然要确保 Windows 的快速启动已关闭。
相关笔记
- [[05-filesystem-formats]] - NTFS 与 ext4/btrfs 的横向对比
- [[10-linux-disk-practice]] - Linux 端的磁盘操作
- [[14-dual-boot]] - 双系统共享数据分区的完整方案
下一步学习
- [ ] 阅读 12 - ext4 深入
学习状态：🟡 开始学习