Linux 7.1 原生 NTFS 驱动深度解析：3.6万行代码重写，NTFS 读写困境终得解

前言：Linux 用户的十年之痛

如果你是 Linux 用户，同时手里有块从 Windows 那边"借"过来的 NTFS 格式硬盘，那么大概率经历过这种尴尬：

• 能读，不能写——读数据没问题，但往里写东西，要么报错，要么直接把你的数据搞坏。
• 靠第三方方案凑合——NTFS-3G、Paragon NTFS3 驱动，都是在内核外（userspace）或以内（内核模块）打补丁，体验永远差那么一层。
• 性能像开盲盒——大文件写入慢吞吞，多线程场景直接卡死，还时不时冒出"只读挂载"的警告。

这个问题存在了多少年？整整快二十年。

2026年4月17日，Linux 创始人 Linus Torvalds 亲自将一套全新的 NTFS 文件系统驱动程序合入 Linux 7.1 主线内核——这意味着，Linux 终于拥有了真正的、原生内核级的 NTFS 读写支持。主导这项工作的，是来自韩国的核心内核开发者 Namjae Jeon，他历时四年，贡献了超过 36,000 行代码。

这篇文章，我们就来彻底拆解这个驱动：它是怎么来的、解决了哪些老问题、底层架构是什么样的、性能提升了多少，以及作为开发者你应该怎么用。

一、背景：Linux 为什么长期搞不定 NTFS

1.1 NTFS 的特殊性：闭源的代价

NTFS（New Technology File System）是微软为 Windows NT 系列开发的专有文件系统。从 1993 年随 Windows NT 3.1 登场至今，经历多次版本迭代（NTFS 3.0/3.1 是最常见版本，对应 Windows XP 及以后）。

问题在于：NTFS 的协议规范从未完全公开。微软从未发布过 NTFS 的完整技术规格文档，业界对 NTFS 的理解全靠逆向工程。

这就带来了几个根本性难题：

1. 文档不完整：部分 NTFS 元数据结构（如某些日志条目、属性类型）的语义不透明，只能靠反复测试和试错来推断。
2. 行为不确定：某些 Windows 行为依赖于 NTFS 与 Windows 内核的深度耦合，在 Linux 端复现时，稍有不慎就会触发数据不一致。
3. 版本碎片化：不同 Windows 版本对 NTFS 的实现细节有差异，驱动需要兼容从 Windows 2000 到 Windows 11 的所有变体。

1.2 历代方案的局限性

在全新原生驱动出现之前，Linux 社区尝试过几种方案：

方案一：NTFS-3G（用户态实现）

NTFS-3G 是一个完全运行在用户态（userspace）的 FUSE（Filesystem in Userspace）驱动。

工作原理：FUSE 内核模块暴露一个接口 → 用户态程序 NTFS-3G 接收 I/O 请求 
       → 在用户空间解析 NTFS 结构 → 通过 FUSE 写回内核

优点：安全隔离，用户态崩溃不会 kernel panic。
缺点：

• 性能瓶颈明显——每次 I/O 都要经过用户态/内核态上下文切换（context switch）
• 多线程写入场景下，FUSE 的全局锁成为瓶颈
• 复杂文件操作（如硬链接、扩展属性）支持有限

# 典型性能表现（实验室数据）
顺序写入：约 80-120 MB/s（机械硬盘，受 CPU 和 FUSE 开销限制）
随机 I/O：极差，延迟可达数十毫秒

方案二：Paragon NTFS3（内核模块）

Paragon 是商业公司，他们开发了一个内核级 NTFS 驱动，最初闭源，后来部分开源并进入 Linux 内核源码树（作为 NTFS3 驱动）。

工作原理：直接在内核空间解析 NTFS 结构，绕过 FUSE 的用户态开销

优点：性能大幅优于 NTFS-3G，顺序读写提升明显。
缺点：

