smb 速度的确不应这么慢。
但我个人实践下来，群晖系统提供的 nfs 响应速度就比 smb 好很多。。。哪怕 sftp 也比 smb 好，不知道为什么。
另，原盘多大？我 nplayer ios 版本看过 30g 的 比利·林恩的中場戰事，随便拖没问题（拖完 1 秒内缓冲，可以忽略不计）。
场景：走 wifi5G，iphone xs max，ds918+，有 ms2 缓存

群晖哪里有不需要设置就会自动备份的？

恢复备份数据？备份数据是怎样的数据？怎么备份的？

@no1xsyzy #72

明白了，我们认知看来差异不大，讨论可以结贴了。
理性讨论还是让人感觉很愉快的。

图片备用访问地址：
1. https://ipfs.k1ic.com/ipfs/QmXixjZHCrdPyNTHCPc9SLf5w6iBn4QE3j27LChdghqw1y/Snipaste_2021-01-05_06-59-25.png
2. https://ipfs.k1ic.com/ipfs/QmPugun1r7Knbd1awzgkyXQWr42CDFZLEqEnm3oo7ZMu59/Snipaste_2021-01-05_07-12-17.png

@no1xsyzy #68

另外，为了尊重你，我特地去了 HDHome 以关键词 “原盘”，搜了一下，大部分原盘文件大小入下图：
https://10.via0.com/ipfs/QmXixjZHCrdPyNTHCPc9SLf5w6iBn4QE3j27LChdghqw1y/Snipaste_2021-01-05_06-59-25.png


可能有更大的我没有搜到，但是 30g 左右是一个比较普遍的大小。
我们以影片 Le colt cantarono la morte e fu tempo di massacro AKA Massacre Time 1966 1080p GER Blu-ray AVC DTS-HD MA 2.0-OLDHAM 为例，文件清单如下：

```
BDMV/BACKUP/CLIPINF/00000.clpi 0.54 KB
BDMV/BACKUP/CLIPINF/00001.clpi 1.41 KB
BDMV/BACKUP/CLIPINF/00002.clpi 39.39 KB
BDMV/BACKUP/CLIPINF/00003.clpi 0.29 KB
BDMV/BACKUP/CLIPINF/00004.clpi 1.59 KB
BDMV/BACKUP/CLIPINF/00005.clpi 3.88 KB
BDMV/BACKUP/CLIPINF/00006.clpi 7.58 KB
BDMV/BACKUP/CLIPINF/00007.clpi 1.13 KB
BDMV/BACKUP/CLIPINF/00008.clpi 6.20 KB
BDMV/BACKUP/CLIPINF/00009.clpi 1.29 KB
BDMV/BACKUP/MovieObject.bdmv 2.01 KB
BDMV/BACKUP/PLAYLIST/00000.mpls 0.18 KB
BDMV/BACKUP/PLAYLIST/00001.mpls 0.18 KB
BDMV/BACKUP/PLAYLIST/00002.mpls 0.45 KB
BDMV/BACKUP/PLAYLIST/00003.mpls 0.18 KB
BDMV/BACKUP/PLAYLIST/00004.mpls 0.21 KB
BDMV/BACKUP/PLAYLIST/00005.mpls 0.21 KB
BDMV/BACKUP/PLAYLIST/00006.mpls 0.18 KB
BDMV/BACKUP/PLAYLIST/00007.mpls 0.21 KB
BDMV/BACKUP/PLAYLIST/00008.mpls 1.18 KB
BDMV/BACKUP/index.bdmv 0.22 KB
BDMV/CLIPINF/00000.clpi 0.54 KB
BDMV/CLIPINF/00001.clpi 1.41 KB
BDMV/CLIPINF/00002.clpi 39.39 KB
BDMV/CLIPINF/00003.clpi 0.29 KB
BDMV/CLIPINF/00004.clpi 1.59 KB
BDMV/CLIPINF/00005.clpi 3.88 KB
BDMV/CLIPINF/00006.clpi 7.58 KB
BDMV/CLIPINF/00007.clpi 1.13 KB
BDMV/CLIPINF/00008.clpi 6.20 KB
BDMV/CLIPINF/00009.clpi 1.29 KB
BDMV/MovieObject.bdmv 2.01 KB
BDMV/PLAYLIST/00000.mpls 0.18 KB
BDMV/PLAYLIST/00001.mpls 0.18 KB
BDMV/PLAYLIST/00002.mpls 0.45 KB
BDMV/PLAYLIST/00003.mpls 0.18 KB
BDMV/PLAYLIST/00004.mpls 0.21 KB
BDMV/PLAYLIST/00005.mpls 0.21 KB
BDMV/PLAYLIST/00006.mpls 0.18 KB
BDMV/PLAYLIST/00007.mpls 0.21 KB
BDMV/PLAYLIST/00008.mpls 1.18 KB
BDMV/STREAM/00000.m2ts 11.32 MB
BDMV/STREAM/00001.m2ts 448.49 MB
BDMV/STREAM/00002.m2ts 26.95 GB
BDMV/STREAM/00003.m2ts 4.63 MB
BDMV/STREAM/00004.m2ts 638.00 MB
BDMV/STREAM/00005.m2ts 637.39 MB
BDMV/STREAM/00006.m2ts 2.65 GB
BDMV/STREAM/00007.m2ts 173.95 MB
BDMV/STREAM/00008.m2ts 809.35 MB
BDMV/STREAM/00009.m2ts 484.32 MB
BDMV/index.bdmv 0.22 KB
CERTIFICATE/BACKUP/id.bdmv 0.10 KB
CERTIFICATE/id.bdmv
```

