感觉 nas 对于我来说就是伪需求

ferock

2021-01-04 09:40:56 +08:00

@xmt328 #60

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

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

jakehu

2021-01-04 09:42:30 +08:00

说 nas 没用？
收集笔记
自动备份手机照片
自建 gogs
自建 bitwarden
存电影
下载器
等等等等
主要是支持 docker 后就很爽

xmt328

2021-01-04 09:55:44 +08:00

@ferock 我只想说明几个人同时看是有可能的,甚至可以通过软件实现同步看
你一定要极端化一个场景我没话说,不上 NAS 能不能用,那肯定是可以的
好不好用,那各自看需求吧,反正我真香

ferock

2021-01-04 09:59:38 +08:00

@xmt328 #63

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

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

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

ghostist

2021-01-04 10:26:23 +08:00

我就是用蜗牛，需求是 NAS：做 mbp 和黑果的 Timemachine，存储从高中到现在的各种照片（不整理只存） 4T+4T 冗余
存家里 4 个摄像头的录像（ rtsp 流） 500G
homeassistant 、nodered 、mqtt 、zigbee2mqtt 等智能家居相关的服务
ikuai+op，op 主要是签到插件什么的

不算伪吧，功耗没测过，之前单跑智能家居的也得 10W+-

no1xsyzy

2021-01-04 22:49:44 +08:00

@ferock 我作这么个假设你看怎么样：
1. 松鼠症晚期，无脑收大量 4k 原盘
2. 然后一测试，就是不用走网络共享，一台电脑开三个 4k 原盘一看，哇，卡了
3. 然后他就觉得“哦这不行，得来个 NAS”

压力测试加上了从未能达到的压力，导致在服务器配置上面花费了多余不必要的开销，代码优化上花费了不必要的精力。
这也不是什么从未发生过的事情，所以为什么现在都喜欢强调“横向可扩展”，就是因为压力测试很难把握实际情况下的压力。
这算是典型问题了，还不至于让你盯这么紧吧

他身上更严重的问题是，压力测试通不过，分析原因分析得不对。那句话怎么说
Premature optimization is the root of all evils.
没进行实际的分析，就拍脑袋想方法解决。还好大部分组 NAS 的不会去搞纯 RAID1，不然速度还是一样，那他就得开始说 NAS 不行没有任何意义了。

ferock

2021-01-05 00:07:25 +08:00

@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 怼这个老板，那个公司…实际上些人其实和自己的公司、老板、产品经理没啥两样。

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

no1xsyzy

2021-01-05 00:46:02 +08:00

@ferock 你这个 4k 原盘有缩水吧…… 4k@24Hz 通常有 35-45Mbps，不过也就你的两倍
问下你的 RAID 情况？这个是重点。 @jones2000 的问题显然是出在机械硬盘读取速度上。我顺便测了下我的盘，顺序读取约 120Mbps，是根本吃不住 45Mbps *3 的。（ HDD 理想情况是 150Mbps ）
顺便 ZFS 的 ARC / L2ARC 能够对顺序读取进行预测，会抹去读取安排不正确（比如三个进程分别同时向 SATA 协议的硬盘三个不同扇区持续请求数据而不等待前一数据返回，会导致队列长度的竞态条件，读取时序是不均匀的）和时域码率波动导致的卡顿。

哦这没毛病，你继续。

ferock

2021-01-05 06:29:51 +08:00

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

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

ferock

2021-01-05 07:15:29 +08:00

@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 个播放行为在同一瞬间，都在拖动播放器的进度条，否则...
既然现在场景复现的条件越来越多，越来越苛刻，还是那句话，

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

ferock

2021-01-05 07:22:13 +08:00

图片备用访问地址：
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

2021-01-05 09:32:06 +08:00

@ferock 所以说瓶颈在 HDD 上，不是 usb 也不是千兆网。上面我也说了 CrystalDiskMark 看了下，我的硬盘读取速度 120Mbps 左右。
这就是我说的 jones 原因分析错了，实际上解决了他的 “问题” 的，不是 NAS 而是 RAID 或者没有 RAID 分盘分区，存放在不同盘上。
读取时序问题基本只有在读取速度非常接近硬盘读取速度的情况下会发生，是个 SATA 协议任务队列长度和 “旋转磁盘” 的问题。打个比方，你有三个进程同时进行大量读取 0 1 2 三个扇区的活动，结果任务队列不是 012012012 而是 000222111，那一旦 000222 的读取总量超过 HDD 缓存，中间读取 1 扇区的机会会被跳过，直接导致 1 “卡了”。
拖动进度条不是顺序读取，根本不要讨论，就是直接播放。

场景论：哦这没毛病，我举双手同意，你继续。

ferock

2021-01-05 09:38:10 +08:00

@no1xsyzy #72

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

shawn102400

2021-03-22 14:02:29 +08:00

@jones2000 USB3.0 至少跑 100M/S，播放 4K 毫无问题。先检查宽带吧，怕不是用的百兆线百兆卡。