• 代码质量参差不齐：Paragon 的驱动是为自家产品设计的，移植到 Linux 内核后，维护困难
• 停滞不前：该驱动数年未接收主线内核的同步更新，存在兼容性问题
• 架构老旧：未能利用现代 Linux 内核的新 API（如 folio、iomap v2）
• 对齐问题：在处理某些 NTFS 特定数据结构时，会触发边界条件和竞态

这正是 Namjae Jeon 决定从零重写的原因：现有方案都是"补丁思维"，没有从根本上解决 NTFS 与 Linux 内核生态的融合问题。

二、Namjae Jeon：从 exFAT 到 NTFS 的四年长征

2.1 开发者背景

Namjae Jeon 是一位来自韩国的 Linux 内核核心贡献者，在 Linux 文件系统领域有着丰富的经验。他的代表性贡献包括：

• exFAT 驱动：2022 年，Namjae Jeon 为 Linux 内核开发了完整的 exFAT 驱动，并贡献了允许 Linux 修复损坏 exFAT 卷的代码。这为他赢得了 Linus Torvalds 的信任。
• VFAT/NTFS 补丁：多年持续为 Linux NTFS 支持提交补丁，积累了深厚的 NTFS 协议知识。

Linus Torvalds 本人对他的评价颇高，称这次 NTFS 驱动工作为 "NTFS 复活"（NTFS revival） 计划。

2.2 四年开发历程

2022年Q1：项目启动，代码调研
     ↓
2022年Q3：完成 NTFS 日志（LogFile）解析框架
     ↓
2023年全年：实现 MFT（Master File Table）读写核心
     ↓
2024年Q1：处理复杂属性（B+树索引、压缩流、加密）
     ↓
2024年Q3：整合 iomap v2 接口，性能调优
     ↓
2025年全年：folio API 重构，边界条件修复
     ↓
2026年Q1：提交主线，Linus 短暂撤回（Git 结构问题）
     ↓
2026年Q2（4月17日）：修订版合并，进入 Linux 7.1 主线

整个项目超过 36,000 行新代码，覆盖了 NTFS 文件系统的几乎所有核心组件。

三、技术架构：从头设计的内核级文件系统驱动

3.1 为什么选择从头重写而非修补

这里有一个很关键的工程决策：为什么 Namjae Jeon 选择从零重写，而不是在 Paragon NTFS3 基础上修补？

核心原因有三点：

第一，架构不适配现代内核 API
Paragon NTFS3 使用的是老式 VFS（Virtual File System）接口，没有利用：

• folio：Linux 6.1+ 引入的内存管理单元，替代传统的 page 结构
• iomap：高性能 I/O 映射子系统，支持更高效的并发操作
• iomap v2：支持 dio（direct I/O）和 buffered I/O 统一接口

第二，数据结构语义不透明
Paragon 驱动的代码结构是为了性能优化的，很多 NTFS 语义被"扁平化"处理，导致某些高级特性（如重解析点、事务 NTFS）无法正确实现。

第三，维护成本高
在别人写的商业代码上打补丁，长期维护代价极高。重写虽然初期投入大，但后期的可持续性更好。

3.2 核心架构分层

新 NTFS 驱动的架构分为五层，每一层职责清晰：

┌─────────────────────────────────────────────────┐
│           VFS 层（Linux 标准文件操作接口）           │
│   open/read/write/mkdir/symlink 等 POSIX 操作     │
├─────────────────────────────────────────────────┤
│           NTFS inode 层（索引节点管理）              │
│   处理 i_mode、i_uid、i_gid、时间戳等 Unix 属性      │
│   与 NTFS 文件记录（File Record）的双向映射          │
├─────────────────────────────────────────────────┤
│           NTFS 属性层（Attribute Manager）          │
│   $STANDARD_INFORMATION、$FILE_NAME、$DATA 等     │
│   NTFS 特有属性的解析、创建、修改、事务记录          │
├─────────────────────────────────────────────────┤
│           NTFS 索引层（B+Tree Index）               │
│   MFT 索引、目录遍历、名称查找、硬链接解析           │
├─────────────────────────────────────────────────┤
│           NTFS 卷层（Volume Manager）               │
│   引导扇区、日志文件 ($LogFile)、位图 ($BitMap)    │
│   簇映射、压缩簇流、加密流                         │
├─────────────────────────────────────────────────┤
│           块设备层（Block Layer / iomap）          │
│   通过 iomap 与内核块设备子系统交互                │
└─────────────────────────────────────────────────┘