显然这不是一个无脑的 mkv 视频文件，详细信息如下：

```
CodeDisc Label: Le.colt.cantarono.la.morte.e.fu.tempo.di.massacro.1966.MULTi.COMPLETE.BLURAY-OLDHAM
Disc Size: 35,143,783,640 bytes
Protection: AACS
Playlist: 00002.MPLS
Size: 28,932,280,320 bytes
Length: 1:32:09.649
Total Bitrate: 41.86 Mbps
Video: MPEG-4 AVC Video / 34718 kbps / 1080p / 23.976 fps / 16:9 / High Profile 4.1
Audio: German / DTS-HD Master Audio / 2.0 / 48 kHz / 1027 kbps / 16-bit (DTS Core: 2.0 / 48 kHz / 896 kbps / 16-bit)
Audio: Italian / DTS-HD Master Audio / 2.0 / 48 kHz / 1045 kbps / 16-bit (DTS Core: 2.0 / 48 kHz / 896 kbps / 16-bit)
Audio: English / DTS-HD Master Audio / 2.0 / 48 kHz / 1020 kbps / 16-bit (DTS Core: 2.0 / 48 kHz / 896 kbps / 16-bit)
Audio: English / DTS-HD Master Audio / 2.0 / 48 kHz / 661 kbps / 16-bit (DTS Core: 2.0 / 48 kHz / 384 kbps / 16-bit)
Audio: German / DTS-HD Master Audio / 2.0 / 48 kHz / 645 kbps / 16-bit (DTS Core: 2.0 / 48 kHz / 384 kbps / 16-bit)
Subtitle: German / 7.006 kbps
Subtitle: English / 6.261 kbps
```

总码率 41.86 Mbps，三倍约为 123Mbps 。
文件总大小，32.73 GB，三倍约为 99 GB，时长约为 1:32:10 秒，也就是 5530 秒，(99*1024)/5530=约为 18.33m/s
每秒的 IO 总量如上，千兆也好，usb 3.0 也好你可以参考一下。

至于你说的读取时序的问题，硬盘是何种机制我不了解，但是至少从播放体验上来说，哪怕是 1G 的 1080p mkv 文件，拖动以后，播放器也会有 1 秒不到左右缓冲然后继续播放，排除播放器缓冲本身，我刚刚特地观察了一下我 nas 上的 NetDATA 图示:
https://10.via0.com/ipfs/QmPugun1r7Knbd1awzgkyXQWr42CDFZLEqEnm3oo7ZMu59/Snipaste_2021-01-05_07-12-17.png

换句话说，我个人理解为，除非 3 个播放行为在同一瞬间，都在拖动播放器的进度条，否则...
既然现在场景复现的条件越来越多，越来越苛刻，还是那句话，


这样的场景意义何在？？现实中有可能么？

