先说一个真实经历。以前给一家公司搭研发环境，存储服务器是Linux，图省事统一开了SMB共享给所有人用，结果Linux开发机拉取构建产物、同步代码仓库的时候，速度慢到让人怀疑人生，CPU倒是居高不下。后来把Linux端的挂载全部换成NFS，问题立刻消失。那次之后我形成了一个很明确的观点：nfs、smb不要混用，推荐linux使用nfs，windows使用smb。这不是什么教条，而是两种协议从设计土壤开始就完全不同，硬要混着用，你迟早会在性能、权限、锁、文件编码这些地方交学费。
这篇文章我就把这背后的逻辑掰开讲清楚，包括两种协议的根本差异、混用时的典型故障对照、推荐场景下的具体挂载配置，以及一次真实故障的完整排查过程。不管你是在折腾家里NAS，还是在管理公司里的混合存储环境，这篇内容都能帮你少走很多弯路。
1. 为什么说NFS和SMB"不是一个物种"：从出身看协议基因
1.1 NFS的UNIX血统：目录挂载与uid/gid权限模型
NFS（Network File System）诞生于SUN Microsystems，1984年提出，目标是让UNIX工作站之间共享文件系统。它的核心思路非常"UNIX"：把远程目录像本地目录一样挂载进来，客户端看到的就是一个完整的目录树，对用户来说完全没有"网络"的感知。
这种设计带来的第一个关键影响就是权限模型。NFS v3时期最常用的认证方式叫AUTH_SYS（也叫AUTH_UNIX），说白了就是客户端直接告诉服务器"我是uid=1000、gid=1000的用户"，服务器也不多问，直接按这个身份给你分配文件权限。在早期的局域网内部环境里，这个模型够用，网络是可信的，同事也是可信的。到了NFS v4时代，引入了RPCSEC_GSS，支持Kerberos认证和加密，但默认情况下很多部署仍然保留了基于uid/gid的授权逻辑。
第二个关键影响是文件语义。NFS从设计上就尽量模拟POSIX文件系统语义，open、read、write、close、fsync这些操作都能找到对应的RPC调用。开发者写程序时，用标准POSIX API访问NFS挂载目录，行为表现非常接近本地磁盘。
我给Linux服务器挂NFS时的思考框架是：NFS在Linux内核里有native实现，client和server端都是内核线程在处理，路径短、开销小。这意味着什么？意味着大量小文件操作、元数据操作（create、unlink、stat）的性能会明显优于那些靠用户态进程模拟文件共享的方案。
1.2 SMB的Windows血统：会话、共享与用户认证
SMB（Server Message Block）的历史比NFS还早，1983年由IBM发明，后来微软把它发扬光大，成为Windows网络共享的基石。SMB的思路不是"把远程目录变成本地目录"，而是"建立一条会话，访问某个共享资源"。
这个区别听起来很微妙，但影响深远。SMB的一切都围绕会话（session）和用户展开。客户端要先完成身份认证（NTLM或Kerberos），建立起一个上下文，然后在这个上下文里访问共享。Windows的权限模型是ACL（访问控制列表），比POSIX的rwx权限精细得多，所以SMB需要传输更复杂的权限信息。
另外，SMB是一个有状态的协议。服务器端需要维护每个客户端的会话状态、打开的文件句柄、锁状态。到了SMB 2.x和3.x，这种状态管理变得更加精细，引入了租约（lease）机制和持久句柄（persistent handle），让故障切换和网络恢复变得更顺滑。
Windows生态里SMB能成为"亲儿子"是有道理的：内核原生支持、文件服务器服务（LanmanServer）开箱即用、域环境自动集成Kerberos、组策略可以批量配置访问权限。你要是让Windows管理员去配NFS，他大概率会先问一句："为什么不用共享文件夹？"
1.3 协议版本：混用之前先搞清楚版本等级
很多人踩坑的另一个原因是对协议版本没有概念，以为SMB就是SMB，NFS就是NFS。其实这里面的版本差异比想象中大得多。
| 协议 | 代表版本 | 出现时间 | 核心变化 | 现状 |
|---|---|---|---|---|
| NFS | v3 | 1995年 | UDP/TCP，无状态，适合局域网 | 老系统仍见，新部署建议v4 |
| NFS | v4.0 | 2000年 | 有状态、原生Kerberos、伪文件系统 | 兼容性一般 |
| NFS | v4.1 | 2010年 | pNFS并行扩展、会话恢复 | 中等规模可选 |
| NFS | v4.2 | 2014年 | 稀疏文件、copy_file_range、原子交换 | 现代Linux默认首选 |
| SMB | 1.0/CIFS | 1980s-1996 | 最早版本，明文认证，漏洞极多 | 强烈建议禁用 |
| SMB | 2.0 | 2006年 | 命令复合、大文件支持 | Vista/Win7默认 |
| SMB | 2.1 | 2010年 | 租约机制 | Windows 7+ |
| SMB | 3.0 | 2012年 | 加密、多通道、RDMA、持久句柄 | Win8/Server2012+ |
| SMB | 3.1.1 | 2015年 | AES-128-GCM加密、预认证完整性 | Win10/Server2016+ |
如果你在2024年还在用SMB 1.0，那不仅是性能问题，还是巨大的安全漏洞风险。WannaCry勒索病毒当年就是靠SMBv1打穿内网的。我处理过的所有服务器，第一件事就是把SMBv1关掉。
NFS这边，现代Linux内核的客户端默认挂载版本已经到4.2了，Red Hat、Ubuntu、Debian这些主流发行版对NFSv4的支持非常成熟。我建议所有新环境直接指定nfsvers=4.2，不要让它自动协商，因为自动协商偶尔会掉回v3，而v3在某些场景下的权限、锁行为会让你排查到崩溃。
1.4 关键结论先行：混用意味着有一方在做"翻译"
现在把两者摆在一起看。NFS的语义接近POSIX，SMB的语义接近Windows API。如果一个Linux客户端去挂载SMB共享，内核需要把POSIX语义翻译成SMB语义；如果一个Windows客户端去挂载NFS导出，Windows需要把CreateFile、ReadFile这些调用翻译成NFS操作。**翻译就有损耗，损耗就会带来性能和兼容性问题。**这就是"不要混用"这句话最底层的逻辑。
2. 混用场景下的四大类故障：性能、锁、编码、权限
2.1 Linux挂SMB：写放大和元数据延迟最为致命
先看最常见的错误用法：一群Linux服务器去挂载Windows或Samba提供的SMB共享。轻度使用——比如拷贝几个文件、临时读一下日志——问题不明显。但一旦进入生产负载，比如编译构建、Git仓库操作、数据库备份、大规模文件迁移，你很快就会感觉到不对劲。
我实测过的一个场景：同样的10万个小文件，从一台Linux服务器拷贝到另一台，源端和目标端都是Linux，网络都是万兆。通过NFS挂载拷贝用了不到3分钟，通过SMB（Samba 4.x提供）挂载拷贝用了将近17分钟。差距是数量级的。
为什么会这么慢？原因有三个：
第一，SMB协议本身的开销更大。每次文件操作都伴随着额外的头部信息、会话状态确认，小文件操作时协议开销占比极高。第二，Linux的CIFS客户端（cifs.ko）的内核实现虽然成熟，但为了兼容Windows的各种语义，不得不付出性能代价——比如默认要处理ACL查询、对象ID查询等扩展操作。第三，Samba服务端如果是用户态进程，性能天然不如内核态的NFS守护进程（rpc.nfsd直接在内核协议栈里处理请求）。
这还只是性能。更大的坑是元数据操作，比如ls -l这种看似简单的目录列举，在SMB下需要为每个文件发起额外的属性查询请求；而在NFS下，READDIR可以携带着文件属性批量返回。你跑一个find命令，感受到的延迟差异非常明显。
2.2 文件锁失效：跨协议并发读写同一文件是灾难
这是我最想强调的一个点：NFS和SMB的锁机制不互通，而且即使在单一协议下，锁的行为也和本地文件系统不同。
SMB有强制锁（mandatory lock）和机会锁（opportunistic lock，oplock）。Windows应用依赖这些机制来保证文件的一致性，比如Office打开一个共享文档时，另一个用户再打开会收到"文件已被锁定"的提示。
NFS的锁走的是另一套体系。NFS v4把锁管理合并进了协议自身（之前的NLM锁管理器和状态是分开的）。NFS的锁更多是"建议锁"性质，基于POSIX的fcntl锁语义。
最危险的情况是：同一份数据，既通过NFS给Linux服务器访问，又通过SMB给Windows客户端访问，两边同时读写同一批文件。由于锁语义在协议间完全不互通，你无法保证互斥。一旦两边同时对某个文件进行写操作，轻则数据覆盖，重则文件损坏。
2018年我经历过一次事故：一台Linux服务器上的应用通过NFS挂载点写日志文件，而Windows管理员通过SMB共享手动编辑同一个配置文件，两边同时保存，结果文件变成一个混合了两段内容的畸形文件，应用直接崩溃，配置文件损坏后整个服务恢复了一下午。从那以后，凡是读写频繁的核心目录，我都坚持"一个目录只走一种协议"的铁律。
2.3 字符集和文件名：乱码只是表象，深层是编码体系冲突
中文环境下最让人崩溃的问题就是乱码。Linux下文件系统普遍使用UTF-8编码，而Windows（尤其是简体中文版）的传统路径是GBK/GB18030。NFS和SMB协议本身只传字节流，不负责告诉你"这串字节是什么编码"。
当Linux通过SMB挂载Windows共享时，服务端的文件名如果是GBK编码，客户端的cifs.ko默认不会做转换，你看到的文件名就是一堆乱码。反过来，Windows通过NFS访问Linux导出的UTF-8文件名，也会出现同样的问题。
很多教程会让你加iocharset=utf8之类的挂载参数，但那是SMB客户端在做字符集转换，治标不治本。而且不少转换是"尽力而为"，某些特殊字符、保留字符（比如Windows下的\ / : * ? " < > |、Linux下的/）转换后可能直接不可见或者无法操作。
热搜词里有一条"linux解压文件乱码"，很多时候源头不是解压工具的问题，而是文件在跨协议传输过程中文件名编码就已经错乱了。如果你的环境里中文文件名很多，强烈建议不要让文件在NFS和SMB两边反复流转，媒介一旦引入第三方（比如U盘、FTP服务器），编码错乱的概率呈指数级上升。
2.4 Windows挂NFS：权限映射与系统集成的硬伤
反过来看Windows客户端挂NFS。Windows从NT4开始就提供了NFS客户端，但一直像个后妈养的孩子。你要在Windows上挂NFS，首先得安装"Services for NFS"功能，这玩意在Windows Server和客户端系统里默认不启用。
启用之后，真正的噩梦开始了：权限映射。NFS认uid/gid，Windows认SID（安全标识符），两者怎么对应？Windows NFS客户端提供了一种叫做"身份映射"的机制，可以通过Active Directory将Windows用户映射到uid/gid，但配置过程繁琐，稍有不对就会出现"你能看到文件但没权限读写"的诡异状态。更简单的做法是匿名访问（anonymous），即客户端以指定uid/gid的身份访问NFS所有文件，但这种模式下Windows侧的文件权限管理基本失效。
还有一点，Windows NFS客户端对NFSv4的支持一直不完整，很多环境下用的是NFSv3。NFSv3没有内置的Kerberos认证，匿名映射几乎成了唯一选择，安全性堪忧。如果再叠加2.3节提到的大字符集问题，Windows访问NFS基本就是"能用，但不建议"的代表。
2.5 小结：混用带来的常见问题对照表
| 混用方向 | 典型问题 | 严重程度 | 缓解手段（如果短期无法切换） |
|---|---|---|---|
| Linux挂SMB | 小文件性能差、元数据操作慢、锁语义不完整 | 高 | 调大rsize/wsize、启用cache=loose、避免高并发小文件 |
| Windows挂NFS | 权限映射复杂、中文乱码、NFSv4支持不完整 | 高 | 使用匿名映射、下载专用客户端（如SFN替代方案）、限制只读使用 |
| NFS与SMB同时读写同一份文件 | 锁不互通，并发写导致文件损坏 | 极高 | 物理隔离读写通道、应用层加锁、切换单一协议 |
| 跨协议大文件拷贝 | 速度慢、中断后需重来 | 中 | 使用rsync/robocopy等断点续传工具 |
| 跨协议字符集 | 文件名乱码、文件无法删除或重命名 | 中 | 统一使用英文文件名、在源头转换编码 |
3. 推荐落地配置：Linux主力NFS，Windows主力SMB
3.1 最干净的架构：数据池按客户端群体拆分
如果你有权限设计整个文件共享架构，最推荐的做法不是在同一份数据上同时开NFS和SMB，而是按数据池划分：哪些数据主要是Linux系统访问的，就放在NFS专属导出目录；哪些数据主要是Windows用户访问的，就放在SMB专属共享目录。中间用备份任务或数据同步任务做必要的流转，但实时读写路径上不要跨协议。
举个例子，我常给中型公司设计的结构是这样：
| 存储目录 | 共享协议 | 适用客户端 | 典型数据 |
|---|---|---|---|
/srv/nfs/build | NFS导出 | Linux构建服务器 | 编译产物、代码仓库镜像 |
/srv/nfs/logs | NFS导出 | Linux日志采集器 | 应用日志、审计日志 |
/samba/office | SMB共享 | Windows办公PC | 文档、表格、设计稿 |
/samba/tools | SMB共享 | Windows运维终端 | 安装包、脚本、工具软件 |
这种方案下，每种协议都只服务自己最擅长的客户端群体，模型最干净，踩坑概率最小。
3.2 Linux挂NFS的推荐参数与解释
如果你的服务端是Linux（无论是NFS服务器还是Samba服务器），客户端也是Linux，那NFS是毫无争议的第一选择。下面是我反复使用、验证过的一套挂载参数：
mount -t nfs -o \ nfsvers=4.2,hard,timeo=600,retrans=5,rsize=1048576,wsize=1048576,actimeo=30 \ 192.168.10.5:/srv/nfs/build /data/build每个参数的解释：
nfsvers=4.2：固定使用NFSv4.2，避免自动协商掉到v3。hard：文件操作失败时不放弃，一直重试。对大多数应用这是可预期的行为，配合intr（或timeo重试设置）可以让NFS不可用时应用挂起而不是静默出错。timeo=600：超时时间600分之一的十分之一秒？不对，这个参数的单位是0.1秒，所以timeo=600意味着超时周期是60秒。这个值是针对无响应的重试周期，不宜设太小，否则网络抖动就会频繁报错。rsize=1048576、wsize=1048576：读写块大小设为1MB。万兆网络环境下1MB是推荐值，太小的块（比如默认的64KB）会让小文件性能损失更大。actimeo=30：属性缓存30秒。如果文件在服务端变化不频繁，适当调大属性缓存可以显著减少stat请求，提升目录列举速度。
如果你想把挂载写进/etc/fstab让它开机自动挂载：
192.168.10.5:/srv/nfs/build /data/build nfs nfsvers=4.2,hard,timeo=600,retrans=5,rsize=1048576,wsize=1048576,actimeo=30,_netdev 0 0注意_netdev选项。这个很关键，它告诉systemd"这个挂载依赖网络"，开机时不会因为网络未就绪而挂载失败。
3.3 Windows挂SMB的推荐操作
Windows端挂SMB几乎是最简单的事，但有些细节值得强调。
第一步，先确认服务端SMB版本。Windows上可以这样查：
Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol如果EnableSMB1Protocol为True，立刻关掉它——SMBv1就是不安全的代名词。
第二步，映射网络驱动器。在文件管理器地址栏输入\\server\share，按提示输入凭据即可。也可以在PowerShell里：
New-PSDrive -Name "Z" -PSProvider FileSystem -Root "\\192.168.10.5\office" -Persist第三步，如果要追求性能，确认SMB3.0以上的特性生效。Windows 10/11和Server 2016以上默认就有SMB多通道（SMB Multichannel），只要服务器端有多个网卡，协议会自动聚合带宽。如果网卡支持RDMA（RoCE/InfiniBand），SMB Direct可以跑出接近本地NVMe的速度，但这个对硬件有要求，普通办公场景不需要强求。
关于凭据持久化，我不建议在共享路径中保存密码明文。Windows的凭据管理器（cmdkey命令）可以做到安全存储：
cmdkey /add:192.168.10.5 /user:corp\zhangsan /pass:3.4 不可避免的"反向访问"怎么办？
架构再理想，总有一些边缘场景绕不开：要么Linux需要临时访问Windows共享，要么Windows需要临时访问NFS导出。
Linux挂SMB的正确姿势，应该尽量模仿生产负载不高的场景：
mount -t cifs -o username=zhangsan,password='xxx',vers=3.0,uid=1000,gid=1000,file_mode=0644,dir_mode=0755,iocharset=utf8 \ //192.168.10.6/office /mnt/win几个关键说明：
vers=3.0：明确使用SMB 3.0以上协议版本。不要用vers=1.0，既慢又不安全。uid=1000,gid=1000：把远程共享中的文件映射到你本地的用户/组。不映射的话，挂载点下的文件owner可能是root或未知数字。file_mode=0644,dir_mode=0755：对于没有ACL的共享，强制设置文件和目录权限，避免某些文件无法读写。iocharset=utf8：如果文件名是中文，加上这个参数能做UTF-8与本地字符集转换。
Windows挂NFS的方案，如果不是特别必要，我不建议在生产环境使用Windows自带的Services for NFS。真要挂，操作步骤如下：
- 控制面板 -> 程序和功能 -> 启用或关闭Windows功能 -> 勾选"Services for NFS"。
- 在命令行挂载：
mount -o anon \\192.168.10.5\srv\nfs\build Z:- 如果身份映射不对，需要去"NFS客户端"服务里配置用户映射，或者用
anon参数走匿名访问。
但说实话，Windows挂NFS我只建议用在"只读"场景，比如临时查看NFS服务器上的日志文件。一旦涉及写操作，权限和字符集问题会让你非常难受。
3.5 同源数据同时服务两种客户端：唯一靠谱的思路
如果你的业务真的需要同一批数据被Linux和Windows同时高频读写，那唯一靠谱的思路不是让NFS和SMB直接打架，而是引入中间层。中间层的形态可以多样化：
- 对象存储（MinIO、Ceph RGW）：Linux和Windows都通过S3接口访问，协议统一了，锁问题转交给对象存储的原子语义去处理。
- 分布式文件系统（GlusterFS、CephFS）：它们通常有自己的跨平台客户端。
- 网关同步方案：比如用Samba网关提供SMB服务，后端存储是NFS挂载。这种方式让Windows走SMB到Samba，Samba再通过NFS访问后端存储。虽然路径变长，但至少协议在这个入口上是统一的，锁语义由Samba来中转。
4. 一次真实故障的完整排查：Linux全走SMB，性能崩了
4.1 现象：构建服务器变"乌龟"，CPU居高不下
回到文章开头提到的那家客户。环境是一条独立研发网，一台Linux存储服务器，一台Linux构建服务器，若干Windows办公PC。存储服务器上跑的是Samba，一开始是为了方便Windows用户访问文档，后来图省事，构建服务器也直接用cifs挂载了Samba共享来拉取构建缓存和工具链。
某一天构建服务器开始频繁出现构建超时。运维同事用top一看，sys占用高达70%以上，iowait也不低。最开始以为是磁盘坏了，但在存储服务器本地跑磁盘测试又一切正常。
4.2 排查链路：从资源指标到协议指标
我接手后排查的顺序是这样：
第一步，先看网络和挂载状态。mount命令确认构建服务器的/opt/toolchain是一个cifs挂载点。
第二步，看协议版本和协商情况。用dmesg查cifs连接信息，发现内核模块协商到了SMB 3.1.1，版本倒是不低。但再看一眼挂载参数，发现没有显式指定vers，自动协商虽然协商到了3.1.1，但其他一些高级特性没有开启。
第三步，做基准对比。在构建服务器上用time命令执行同样一个打包解包操作，分别访问NFS挂载和SMB挂载的同容量目录：
| 操作 | NFS挂载耗时 | SMB挂载耗时 | 差异倍数 |
|---|---|---|---|
| 解压200MB tar包（5000个文件） | 8秒 | 46秒 | 5.75倍 |
ls -l一个5000文件的目录 | 0.4秒 | 3.2秒 | 8倍 |
| 连续拷贝1GB大文件 | 3.5秒 | 6.1秒 | 1.74倍 |
大文件只有不到2倍差距，但小文件和解压这种元数据密集型操作差距接近6-8倍，这就很能说明问题了：SMB在元数据操作上的性能损耗是决定性的。
第四步，用iostat观察构建服务器和存储服务器两侧的磁盘利用率。构建服务器侧磁盘几乎空闲，存储服务器侧磁盘也没有形成瓶颈，说明瓶颈不在磁盘，而在协议处理路径上。
第五步，在存储服务器上看Samba的日志和负载。smbstatus -p可以看到每个SMB会话的打开文件、锁状态。结果发现构建服务器的会话中，有大量频繁的锁请求和文件打开/关闭操作，Samba进程的CPU总占用率居高不下。
4.3 根因：协议语义差异+服务端进程模型双重叠加
结合起来看，根因就很清晰了。
第一层，SMB协议语义中，每个文件打开、读取、关闭的操作会比NFS多出不少额外的握手和状态维护。对于大量小文件操作，这些额外开销会被无限放大。构建工具链恰恰就是典型的小文件密集访问场景——成千上万个头文件、可执行文件、配置片段被反复打开。
第二层，Samba是用户态进程。相比内核态的NFS服务器，它需要处理更多的上下文切换和内存拷贝。当客户端数量少、操作量大的时候，这个差距尤其致命。
第三层，cifs客户端默认的缓存策略比较保守。为了兼容Windows的缓存一致性语义，Linux cifs客户端在打开文件的写操作上默认不走本地缓存，全部实时写到服务端，这进一步加剧了延迟。
4.4 修复：把Linux端全部切换到NFS
修复方案其实不复杂。存储服务器上原本的Samba共享目录是/export/data，我在这台服务器上先确认了NFS服务端已经安装（RHEL系是nfs-utils），然后在/etc/exports里添加了：
/export/data 192.168.10.0/24(rw,sync,no_subtree_check,no_root_squash)构建服务器的/opt/toolchain改成NFS挂载：
mount -t nfs -o nfsvers=4.2,hard,timeo=600,rsize=1048576,wsize=1048576 \ 192.168.10.5:/export/data /opt/toolchain切换后重跑同样的基准测试，小文件解压速度从46秒降到9秒，构建整体耗时下降了接近一半。Windows办公PC继续走SMB，完全不受影响。这就是"Linux用NFS、Windows用SMB"在生产环境中的一次非常直观的验证。
4.5 附带收获：明确了"不混用"的运维边界
这次排错之后，我给客户定了三条规矩：
- 构建、日志、代码等Linux系统主力访问的数据，只走NFS导出，不放到SMB共享里。
- 办公文档、安装工具等Windows用户访问的数据，只走SMB共享，不导出NFS。
- 如果某个目录确实需要两种协议都访问（比如研发团队要，销售也要），那就做单向同步，用
rsync或robocopy定期把数据从NFS侧复制到SMB侧，而不是让两边同时写。
这三条规矩后来成了我处理同类环境的默认基线，几乎再没出过协议相关的生产事故。
5. 一些容易被搜索引擎误导的"常识"澄清
5.1 "Windows无法安装到格式化为NFS的分区"是什么梗？
这个说法本身暴露了基础知识混淆。NFS是网络文件系统，不是本地磁盘文件系统，它定义的是"通过网络访问远程文件"的协议，而不是一张磁盘的分区格式。Windows系统安装能使用的本地分区是NTFS，Linux本地分区是ext4、xfs这些。你在Windows安装程序里即使想选"NFS分区"，它也根本不会出现在分区列表里，因为NFS根本不是分区格式。
会出现这种搜索词，大概率是有人把"NFS分区"和系统引导时挂载网络根文件系统（NFS root）混为一谈了。后者在Linux的PXE网络启动、无盘工作站场景里确实存在，但那是在引导加载阶段通过DHCP/TFTP拿到内核，然后以NFS作为根文件系统启动的，整个过程Windows完全不参与。
所以正确的理解应该是：NFS和SMB都只是"网络文件访问协议"，它们管不着本机磁盘怎么格式化。NFS和SMB的选型，只影响你访问远程共享的方式，不影响本地磁盘分区方案。
5.2 "kali链接smb"怎么做才规范？
Kali等Linux发行版连SMB，最常见的两位命令是smbclient和mount.cifs。快速验证共享列表用：
smbclient -L //192.168.10.6 -U username挂载一个共享到本地：
mount -t cifs -o username=username,vers=3.0,uid=1000,gid=1000 //192.168.10.6/share /mnt/smb这种场景通常是一次性的渗透测试或简单的文件交换，属于低负载使用，倒不必太纠结性能。但如果你发现Kali在做大规模文件扫描时SMB很慢，不要急着调网络，先检查一下是不是挂载参数里没有指定vers=3.0。很多老教程给的命令默认走SMB1，慢且不安全。
5.3 WSL删除文件后空间没释放，跟NFS/SMB有关系吗？
没有关系，但搜索热词把它们放一起了，顺手澄清一下。WSL（Windows Subsystem for Linux）的根文件系统是一个虚拟磁盘文件，默认是ext4.vhdx。你在WSL里删除文件，ext4文件系统层面释放了空间，但虚拟磁盘文件本身不会自动收缩，Windows上看到的还是那么大。解决办法是在Windows的PowerShell（管理员）里执行：
wsl --shutdown Optimize-VHD -Path "$env:LOCALAPPDATA\Packages\*\LocalState\ext4.vhdx" -Mode Full没有Optimize-VHD命令的话，说明你的Windows版本没有Hyper-V管理工具，可以改用diskpart手动compact，或者干脆用WSL 2自带的wsl --manage <distro> --set-sparse true（需要最新版本支持）。总之这个问题的链路是"ext4文件系统+vhdx虚拟磁盘"，和NFS/SMB这两种网络协议八竿子打不着。
回到最开始那句话：nfs、smb不要混用，推荐linux使用nfs，windows使用smb。这句话背后是几十年的协议演化和无数实践踩坑换来的经验。每种协议都服务好自己生态内的客户端，边界清晰、监控简单、故障率低。我后来在公司里做存储方案评审，第一眼看的就是"这份数据的主要消费者是谁"，消费者是Linux，默认NFS；消费者是Windows，默认SMB。这个简单的判断标准，帮我躲过了远比预想中多的麻烦。