3.3 关键技术实现

3.3.1 MFT（Master File Table）文件记录解析

NTFS 的核心是 MFT——一个特殊的元数据文件，记录了卷上所有其他文件的信息。每个文件至少有一个 MFT 条目。

// 新 NTFS 驱动中 MFT 条目解析的简化示意
struct ntfs_mft_record {
    /* MFT 头部（固定大小） */
    __le32  magic;              // "FILE" 魔数
    __le16  sequence_num;       // 序列号（删除后重用）
    __le16  link_count;         // 硬链接计数
    __le16  attrs_offset;       // 第一个属性的偏移
    __le16  flags;              // 标志：已分配/删除/in_use
    __le32  bytes_used;         // 条目实际使用字节
    __le32  bytes_allocated;    // 条目分配大小（通常 1024 或 4096）
    
    /* 接下来是可变长属性列表 */
} __attribute__((packed));

关键实现细节：

// 从 MFT 条目中提取指定类型属性的函数
static inline struct ntfs_attribute *
ntfs_attr_lookup(struct ntfs_mft_record *rec, ATTR_TYPE type, 
                  ntfschar *name, size_t name_len)
{
    struct ntfs_attribute *attr;
    struct ntfs_attribute *first = (struct ntfs_attribute *)
        ((u8 *)rec + le16_to_cpu(rec->attrs_offset));

    for (attr = first; (u8 *)attr < (u8 *)rec + le32_to_cpu(rec->bytes_used);
         attr = (struct ntfs_attribute *)((u8 *)attr + 
              le32_to_cpu(attr->size))) {
        
        if (attr->type != type)
            continue;
        if (name_len != attr->name_length)
            continue;
        if (name_len && memcmp(name, (u8 *)attr + attr->name_offset,
                                name_len * sizeof(ntfschar)))
            continue;
        return attr;
    }
    return NULL;
}

3.3.2 日志文件系统：NTFS LogFile 的挑战

NTFS 是一个日志文件系统（Journaling File System）。所有元数据变更都会先写入 $LogFile（日志文件），确保系统崩溃后能恢复到一致状态。

这是 NTFS 最复杂的部分之一——Windows 要求 NTFS 驱动器在每次操作后保持日志一致，如果 Linux 驱动破坏了日志状态，Windows 会拒绝挂载该分区，甚至触发文件系统修复。

新驱动的日志处理策略：

/**
 * ntfs_restart_area_read - 读取日志重启区域
 * @vol: NTFS 卷信息
 * 
 * 日志重启区域（LsnRestartArea）包含日志文件的检查点和
 * 恢复所需的状态信息。
 */
static int ntfs_restart_area_read(struct ntfs_volume *vol)
{
    struct ntfs_restart_page *rp;
    struct buffer_head *bh;
    int ret;

    bh = sb_bread(vol->sb, vol->log_lbo / vol->sb->s_blocksize);
    if (!bh)
        return -EIO;

    rp = (struct ntfs_restart_page *)bh->b_data;

    /* 验证魔数 "RSTR"（Restart） */
    if (magic64_diff(rp->magic, cpu_to_le64(0x52545253 /* RSTR */))) {
        ntfs_error(vol->sb, "Invalid log restart area magic.");
        ret = -EINVAL;
        goto out;
    }

    /* 解析检查点状态 */
    vol->current_lsn = le64_to_cpu(rp->current_lsn);
    vol->client_index = le16_to_cpu(rp->client_index);

    ret = 0;
out:
    brelse(bh);
    return ret;
}

