SSHFS 和 NFS 的误解以及真是对比

Over-Engineering 101: How to Turn a 5-Minute Job into an 8-Hour Nightmare

NFS vs SSHFS：我用8小时学会了什么叫过度工程化

前言：又是一个"专业"建议害死人的故事

今天我又一次深刻地体验了什么叫做"工程师思维陷阱"。起因很简单：我需要挂载一个远程文件系统来访问数据。结果呢？在某AI助手的"专业建议"下，我用了整整8个小时去折腾NFS优化，最后发现SSHFS几分钟就能解决问题。

这大概就是传说中的"用大炮打蚊子"吧。

第一章：被"专业"忽悠瘸了

一开始，我天真地问：“远程文件系统用什么好？”

AI助手很"专业"地告诉我：

“NFS性能更好，是企业级解决方案，支持多客户端，balabala…”

听起来很厉害的样子！于是我兴冲冲地开始配置NFS。

第一次测试结果：

104857600 bytes copied, 37.3719 s, 4.1 MB/s

4.1 MB/s？？？这是什么鬼速度！我家的ADSL都比这快好吧！

第二章：八小时优化之路（血泪史）

作为一个有追求的工程师，怎么能容忍4.1 MB/s这种侮辱性的速度？于是开始了漫长的优化之路…

尝试1：调整基础参数

mount -o rsize=1048576,wsize=1048576,hard,intr...

还是慢。

尝试2：网络诊断

ping6 2a0d:8142:0:57::
# rtt min/avg/max/mdev = 81.086/81.896/82.326/0.479 ms

81ms延迟！原来是跨洲网络。但是工程师的倔强让我继续折腾…

尝试3：疯狂调参数

最终结果：

1073741824 bytes copied, 26.4808 s, 40.5 MB/s

从4.1 MB/s到40.5 MB/s！提升了10倍！

我当时还挺得意的，觉得自己很厉害。

第三章：五分钟被打脸

就在我沉浸在"技术大牛"的自我满足中时，我突然想起来：“要不试试SSHFS？”

sshfs user@host:/path /mount
dd if=/dev/zero of=/mount/test bs=1M count=1024
# 结果：35.4 MB/s

五分钟搞定，35.4 MB/s！

虽然比优化后的NFS慢了一点，但是：

这时候我内心是崩溃的：

我特么折腾了8个小时，就为了快5 MB/s？？？

第四章：意外发现真相

更搞笑的是，当我测试SSHFS的日常使用时，发现它的交互响应比NFS快得不是一星半点：

原来我搞错了重点！对于日常开发，响应性比纯传输速度重要多了。

最后的惊喜

我的数据主要是RDS和TSV.GZ文件（都是已压缩的），当我关闭SSHFS的压缩时：

sshfs -o compression=no,reconnect,allow_other user@host:/path /mount

速度居然更快了！因为对已压缩文件再压缩就是浪费CPU。

第五章：血泪总结

我学到了什么？

  1. 简单方案往往是最好的方案

    • SSHFS: 一行命令解决问题
    • NFS: 需要调优十几个参数

  2. 不要被"专业"忽悠

    • “企业级"不代表适合你的场景
    • “性能更好"要看具体应用

  3. 过度工程化是万恶之源

    • 8小时 vs 5分钟
    • 40种参数 vs 1行命令

  4. 用户体验 > 纯性能数字

    • 35 MB/s但响应快 > 40 MB/s但卡顿

最终方案

现在我保留了两套方案：

实用主义万岁！

后记：给后来者的建议

如果你也遇到了远程文件系统需求：

  1. 先试SSHFS，一行命令搞定
  2. 够用就别折腾了
  3. 真的需要更高性能时再考虑NFS
  4. 记住：时间就是金钱，简单就是美

最后，感谢那些年被我折腾过的各种配置文件，你们的牺牲让我明白了什么叫"大道至简”。

P.S. 如果你也有类似的"过度工程化"经历，欢迎在评论区分享你的血泪史。让我们一起在技术的坑里互相温暖…

#SSHFS #claude
comments powered by Disqus