@dorothyREN
@gamexg 就是交叉对联线，普通常用网线两头都一样的线序标准(586A/586B)，若一头是 A，另一头是 B，即 AB 线

AB 线可以让两张网卡直接通讯(里面一对数据收发线对掉，让两张网卡收发对应起来)

千兆网卡的标准内置了“线序自动侦测和自动翻转"，其实已经可以用一根普通网线对联两张网卡。

我实践中也遇到过两张千兆网卡(最近 3 年内)，使用优质网线(超五类,六类)直接对联，实际传输速率却非常低，
直到用两根网线和一台交换机把它们连起来才达到正常速度(Debian/Ubuntu)。

本来就拍给中国人看（主要市场在中国）的片子嘛，不用个明星，能对得起广大人民群众？能对得起中国投资人（老板就好那个星）？

他们口中的 “计算机” 只是个广义的概念，的确在有些软件 /服务公司里作初级销售，门槛和保险推销员没什么差别。作芯片设计 /编译器设计优化，那门槛就也不低。

@GalvinZhao 钓鱼可不是冥想，很麻烦的，各种琐事…并不是枯坐。其实觉得有点像全身心投入作一个程序的 debug （观察，调整，尝试；不断循环）

中国式淡水垂钓，用的活饵 /可食用加工饵，单钩 /双钩 最长十分钟就得提杆收线换饵（否则泡化了 /饵失去活性），时不时还得撒诱饵。欧美淡水垂钓多用拟饵 /飞蝇钓法，得不断抛钩收线让假饵模拟水虫游动，更像是中低强度有氧运动了。

凡人不是神仙，人老了很多出现的问题和衰弱都是不可逆的，很多方面就算作的再好，也只是减缓过程。还是要趁早打算，尽量能趁年轻时就学习如何正确面对终结之时。

文中提到前些天还有说有笑，某天就突然离世，说来也是善终了，可以说是种令人羡慕的幸福终结，比在病床上痛苦好多年活活拖死要好得多。之前能有说有笑，那么看来是和楼主处的很快乐的，人生在世，能活得快乐，那就是最大的幸福，足够是大孝了。

楼主爷爷爸爸都因为心脏问题么？那么请自己也小心了吧，定期体检，遵医嘱的健康生活作息习惯，活得开心。

@ryd994 是的，假若只是传统的网卡设计，的确高速网卡(10Gbps 起步)，是网卡没跑满但 CPU 因为要参与网络传输给耗得差不多了（某年某会议上某电商巨头的技术大佬分享经验时特别提吐过这个槽点）。

这两年一些大厂(amazon 已经开始用)出了一些“自带硬件加速”的高速网卡，来极大减轻网络传输时 CPU 的负载。

公积金网站在线找回密码

最后，饭桌上玩手机真得不好。哪怕你两眼茫然目视前方发呆傻笑都可以。

啊哈哈哈哈...当众这么哭了，好样的！随性，说不定还是好事。

或许同桌的妹纸觉得你可爱，以后私下更多联系你呢。

@a7a2 很早以前看过一些介绍 rsync 比对 /传输 算法的文，记得它们都介绍 rsync 是基于存储块的分析比对来高效查分传输的，并不是针对文件对象来比对。

"无论是本地或远程文件传输，rsync 首先创建每个源文件块校验的索引。此索引用于查找可能存在于目标中的任何相同数据块。一旦这种块存在，块就被就地使用，而不是从源复制。这大大加快了存在小差异的大文件的同步。"
from: https://wiki.archlinux.org/index.php/Rsync_(%E7%AE%80%E4%BD%93%E4%B8%AD%E6%96%87)

"rsync 实用程序使用由澳洲计算机程序师安德鲁·垂鸠（ Andrew Tridgell ）发明的算法，在当接受端计算机已经有相同结构（例如文件）但不同版本时，有效的将结构传输过通信连接。

接受端将文件拷贝打散成固定大小为 {\displaystyle S} S 的不重叠片段，并对每个片段计算两个校验和：MD4 散列函数与一个较弱的轮替校验和（ rolling checksum ）。它将这些校验和送给发送者。通信协议版本 30 （与 rsync 版本 3.0.0 一并发行）现在使用 MD5 散列函数以替代 MD4"
from:
https://zh.wikipedia.org/wiki/Rsync#%E6%BC%94%E7%AE%97%E6%B3%95

我们 NAS 是将 4 个网口在千兆交换机上绑定聚合的，所以 NAS 单 IP 总带宽就是千兆 x4，
实际使用中的确是可以接近 400Mbytes/sec 的速率读写数据，但对于我们动辄需要读写上 TB 的单一大文件，
依然是缓慢(视频处理任务里，很多时间耗在数据传输上)，

客户端(工作机)主板所限制(最终还是成本所限)，PCI-E 剩余插口不足，没办法插 4 块网卡，用不起 4 口网卡，
所以最终工作机还是被局限在千兆网络上。

#43 没敲完，按错键被快速发出了

几十 TB 的 NAS 勉强够用，设备间导入导出的确是个麻烦，即便可用 SSD 作移动硬盘传递，设备间传输还是太慢。

做过一些勘查，发觉能满足需求(拆硬盘没问题，只要快就行)，唯有 Type-C 物理接口的雷电 3 的速率才可以满足。

因为可动用的资金有限，最后还是委屈用 USB-3.0

去年碰巧也遇到过有相当长一段时间里，几乎每周都会有总量 2-3TB 的大文件(视频为主)产生，几十 TB 的 NAS

@hdyl 觉得你所面对的困难还是太大了，可参考

https://ex.noerr.eu.org/t/464363#r_5807919
里 56 楼 msg7086 所言极好：
“ 我觉得吧，学编程、学计算机语言、学软件开发，这是三样不同的事情。”

多网卡绑定...只给存储器服务器作，也只是提高了服务器的带宽，客户机输出带宽并无改善。

RAID 写入足够？你真的这么看？绑 4 块网卡，至少峰值就是 400Mbytes/sec 了...

买不起 /不愿投资搞比较高标准的 NAS (冗余度至少达到可承受 2 块硬盘同时坏掉)，还得有可靠备份，那么可以：

人力资源丰富，吩咐小弟去找一堆机器组 Hadoop 鸡群吧，设定好冗余策略(随时都可以改)只要不断增添机器，
HDFS 整体容量就能不断扩张，就是用起来比较麻烦，不像共享磁盘，更像个 RSYNC 服务器。

几年前有那么一年多很火爆的这种，记得是一家独大，有几家还想竞争，似乎这么几年后都没啥声音了。

请手下关系好的程序员吃个饭，之后好好善待他们，公平开价
(按工时算价格，以他们当前工时价格+加班费 作为起步基础)请他们接下你这单私活呗。

你只要认真出好你的需求文档，注意他们进度就 OK，大家作自己擅长的事，何乐不为。