为什么日志如此关键：如果 Linux 写入了 NTFS 但破坏了日志结构，Windows 再次挂载时会认为文件系统处于"脏"状态，触发 chkdsk 强制修复。轻则丢失修改，重则整盘数据损坏。新驱动通过严格遵循 NTFS 日志协议，避免了这一问题。

3.3.3 folio 集成：内存管理的新范式

Linux 6.1 引入的 folio API 是对传统 page cache 的一次重大升级：

新 NTFS 驱动全面采用 folio：

/**
 * ntfs_read_folio - folio 粒度的文件数据读取
 * @file: 已打开的文件
 * @folio: 目标 folio（包含 2^n 个 page）
 */
static int ntfs_read_folio(struct file *file, struct folio *folio)
{
    struct inode *inode = file_inode(file);
    struct ntfs_inode *ni = ntfs_i(inode);
    struct page *page = &folio->page;
    u64 vcn = (u64)page->index << (PAGE_SHIFT - vol->cluster_size_bits);
    u64 lcn;
    u64 valid_size = i_size_read(inode);
    struct folio_iter fi;
    size_t copied = 0;
    int err = 0;

    /* 对齐到簇边界 */
    lcn = ntfs_vcn_to_lcn(ni, vcn, false);
    if (lcn == LCN_ENOENT)
        goto handle_extents;

    /* 使用 iomap 进行零拷贝直接映射 */
    err = iomap_read_folio(folio, &ni->iomap_ops);
    if (err < 0) {
        ntfs_error(inode->i_sb, "iomap_read_folio failed: %d", err);
        goto out;
    }

handle_extents:
    /* 处理稀疏簇（sparse clusters） */
    if (lcn == LCN_HOLE || lcn == LCN_ENOENT) {
        filemap_invalidate_folio(folio->mapping, folio_pos(folio),
                                  folio_size(folio));
    }

out:
    folio_unlock(folio);
    return err;
}

3.3.4 iomap v2：统一的高性能 I/O 路径

iomap（I/O Mapping）是 Linux 内核中用于将文件偏移映射到物理块设备的子系统。相比传统的 mapping->bmap 接口，iomap 支持更高效的 DIO（Direct I/O）和更智能的写合并。

/**
 * ntfs_iomap_begin - 将文件区间映射到物理块
 * @inode: 文件 inode
 * @pos: 文件内偏移（字节）
 * @length: 请求长度
 * @flags: 操作标志（R/W）
 * @iomap: 输出：iomap 结果
 * 
 * 这是 iomap 驱动的核心函数，将 NTFS 的簇分配
 * 映射到线性块设备地址空间。
 */
static int ntfs_iomap_begin(struct inode *inode, loff_t pos,
                            loff_t length, unsigned flags,
                            struct iomap *iomap, struct iomap *srcmap)
{
    struct ntfs_inode *ni = ntfs_i(inode);
    struct ntfs_volume *vol = ni->vol;
    u64 lcn;          // 逻辑簇号
    u64 pblock;       // 物理块号
    u32 cluster_size = vol->cluster_size;

    /* 处理空洞（sparse/extents） */
    if (flags & IOMAP_WRITE) {
        /* 写入时先检查空间，必要时分配新簇 */
        lcn = ntfs_cluster_alloc(ni, pos, length);
        if (lcn == LCN_ENOMEM)
            return -ENOSPC;
    } else {
        /* 读取时查找已分配簇 */
        lcn = ntfs_vcn_to_lcn(ni, pos >> vol->cluster_size_bits, false);
        if (lcn == LCN_HOLE) {
            /* 稀疏区域，返回空洞映射 */
            iomap->type = IOMAP_HOLE;
            iomap->addr = IOMAP_NULL_ADDR;
            return 0;
        }
        if (lcn == LCN_ENOENT)
            return -ENOENT;
    }

    /* 簇号转换为物理块号 */
    pblock = vol->device_start + (lcn * cluster_size / SECTOR_SIZE);