@no1xsyzy 120Mbps，意思是 12m/s ？ Mbps 未测试，我个人也不会去下载 60g 的文件，你可以自己尝试下载实际测试一下，至于你说的各种理论，还是实践一下比较好。毕竟，你担心的，播放器预读取机制也会考虑。而且，而且，千兆局域网，10m/s 放大 2 倍，这样的顺序 io 就瓶颈了？

何况我的重点是，根本就极少机会出现这种观影场景。

@WNW 知道

经典的：Response.Write()

@no1xsyzy #66

我也是 nas 老玩家了，实操体验为，三口之家，4k 是大家一起看一部片子，或者父母基本看机顶盒国产连续剧，或者孩子看动画片，我手机看 1080p 硬编码字幕，老婆手机看视频平台综艺。

4k 原盘，假设文件大小 30g，200 分钟，网速要求，2.56m/s，这是一个简单的计算题：30x1024m/200x60s

就算 4 个人同时看，也就是 10m 多每秒的 IO 压力…百兆内网算是峰值，前兆内网无压力，usb 3.0 5G 的带宽，至少能吃满千兆局域网。

所以，以我几年玩 nas 微薄的个人经验，多人看 4k 场景在 6 口之家的范围内，实际极为稀有，但即使极为稀有的场景下，usb 3.0 + 千兆局域网足以应对。我个人是硬件 918+，带 m2 缓存，思科千兆 16 口交换机…所以你提到的压测场景我个人实操过，且进度条随便拖拽，在拖拽完几秒缓冲后，并无卡顿的情况。

你问我为啥盯那么紧？因为，拍脑袋杜撰一个场景，说不行，所以我们要上什么需求，这样的事情公司里还不够每天被恶心吗？每天看到 V2EX 怼这个老板，那个公司…实际上些人其实和自己的公司、老板、产品经理没啥两样。

以上回答你问的那句问题：为啥盯那么紧。伪假设基础上提出的瞎🐔八结论。

为啥不试试小米的国际版 rom

减仓 25%

楼上+1

参考鹅厂，有 code review，svn 递交必须审批，回顾问题落实到责任制。
那可能沦为形式化会弱一点。


制度和人之间，关键作用的还是人。

@xmt328 #63

麻烦先了解一下，极端化的定义，在说别人是不是“极端化”。
NAS 我自己也用，而且我有 2 台 NAS，总盘位 10 个都插满，总容量 40T 。

所以，明显你连我刚刚揪着不放的帖子的上下文都不了解，就来参与讨论，这样的讨论其实并不是很尊重对方。
我一直只是针对#31 楼提出的场景罢了。

附图：
https://10.via0.com/ipfs/QmP4UzGnHi5APy1RjxoY6jsQ3uL79636atD6hhU8wNYuZi/Snipaste_2021-01-04_09-57-53.png

@xmt328 #60

那也建议你，“不用这么急着否定别人” 的观点，你家的 NAS 在家你自己看 4k，公司和爸妈家看 1080，但我上面一直说的只有一点。3~4 个人一起看 25g 4k 原盘。。。

你巴拉巴拉说一堆，那你有过这样的场景吗？是：3~4 个人在一个局域网，从一个设备一起看 25g 4k 原盘吗？
如果你是一个三口之家，算上和父母一起住，五口之家，算上二胎，六口之家，你真的有实践过这样的场景么？

@zzw252 我不用 ac，你可以专门开个帖子问问 ac 怎么搞效果好

但凡有一碟花生米系列…用 date 对象很难吗？…

@no1xsyzy 他描述的场景，按照他自己后面的解释，我比较下来，属于拍脑袋瞎🐔八扯

书桌一条线出来，可以拖个 5 口千兆二级交换。
电视柜也一样，我的电视柜下面有一个 8 口网件二级交换。用来接 ps3 、ps4 、机顶盒、电视等设备。1 进 7 出还有富余。

千兆，个人使用下来，是足够的，这么的有必要上万兆么？
一般，一个房间一个网线口，用来以后扩展 ap 。
客厅可以考虑电视机这多几个口
书桌附近可以多几个口

加上专门放 nas 的柜子，其实墙上的网线口，按照 3 室 2 厅来算，不应超过 7 个（ 3 个房间各 1 个，2 个厅 各 2 个）
一般家用 16 口的千兆交换机足矣，1 入 15 出，7 口给墙，8 口留给 NAS 柜。

我本人用 16 口思科交换机，还未插满。
以上你可以参考一下。