    /* 填充 iomap 结果 */
    iomap->type = flags & IOMAP_WRITE ? IOMAP_F_MAPPED : IOMAP_MAPPED;
    iomap->addr = (sector_t)pblock << (SECTOR_SHIFT - 9);
    iomap->length = min_t(loff_t, length, 
                          (loff_t)cluster_size * ni->data_alloc_size 
                          - (pos & (cluster_size - 1)));
    iomap->flags = IOMAP_F_NEW;

    return 0;
}

3.4 与旧方案 NTFS3 的架构对比

四、性能分析：数字说话

4.1 基准测试数据

根据中关村在线和 Phoronix 的测试数据（2026年4月21日），全新 NTFS 驱动相较于 Paragon NTFS3：

顺序写入性能

测试环境：
- CPU: AMD Ryzen 9 9950X
- 内存: DDR5-6400 64GB
- 硬盘: Samsung 990 Pro 2TB (NVMe PCIe 4.0)
- 文件系统: NTFS (被测卷)
- 测试工具: fio (bs=1M, ioengine=libaio, iodepth=4)

顺序写入 1GB 文件：
Paragon NTFS3：  620 MB/s（基准）
新 NTFS 驱动：   837 MB/s（+35%）
新 NTFS 多线程：1054 MB/s（+70%）

多线程写入是最大亮点——Paragon NTFS3 的老架构在多线程场景下存在全局锁瓶颈，而 iomap v2 的并发设计让新驱动在 4 线程写入时性能提升达 70%。

大容量硬盘挂载速度

测试：挂载一块 4TB NTFS 机械硬盘（WD Blue, 5400 RPM）

Paragon NTFS3：28.4 秒（基准）
新 NTFS 驱动： 7.1 秒（+75%，提升 4 倍）

挂载速度提升 4 倍的核心原因：新驱动的 MFT 缓存策略和 folio 预读机制大幅减少了磁盘 I/O 次数。

4.2 性能提升的深层原因

性能提升不是"优化参数"能达到的效果，而是架构层面的必然：

1. folio 减少内存碎片
传统 page cache 在处理大文件时会产生数千个 4KB 的 page 对象，每个对象都需要独立的内存头和锁。folio 将连续的物理页合并为单一对象，内存分配和查找的开销随文件大小线性增长，而非指数增长。

2. iomap 消除重复映射查找
mapping->bmap 接口在每次写操作时都要遍历 VFS → 文件系统 → 块设备三层来完成物理块查找。iomap 提供了更激进的映射缓存，同一文件区域的重复访问几乎零开销。

3. 直接 I/O 绕过 page cache
对于大文件顺序读写，启用 O_DIRECT 标志后，新驱动的 iomap 路径可以直接将用户缓冲区的物理页映射到块设备 I/O 请求，绕过整个 page cache 层，避免了一次内存复制。

五、使用指南：如何在 Linux 7.1 中启用新驱动

5.1 编译选项

新驱动通过 Kconfig 选项启用：

# 在内核源码目录中
cd /usr/src/linux-7.1

# 启用 NTFS_FS (NEW) 驱动
make menuconfig

# 导航路径：
# File systems  →  DOS/FAT/EXFAT/NT Filesystems  →  
#   < > NTFS Read-Write File System support (NEW)     ← 选择 M（模块） 或 *（内置）

# 或者直接编辑 .config
CONFIG_NTFS_FS=m        # 编译为模块 ntfs.ko
# 或
CONFIG_NTFS_FS=y        # 内置到内核

5.2 挂载 NTFS 分区

# 方式一：自动挂载（推荐，由 udev 处理）
# 插入 NTFS 设备后，系统自动识别并挂载到 /run/media/$USER/卷标

# 方式二：手动挂载（完整控制）
sudo mount -t ntfs /dev/sdb1 /mnt/ntfs_drive \
    -o uid=1000,gid=1000,dmask=022,fmask=133, \
       streams_interface=xattrs,hide_dot_files

# 方式三：指定写入模式（新驱动原生支持写入，无需额外参数）
sudo mount -t ntfs3 /dev/sdb1 /mnt/ntfs_drive \
    -o uid=1000,gid=1000,permissions,streams_interface=xattrs

# 方式四：编辑 /etc/fstab 永久挂载
# 在 /etc/fstab 中添加：
# /dev/sdb1  /mnt/ntfs_drive  ntfs3  uid=1000,gid=1000,permissions  0  2

5.3 新旧驱动切换

如果遇到兼容性问题（极少数情况），可以强制使用旧驱动：

# 强制使用 Paragon NTFS3（旧）
sudo mount -t ntfs3 /dev/sdb1 /mnt/ntfs_drive -o force

# 强制使用 NTFS-3G（用户态）
sudo ntfs-3g /dev/sdb1 /mnt/ntfs_drive

# 查看当前使用的 NTFS 驱动
dmesg | grep -i ntfs
# 输出示例：
# [  123.456] NTFS: new NTFS driver from Namjae Jeon
# [  123.789] NTFS: volume version 3.1

5.4 验证新驱动的工作状态

# 查看内核模块信息
cat /proc/filesystems | grep ntfs
# 输出应包含 ntfs3：

# nodev    ntfs
# nodev    ntfs3

# 检查挂载选项中的驱动类型
mount | grep ntfs
# /dev/sdb1 on /mnt/ntfs_drive type ntfs3 (rw,nosuid,nodev,...)

# 使用 ntfsinfo 查看卷信息（新驱动提供）
ntfsinfo -m /dev/sdb1

5.5 性能调优参数

# 在挂载选项中添加性能参数

# 启用 POSIX ACL（获取更精细的权限控制）
sudo mount -t ntfs3 /dev/sdb1 /mnt/ntfs_drive \
    -o acl,user_xattr,streams_interface=xattrs

# 禁用访问时间更新（减少写入，提升速度）
sudo mount -t ntfs3 /dev/sdb1 /mnt/ntfs_drive \
    -o noatime,nodiratime

# 推荐的生产环境选项
MY_UID=$(id -u)
MY_GID=$(id -g)
sudo mount -t ntfs3 /dev/sdb1 /mnt/ntfs_drive \
    -o uid=$MY_UID,gid=$MY_GID, \
       permissions,streams_interface=xattrs, \
       hide_dot_files,windows_names,compression

六、兼容性与边界场景

6.1 已支持的特性

全新 NTFS 驱动的功能覆盖度非常全面：

• ✅ 完整读写（终于不是"只读"了）
• ✅ POSIX 权限（uid/gid/mode）
• ✅ 硬链接
• ✅ 符号链接（重解析点）
• ✅ 扩展属性（xattr）
• ✅ ACL（访问控制列表）
• ✅ 压缩文件流
• ✅ NTFS 日志（崩溃恢复）
• ✅ 大文件（>4GB）
• ✅ 大卷（>2TB）
• ✅ Unicode 文件名
• ✅ Windows 权限继承（部分支持）

6.2 已知限制

• ⚠️ 加密文件（EFS）：BitLocker 加密的 NTFS 卷暂时不支持，这是微软专有加密技术
• ⚠️ 事务 NTFS（TxF）：Windows 特有的事务机制尚不支持
• ⚠️ 某些特殊的重解析点：如文件系统挂载点和符号链接的特殊变体
• ⚠️ $Secure 属性：部分 Windows 安全描述符字段的语义解析尚不完全

6.3 Windows/Linux 双引导场景的注意事项

对于双系统用户（Windows + Linux）：

# 场景：Windows 休眠后，Linux 挂载 NTFS 分区
# Windows 快速启动（Fast Startup）会留下 hibernation 文件
# 挂载时系统会拒绝写入以保护数据：

# 查看原因
dmesg | grep -i ntfs
# [  234.567] NTFS: volume is hibernated, refusing to mount.
# [  234.568] NTFS: volume is dirty, running chkdsk is recommended.

# 解决方案：
# 方法一：在 Windows 中关闭快速启动
#    控制面板 → 电源选项 → 选择电源按钮的功能 → 启用快速启动（取消勾选）

# 方法二：强制挂载（不推荐，可能丢失 Windows 未保存数据）
sudo mount -t ntfs3 /dev/sdb1 /mnt/ntfs_drive -o force

# 方法三：从 Linux 运行 NTFS 修复（实验性）
sudo ntfsfix /dev/sdb1
sudo mount -t ntfs3 /dev/sdb1 /mnt/ntfs_drive

七、开发视角：从 NTFS 驱动看内核贡献

7.1 参与内核开发的门槛

Namjae Jeon 的这个项目给我们的最大启示是：Linux 内核开发并没有想象中那么遥远。

关键技术点：

• C 语言和算法基础
• 对 Linux 内核 VFS 子系统的理解
• 对 NTFS 协议规范的深入研究（参考 NTFS 文档和开源实现如 Linux-NTFS 项目）
• 耐心：四年时间，36,000 行代码

7.2 如何参与文件系统驱动开发

# 1. 搭建开发环境
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux
git checkout -b ntfs-devel origin/master

# 2. 了解测试框架
# 运行 xfstests（Linux 文件系统测试套件）
git clone https://github.com/kdave/xfstests.git
cd xfstests
# 配置针对 NTFS 的测试用例

# 3. 提交补丁
git format-patch -1
# 发送给邮件列表：linux-fsdevel@vger.kernel.org
# 补丁会经过数轮 review 才能进入主线

7.3 从这个项目中可以学习的设计模式

分层架构：新 NTFS 驱动的五层设计清晰地分离了关注点——VFS 层处理 POSIX 接口，inode 层处理 Unix 语义，属性层处理 NTFS 特有结构。这种分层在 Linux 几乎所有文件系统驱动中都能看到（ext4、btrfs、xfs 等）。

事务语义：NTFS 日志的处理方式是学习日志文件系统设计的绝佳案例。

folio/iomap 的演进：从传统 page + mapping 到 folio + iomap 的迁移，反映了 Linux 内核在存储子系统的持续演进，理解这个演进过程对所有内核开发者都有价值。

八、总结与展望

8.1 这件事的意义

Linux 7.1 原生 NTFS 驱动的合并，不仅仅是一个"多了个驱动"的小事。它的意义在于：

对普通用户：彻底解决了 Linux 与 Windows 之间最大的互操作性痛点——NTFS 分区读写障碍从此成为历史。无需额外安装驱动，无需配置 FUSE，开箱即用。

对系统开发者：一个全新的、生产级的内核文件系统驱动，展示了 folio + iomap v2 组合的工程威力，将成为后续内核开发的参考标杆。

对 Linux 生态：四年开发、36,000 行代码、一个人主导、社区维护——这个项目本身就是对"开源软件维护者激励缺失"论调的有力反驳。真正的热爱，可以驱动一个人花四年时间解决一个"别人不愿意碰"的问题。

8.2 未来可期

根据 Linux 内核邮件列表的讨论，Namjae Jeon 和社区已经规划了后续工作：

• 版本 7.2：完善 EFS/BitLocker 加密支持
• 版本 7.3：引入 fsck.ntfs（NTFS 文件系统检查和修复工具）
• 长期：与 Windows 团队接触，推动 NTFS 规范的部分开放

8.3 给程序员的一句话

如果你还在用 NTFS-3G 或 Paragon NTFS3，赶紧升级到 Linux 7.1。这不只是性能翻倍的问题——这是一个真正融入 Linux 内核生态系统的 NTFS 实现，不再是"外来者"，而是"自己人"。

如果你是对内核开发感兴趣的程序员，这个项目是最好的教科书：从协议理解到架构设计，从 folio 到 iomap，从单元测试到邮件列表 review——Linux 内核开发的全流程，都在这里了。

代码改变世界，有时候就是 36,000 行。

参考资料：Linux 内核源码（fs/ntfs3/）、Phoronix 测试报告（2026-04-21）、中关村在线评测（2026-04-21）、DoNews 技术报道（2026-04-18）、Linus Torvalds 内核邮件列表公告（2026-04-17）。